Quelques informations ...

Voici quelques informations ...
Je suis en déplacement professionnel depuis 2 semaines et PANORAMIC avance, mais plus lentement que lorsque je suis chez moi.

1 - La limite à 30 de la taille de la police de FONT_SIZE a été levée.

2 - Une petite instruction (de 4 lettres seulement) a été créée, mais quel boulot, car elle bouleverse la gestion des variables et préfigure ce que sera PANORAMIC dans le futur.
Roulement de tambour ...
C'est FREE variable qui libère la place qu'occupait une variable en mémoire et qui annule totalement la variable: le nom peut être réutilisé ou pas.

exemple:

Code:

dim a%,b%,c%(20,30)
a%=10
b%=20
c%(5,6)=100
free a%: rem a% n'existe plus
free c%: rem le tableau c% n'existe plus

3 - Je commence à me demander si je vais coder l'instruction REDIM qui redimensionne un tableau, car on pourra faire l'équivalent de REDIM avec FREE et DIM:

Code:

dim c%(20,30)
c%(5,6)=100
free c%: rem le tableau c% n'existe plus
dim c%(200,300): rem le tableau c% est redéfini

Remarque: la valeur de c%(5,6) est perdue.

4 - J'ai commencé à coder les sous-programmes avec passage de paramètres:
- déclaration par SUB NOM(a%,b,c$)
- définition par NOM(a%,b,c$)
- utilisation par NOM(a%,b,c$)

Code:

dim i%
sub square(nombre%)
rem ----------------------
for i%=1 to 10
 square(i%)
next i%
end
rem ----------------------
square(nombre%)
 print nombre%*nombre%
end_sub

Bonjour
L' avantage avec le redim c'est que rien n'est perdu dans le tableau.Ou alors il faudait
copy c%(20,30),d%(50,30)
free c%
copy d%(50,30),c%(50,30)

Ou quelque chose comme cela.

Super Beau boulot avec le Free... avec le sub... on peut faire des sous programmes propres et indépendants, c'est vrai que ça va boulverser Panoramic et la réutilisibilité des codes, je pense que certains vont ressortir leur programme de librairies de sous programmes

Alors là Jack, je suis scotché ! J'attendais cela depuis longtemps ! La commande FREE est super, mais surtout la commande SUB(...) - un vrai progrès ! C'est le pas décisif vers une bibliothèque de sous-programmes utilisables par #INCLUDE partout, chez tout le monde. Et avec la commande FREE, on pourra au moins s'approcher d'une simulation des variables "locales" en choisissant dans ces sous-programmes des noms très spécifiques pour les variables et en les supprimant après !

Question: est-ce que tu as aussi envisagé la même chose pour les labels ? Quelque chose comme FREE_LABEL label ? On pourrait alors localement définir des labels dans un sous-programme indépendant, et les supprimer en sortie...

@659_minifly:

Citation :

L' avantage avec le redim c'est que rien n'est perdu dans le tableau

Ah bon ?
Même si tu fais ça ?

Code:

dim c%(100,200)
c%(100,200)=5
redim c%(10,10)

D'autre part, je pense que le programmeur qui doit utiliser redim pour agrandir son tableau sans perdre les données a fait une erreur de conception:

Code:

dim c%(10,20)
C%(10,20)=5
redim c%(100,200)
c%(100,200)=10

Il vaut mieux faire tout de suite dim c%(100,200):

Code:

dim c%(100,200)
C%(10,20)=5
c%(100,200)=10

on s'entend avec un redim plus grand on ne perd rien.

j'utilise un tableau comme ça

definition d'un tableau

dim tbl(1,2)

puis je créé un élément que j'enregistre dedans.
tbl(1,0)=Numéro de l"élément
tbl(1,1)=X coordonnées
tbl'1,2)=y coordonnées
Création d'un nouvel élément
redim tbl(2,2)
tbl(2,0)=Numéro de l"élément
tbl(2,1)=X coordonnées
tbl(2,2)=y coordonnées

Voila un exemple d'utilisation du " Redim" pour moi.

Oui, je comprends, c'était pour te taquiner un peu.
Mais ton exemple me fait penser à l'utilisation de liste, car il ressemble à un empilage et on ne gère pas le nombre total d'éléments:

Code:

dlist 1
add_item 1, str$(N1): rem Numéro de l"élément
add_item 1, str$(X1): rem X coordonnées
add_item 1, str$(Y1): rem Y coordonnées
add_item 1, str$(N2): rem Numéro de l"élément
add_item 1, str$(X2): rem X coordonnées
add_item 1, str$(Y2): rem Y coordonnées

Juste pour alimenter la réflexion:
Si tu veux faire un REDIM sans perte de données, cela n'est envisageable que si tu assumes que l'emplacement physique des données existantes n'a pas changé, ou alors les données existantes doivent être recopiées, et temporairement, on aurait les deux tableaux en mémoire.

Exemple:

Code:

dim a%(1,9)
a%(1,3) = 17

redim a%(2,19)
print a%(1,3) : ' <------------ il n'y a aucune chance de retrouver 17 ici
print a%(0,13) : ' <------------ ici, on a des chances de retrouver 17

