Problème avec instruction ADR()

Bonsoir,

J'essaie d'utiliser l'instruction adr() et j'obtiens des résultats bizarres.

J'ai utilisé l'exemple dans le manuel de référence:

Code:

dim a%,b,c$

print adr(a%)
print adr(b)
print adr(c$)

end

J'ai essayé avec plusieurs variables de type flottant, l'adresse est toujours 0. J'ai essayé d'initialiser le string, mais le résultat est toujours un message d'erreur. En fait, cela semble marcher pour le type integer seulement. Est-ce que je me trompe ?


et j'obtiens:

Code:

10781732
0

suivi de la fenêtre d'erreur de Panoramic avec le message:
" is not a floting point value.

Effectivement, même chose, ça ressemble fortement à un bug !

Il y a effectivement un bug dans ADR() , qui avait déjà été signalé par JL35:
https://panoramic.1fr1.net/a-l-aide-f6/floating-point-value-t542.htm

Bon soir,

Oui, j'avais vu ce message.

Comme je l'ai dit, il n'y a pas le feu. Mieux vaut que tu prennes le temps pour le faire sans être stressé que de te sentir pressé d'agir par les adeptes impatients - tout le monde en sortira gagnant finalement.

Je suis tombé dessus par hasard, car tout heureux d'avoir réussi à régler mon problème d'accès aux DLL, je voulais essayer de retourner des strings ce qui était l'objectif.

Par le petit bout de code suivant:

Code:

dim i%,j%,k%,l%,m%

print adr(i%)
print adr(j%)
print adr(k%)
print adr(l%)
print adr(m%)

end

j'ai découvert que des entiers "successifs" au niveau du programme sont en fait "ecartés" de 72 octets en mémoire. Cela veut-il dire que Panoramic mélange l'espace pour les variables avec d'autres informations ?

Et question plus importante: lorsque adr(x$) marchera, est-ce que l'on pourra écrire dans l'espace à partir de cette adresse, un peu comme ceci:
i% = dll_call2("ma_routine_DLL",adr(a$),len(a$))
Dans ce cas, je retournerais un code retour dans i% et le véritable résultat string dans a$ sur une longueur de len(a$). Est-ce que je peux envisager cela ?

Bon courage pour la suite de Panoramic !

Les DLL avaient été codées dans l'urgence.

Tim me les avait demandées le 28 mars 2009, et il avait obtenu des premières fonctions opérationnelles le 30 mars 2009 (après 2 jours de codage forcené).
Depuis, plus aucune nouvelle ...

Je vais remanier toutes ces fonctions:
CALL_DLLn(), ADR(), HANDLE(), HANDLE_CANVAS() pour les rendre plus faciles à utiliser.
Je ferai ça calmement, en prenant mon temps, mais surement.

Pour le moment ADR() d'une variable entière fonctionne, mais ne fonctionne pas pour des variables réelles ou string.

Les adresses des variables entières en effet ne sont pas juxtaposées car plusieurs informations sont stockées: la valeur, le nom, le type (1=entier, 2=chaine, 3=réel, 4=entier à 1 indice, 5=chaine à 1 indice, 6= réel à 1 indice, 7=entier à 2 indices, 8=chaine à 2 indices, 9= réel à 2 indices), etc...

L'exemple que tu donnes sera tout à fait réalisable quand ADR(a$) fonctionnera:

Code:

i% = dll_call2("ma_routine_DLL",adr(a$),len(a$))

La plupart des DLL codées en C++ et qui utilisent des strings utilisent en fait un pointeur sur ce string. C'est le rôle de adr(a$) qui est un véritable pointeur sur a$.
Attention, en C++ un string se termine par la valeur 0.

Oui, j'ai vu la terminaison par on octet 0, dans Delphi aussi, dans certains types de strings.

J'attendrai la version opérationnelle de ces routines; je mets ma DLL au point en attendant, en utilisant Delphi.Je suis content d'avoir apparemment saisi correctement l'utilisation de ces fonctions, et ma conception de la DLL n'aura donc pas besoin d'être changée.

Merci pour tes efforts, et je t'approuve entièrement lorsque tu dis vouloir prendre ton temps et le faire calmement - je crois que c'est la seule façon de toucher à ces éléments délicats.

Cordialement Klaus