Renvoi de paramètres par une sub

On l'a vu dans un autre post ('Vos sources...'), le renvoi de paramètres par une sub n'est pas évident.
Du fait que les variables passées en paramètres à la sub y deviennent des variables locales et que l'appelant ne peut pas récupérer leur modification éventuelle au retour.
Silverman a proposé une solution élégante, une sub qui exploite un nom de variable passé en paramètre, mais ça fait une sub (conséquente) appelée systématiquement par une autre sub...

On pourrait imaginer comme j'ai dit par ailleurs de passer les résultats dans le presse-papier windows, mais aussi dans une Dlist, commune à toutes les subs du programme, déclarée sous forme de variable dans le programme principal, et dont il suffit de connaître le nom symbolique (toujours le même).
Les résultats seraient rendus sous forme séquentielle, en alphanumérique, dans la Dlist.

Par exemple, une sub qui donne les dimensions en pixels d'une image (deux paramètres en retour: largeur et hauteur):

Code:

DIM f$,w%,h%,retsub%
f$ = "C:\GRAPH\JPG\goldgate.jpg": ' image quelconque
retsub% = 5000: DLIST retsub%: ' DLIST commune de renvoi des paramètres des Subs en retour
' ...
DimJpgBmp(f$)
w% = VAL(ITEM_READ$(retsub%,1)): h% = VAL(ITEM_READ$(retsub%,2))
Message "Image= "+ STR$(w%)+" x "+STR$(h%)
TERMINATE


SUB DimJpgBmp(f$)
   ' Image JPG ou BMP exclusivement, dimensions rendues séquentiellement dans la Dlist retsub%
   DIM_LOCAL wi%,hi%,fm$: fm$ = "C:\TEMP\Provy.bmp"
   PICTURE 1099: HIDE 1099: FILE_LOAD 1099,f$: FILE_SAVE 1099,fm$: DELETE 1099
   FILEBIN_OPEN_READ 1,fm$
      FILEBIN_POSITION 1,18: wi% = FILEBIN_READ(1)+256*FILEBIN_READ(1)
      FILEBIN_POSITION 1,22: hi% = FILEBIN_READ(1)+256*FILEBIN_READ(1)
   FILEBIN_CLOSE 1
   FILE_DELETE fm$
   IF OBJECT_EXISTS(retsub%)=0 THEN DLIST retsub%
   CLEAR retsub%: ITEM_ADD retsub%,STR$(wi%): ITEM_ADD retsub%,STR$(hi%)
END_SUB

Il suffit que toutes les subs concernées connaissent le nom 'retsub%'.
Inconvénient (?): tous les paramètres sont passés sous forme alphanumérique, il faut donc convertir les paramètres numériques dans les deux sens, comme ici.

Il sera beaucoup plus simple, plus élégant et plus efficace si Panoramic permet la transmission de paramètres par adresse en plus de paramètres par valeur.

Rappel  de transmission de paramètres

1) Transmission de paramètres par valeur :
Panoramic dépose sur la pile une copie de chaque paramètre de type « valeur » transmis.
Une fois la routine exécutée, lors du retour au programme appelant, le système éliminera les paramètres de la pile.
Ces valeurs sont en fait des copies temporaires, les valeurs d’origine connues du programme appelant ne sont pas modifiées par l’exécution de la procédure.
2) Transmission des paramètres par adresse :
Lorsqu’on désire qu’entre le programme appelant et la procédure, la transmissions de paramètres se réalise dans les deux sens, c’est-à-dire que la procédure puisse elle aussi transmettre des informations au programme appelant,  on doit alors employer la transmission de paramètres par adresse. Le système ne dépose pas une copie du continue sur la pile, mais il travaille directement en mémoire sur la variable. Cela provient de ce que la procédure reçoit l’adresse mémoire à laquelle figure le continu de la variable.
De cette façon, le sous-programme est en mesure de modifier la valeur d’une variable et de transmettre au programme appelant cette valeur modifiée.
Malheureusement, Panoramic ne permet pas (encore) la transmission de paramètres par adresse.

Entièrement d'accord avec toi papydall... seulement actuellement ce n'est pas le cas et il faut bien trouver une solution, en attendant mieux.

C'était l'esprit de mon post, un palliatif.

@JL35
je reconnais là le système de pile. Mais comment savoir dans quel ordre sont empilé les données? Il n'est pas impossible d'inverser w% et h% par erreur au moment de dépiler les données au retour de la sub.

@papydall
le point 2) n'est pas possible directement, et c'est bien dommage. Mais on a la fonction ADR; On peut passer passer une adresse à la sub de cette manière là.
Ex. en pseudo-code:

Code:

float=1.23456
arrondi(adr(float),2)
print float

END
sub arrondi(adr_param1%,decimales%)
dim_local float,result
   float=PEEK4(adr_param1%)   :' récupère une valeur
   result=...   :' traitement
   POKE4 adr_param1%,result   :' écrit une valeur
end_sub

Certes silverman, mais le programme appelant doit évidemment bien savoir dans quel ordre sont rendues les données, ce qui doit être écrit en commentaire en tête de la sub.
S'il y a une inversion de données, c'est une erreur du programmeur ! une fois le programme écrit correctement il ne peut plus y avoir d'erreur.

Je reconnais bien volontiers que ce n'est pas une solution idéale, une idée comme ça, c'est tout, en attendant mieux.

PS c'est quoi les PEEK4 et POKE4 dans ton exemple ?

Je pense que
PEEK4,   c’est pour lire 4 octets
POKE4,   c’est pour écrire 4 octets
Il faut les coder en SUB, je suppose.

Tout à fait exact papydall, c'est comme ça que je procédais avant de créer VARIABLE_FILL.