Je veux dire par là que la conservation des données est directement liée à l'ordre dans lequel sont stockées les cellules du tableau. Ce que j'ai indiqué ci-dessus, serait valable dans d'autres basics, et c'est valable en Fortran, par exemple. Je ne sais pas pour Panoramic, car je n'ai aucun moyen de vérifier. On ne peut pas obtenir l'adresse d'un tableau (dommage d'ailleurs), et c'est sûrement lié à la méthode interne d'allocation de mémoire pour un tableau, tout comme on ne peut pas obtenir l'adresse d'une cellule d'un tableau. Impossible alors, dans une DLL, de faire un dump de la mémoire du tableau. On peut obtenir l'adresse d'une variable simple, et "dumper" le contenu des emplacements mémoire suivants, mais le résultat n'est pas concluant. Je l'ai fait, et j'ai bien retrouvé mes valeurs, seulement elles sont mélangées avec d'autres informations. C'est comme si les données pures ne soient pas dans un espace physiquement distinct des tables de symboles etc. Fais l'essai avec ceci:

Code:

dim i%,a%(1,2),res%
i% = 123
a%(0,0) = 900
a%(0,1) = 901
a%(0,2) = 902
a%(1,0) = 910
a%(1,1) = 911
a%(1,2) = 912
res% = dll_call1("Dump",adr(i%))

et dans la fonction Dump de la DLL, tu affiches les valeurs de l'adresse fournie ainsi que des 15 ou 20 cellules suivantes... Le résultat est intéressant !

Jack
c'est exact,j'utilise un list pour debug que je passe en Dlist après.
Mais c'est quand meme plus long surtout avec du graphic.

Citation :

On ne peut pas obtenir l'adresse d'un tableau (dommage d'ailleurs), et c'est sûrement lié à la méthode interne d'allocation de mémoire pour un tableau, tout comme on ne peut pas obtenir l'adresse d'une cellule d'un tableau. Impossible alors, dans une DLL, de faire un dump de la mémoire du tableau. On peut obtenir l'adresse d'une variable simple, et "dumper" le contenu des emplacements mémoire suivants, mais le résultat n'est pas concluant.

Les variables sont mémorisées dans des tableaux dynamiques: leurs valeurs et leurs caractéristiques (le type, des pointeurs sur les premiers éléments dans le cas de tableaux, vers les tableaux de valeurs, eux même dynamiques, etc) et c'est une usine à gaz.
Ce qui fait que des instructions comme ADR, FREE ou REDIM sont extrèmement pénibles à coder.

Cela vient du temps où je n'imaginais absolument pas que les utilisateurs voudraient connaître les adresses des variables, d'une époque où je développais un langage pour les programmeurs du dimanche.

Un jour, j'éditerai un guide pour accéder aux éléments des tableaux, quand par exemple je ferais les plug-ins.
Ouille, ouille, j'ouvre une autre débat ...

En fait, je suis un troll.

Merci de ces précisions ! Ca aide à mieux comprendre. Je me doutais bien de quelque chose de ce genre, au vu des résultats obtenus avec les méthodes de voyeur.

Tracaille à ton rythme et continue comme ça - je trouve que l'ensemble avance très positivement, dans une direction qui me plait...

Citation :

Un jour, j'éditerai un guide pour accéder aux éléments des tableaux, quand par exemple je ferais les plug-ins.

Je crois que tu as un peu maso Jack...

Quand au Redim, l'utilisation d'une DLIST remplace avantageusement les tableaux.

Par contre, la seule chose qui manque pour les (D)LIST c'est une fonction d'édition d'un élément.
On a :

• ITEM_ADD N,s$
  
• ITEM_DELETE N,id
  
• ITEM_INSERT N,s$
  
• ITEM_READ$(N,id)
  

mais on a pas :

• ITEM_EDIT$ (N,id,s$)

-> on est obligé de faire un ITEM_READ, ITEM_INSERT et un ITEM_DELETE pour simuler cette fonction: c'est un peu lourd....

Pour moi aussi, ça avance dans le bon sens et encore bravo à Jack pour mener tous ses avancement de front pendant ses loisirs
PS: Jack, si tu as besoin d'aide, tu peux toujours demander, nous serions plusieurs à vouloir t'aider dans la mesure de nos moyens. Donnes nous juste des consignes (orientation, règle de base de ce que l'on a à faire) et nombreux sont ceux qui voudront t'aider parmi les actifs du forum (Nardo, Klaus, Cosmos 70, JL35 le font déjà en aidant un paquet de fois sur les problèmes rencontrés)

L'essentiel pour moi ce sont les Subs indépendantes avec passage de paramètres, j'en rêvais, Jack l'a fait. Ce n'est pas une révolte, Sire, c'est une révolution !
Et aussi la levée de la limitation des tailles de fontes à 30, ça va bien m'arranger.

D'accord avec Nardo, une possibilité de modifier individuellement un élément de List (plutôt que de faire Delete puis Insert).
Et quelques bricoles sur les chaînes, par exemple INSTR: une option qui cherche à partir d'un indice donné (pour faire une recherche de proche en proche), et un RevInstr, Instr inversé qui parte de la fin de la chaîne.
Mais c'est juste pour le cas où Jack ne saurait pas quoi faire de ses loisirs...

Nardo
dlist remplace les tableaux mais pas avantageusement.
Cela prend trop de temps surtout si tu l'utilise pour des jeux avec du graphic dedans.
Si on pouvait au moins avoir une copie de tableaux de dimensions plus grandes
ex
copy c%(1,10),b%(100,10)
ce serait très bien.

@Jack:
Il me semble que tu as mentionné l'arrivée prochaine de la copie d'un picture dans le presse-papier.

Est-ce que tu pourrais étendre cela à l'image d'une form ? Par exemple en spécifiant le numéro d'objet de la form ? ou mieux, en spécifiant le handle de la form, ou le handle du canvas de la form, ce qui permettrait de spécifier également un handle d'une form autre que celle de Panoramic ?