Fonction ADR pour adresse d'un string

La foncton adr(n%) marche très bien, mais j'aurais une grande utilité d'appliquer cette fonction à un string, pour pouvoir passer un string en paramètre à une DLL ou récupérer un résultat string d'une DLL. J'aimerais pouvoir faire ceci:

Citation :

dim nom$,lnom%,resultat$,lresultat%,n%
nom$ = "test.dat"
lnom% = len(nom$)
resultat$ = string$(1000," ")
lresultat% = len(resultat$)
n% = DLL_call4("ma_fonction_dll",adr(nom$),lnom%,adr(resultat$),lresultat%)
print resultat$

Jack, est-ce que c'est un gros travail ou il s'agit juste d'un oubli dans l'implémentation ? Ou serait-ce plus simple de créer une nouvelle fonction descr(v) qui retournerait un entier 32 bits contenant l'adresse d'un block mémoire de 3 entiers 32 bits contenant le type de la variable v, l'adresse de la partie data de la variable v et la longueur en octets de cette partie data, quelque soit le type de la variable ?

Dans ce cas, mon petit exemple se réduirait à ceci:

Citation :

dim nom$,resultat$,n%
nom$ = "test.dat"
resultat$ = string$(1000," ")
n% = DLL_call2("ma_fonction_dll",descr(nom$),descr(resultat$))
print resultat$

Je sais, le problème de la fonction adr() a été évoqué il y a longtemps, mais j'aimerais vraiment pouvoir passer des strings à une DLL et les en sortir !

Normalement il est bien prévu dans la doc que la fonction ADR() retourne l'adresse de TOUS les types de variables, y compris chaîne (sauf les éléments de tableaux), ça n'a pas été réparé ? si non, c'est un bug en attente.

Code:

DIM a$, b%
a$ = "Au clair de la lune"
b% = 12
PRINT ADR(a$)
PRINT ADR(b%)
END

Effectivement, ça ne marche pas pour la variable chaîne ! il y a affichage d'une adresse dans un message...

Eh oui, c'est ce que j'ai vu. Je l'avais déjà signalé il y a un certain temps, et Jack avait dit qu'il s'en occuperait à l'occasion. Pour le moment, il n'a apparemment pas eu le temps, ce que je comprends. Ceci dit, je reste bloqué dans ma réalisation: mes fonctions marchent bien hors Panoramic, mais le lien n'est pas possible à cause du défaut de adr(a$)... Alors, j'attends encore.

Ça à dû passer à l'as dans la todo list... il est vrai qu'elle est immense...

Dès que la fonction adr(a$) marchera, je pourrai mettre à disposition de tous ma nouvelle routine d'envoi de messages texte d'un programme Panoramic à un autre. Ca fonctionnne et je peux le mettre dans ma DLL, mais il faut que je puisse capter le texte à envoyer, ainsi que le nom du destinataire (qui est caption(0) du programme de destination). Il y a aussi une fonction de réponse au message reçu.

J'ai même résolu le problème de génération d'un évènement sur réception du message: un sous-programme Panoramic se déclenchera sur réception de chaque message !

J'ai comme l'impression que tu demandes que ADR(A$) fonctionne ...
OK, je regarde ce bug.

Un grand merci pour l'attention que tu portes à mes suggestions !

Lorsque cette fonction marchera, je pourrai avoir accès aux strings en entrée et sortie d'une DLL, en passant en paramètres quelque chose comme ceci:

Citation :

dim etat%, dest$, mes$

dest$ = "MonProgrammeDeDestination"
mes$ = "MonMessageTexte"
etat% = DLL_call4("SendToPanoramic",adr(dest$),len(dest$),adr(mes$),len(mes$))

Le bug est corrigé dans la version instantanée du 24/04/2010.

Excellent ! Je m'y mets de suite ! Merci !

@Jack:

J'ai passé un peu de temps à comprendre commend fonctionne adr(a$) !

En effet, contrairement à adr(i%) qui donne directement l'adresse de la partie data, adr(a$) donne l'adresse d'une sorte de descripteur qui contient une adresse aui pointe vers le texte proprement dit du string.

Une fois que j'avais compris cela, la suite s'enchaînait logiquement.

Comme premier résultat, j'ai mis une nouvelle fonction dans ma DLL permettant de changer l'imprimante par défaut de windows; la gestion de messages entre processus Panoramic suivra sous peu.

Citation :

En effet, contrairement à adr(i%) qui donne directement l'adresse de la partie data, adr(a$) donne l'adresse d'une sorte de descripteur qui contient une adresse aui pointe vers le texte proprement dit du string.

?????
Je ne comprends pas.
ADR(a$) donne l'adresse du 1er caractère (existant ou pas si a$="") de a$.

La raison est la suivante:

Pour prendre un string passé en paramètre avec adr(s$), je fais ceci en Delphi:

Code:

function PrinterFunction(const f:integer; phnd: Pinteger; chnd: Pinteger; opt1: integer; opt2: integer; opt3: integer): integer; stdcall; export;

var
        pstr: PString;


                pstr := PString(opt1);
                printer.Canvas.Font.Name := pstr^;

Et il me semble donc qu'il y a une indirection de plus, c'est-à-dire l'adresse reçue en paramètre est l'adresse où se trouve l'adresse de a$. Mais n'ayant pas une grande expérience en Delphi, je peux me tromper.

De toutes façon, avec cette construction, ça marche et je peux aussi retourner les strings en utilisant cette construction. Alors, mon message c'était juste pour comprendre.

Cependant, est-ce que tu as eu le temps de regarder s'il est possible d'étendre la fonction adr() pour passer l'adresse du début de la partie data d'un tableau d'entiers, de la même manière que celle du début d'un string ? Avec une syntaxe du type

Code:

dim x%(10),res%

res% = dll_call1("MaRoutine",adr(x%())

ou une autre fonction du type adr_array(x%) ?

Je sais qu'il y a un risque de corruption des données, mais ce risque existe de toutes façon dès qu'on passe une adresse à une DLL...

Il me semble qu'en Basic également dans le cas d'une variable chaîne c'était de l'adressage indirect, que ADR(a$) donnait l'adresse d'un pointeur vers la chaîne et la longueur de celle-ci.
Ici je ne sais pas, Jack a l'air de dire que c'est direct, et je me demandais justement s'il est possible d'exploiter cette adresse autrement qu'en paramètre de dll, c'est à dire aller voir en mémoire ce qu'il y a à l'adresse rendue par adr(), en somme l'équivalent de PEEK(adresse) en basic.

Pour simuler un peek, cela ne me semble pas possible en Panoramic directement. Mais avec une fonction DLL, c'est très simple, et je l"ai fait pour mettre ma DLL au point. Si cela t'intéresse, je rajoute des peek et poke à ma DLL - tiens-moi au courant.

Oui, je me souviens de peek( ), c'était génial,
j'en ai fait des choses avec ça !
Dommage que ça n'existe pas en panoramic.

Il faut apporter une précision au sujet de peek et poke. Dans les anciens Basic, on adressait la mémoire physique directement. Ce n'est plus possible avec les Windows modernes. On travaille en adressage virtuel avec des adresses de 32 bits, voire 64 bits pour certaines versions, ce qui donne un espace d'adressage gigantesque qui n'a plus rien de commun avec la mémoire physique, fusse-t-elle grande.

Le système gère les allocations de morceaux de mémoire de façon interne, et ni Delphi ni Panoramic ne peuvent savoir où se trouvent physiquement les morceaux de mémoire. L'adresse 0 peut très bien être en memoire physique mais certainement pas à l'adresse 0 physique, ou alors se trouver dans le fichier de pagination...

Donc, un peek ne peut être imaginé que sur une adresse que nous fornit Panoramic, à l'aide de la fonction adr(). Et là, on connaît forcément le contenu puisqu'il s'agit de nos variables...

L'utilité de peek et poke n'est donc pas très grande en-dehors de mes petites fonctions de mise au point de ma DLL - c'est la raison pour laquelle je ne les avais pas incluses dans la version publiée.

Effectivement,je sais bien que l'adressage en QBasic était physique (0 à 65535) donc très simple. Avec les mémoires gigantesques actuelles, la pagination, la gestion dynamique, etc. c'est beaucoup plus compliqué, et comme tu dis je me demande finalement si ce serait bien utile.

Mon arrière-pensée de départ était une espèce de programme de debug, noter l'adresse de certaines variables au départ pour pouvoir lire et tracer leur valeur à des points de passage choisis.
Mais bon, c'était un peu une idée en l'air, et on doit pouvoir faire ça avec les outils disponibles (Message notamment).
En ce qui me concerne Klaus, je te remercie mais tu peux laisser tomber, tant que je n'aurai pas les idées plus claires !