Problème avec SearchStringList.

Bonjour.

@Jack et Klaus.

Pouvez-vous m'expliquer le pourquoi de l'impossibilité de compiler le code suivant ?

Merci.

Je cite Jack:

La ligne suivante compile mais produit un plantage à l'exécution:

Code:

x%=dll_call3("SearchStringList",object_internal(6),adr(element$),adr(te$))

C'est une ligne de planetarium qui m'a donné du fil à retordre dans le compilateur.

Avec l'interpréteur, elle fonctionne et donne le résultat attendu.

Avec le compilateur, elle compile parfaitement, mais à l'exécution, elle ne donnait pas le résultat attendu et il m'est même arrivé d'avoir un plantage.

Voici pourquoi.
DLL_CALL3 appelle la fonction SearchStringList de la DLL de Klaus KGF.
On passe en paramètres à cette fonction deux adresses de chaînes de caractères : adr(elemets$) et adr(te$) dans ton exemple.
Or, cette fonction ne se contente pas de retourner une valeur, comme toute fonction, mais en plus, elle modifie la valeur du deuxième paramètre. Après son appel, la valeur de la variable te$ est modifiée.
Cela fonctionne très bien pour l'interpréteur car Klaus a très bien repéré comment était codée une chaîne de caractères en mémoire et il sait à quel endroit à partir de l'adresse, la chaine de caractère se situe exactement.

Mais ce mécanisme, qui est spécifique à l'interpréteur, ne fonctionne plus avec le compilateur, car avec le compilateur, les chaînes de caractères ne sont pas stockées en mémoire de la même façon que pour l'interpréteur. La fonction va donc écrire une chaine de caractères au mauvais endroit, avec toutes les conséquences que cela provoque.

Comme Klaus n'était pas présent sur le forum cet été et que je tenais à compiler le planétarium pour voir ce que cela donnerait, j'ai "bidouillé" le compilateur pour que cela fonctionne. J'ai "leurré" la fonction SearchStringList de la DLL de Klaus en lui envoyant non pas les adresses des chaines de caractères comme c'est structuré dans l'interpréteur, mais les adresses des variables telles qu'elles résident en mémoire une fois compilées.
Autant dire tout de suite que ce n'est pas portable, tout autre appel de DLL_CALL3 ne fonctionnerait pas. Mais dans planetarium, DLL_CALL3 n'est utilisé que pour des appels à SearchStringList.
Pour le moment, la fonction DLL_CALL3 du compilateur a été modifiée pour faire fonctionner SearchStringList, mais ce n'est pas viable, cela reste une "bidouille", une réparation de fortune qui ne marche que pour planetarium.

Bonsoir.

Merci Jack, cela a le mérite d'être clair.

Cependant, je pense qu'une commande native de recherche d'un item dans un objet Dlist serait la bienvenue.
Chose que je réclame depuis longtemps.

Cela simplifierait grandement mon logiciel.

Je découvre de problème, et le "bidouillage" que tu as dû faire pour tenter de résoudre cela. Je suis désolé d'avoir causé de tels problèmes.

Or, sache que SearchStringList est loin d'être la seule fonction de KGF.dll modifiant une variable de type string, et pas seulement des fonctions avec 3 paramètres ! JE peux y apporter une solution globale si tu me donnes deux renseignements:
1. comment est-ce que je détecte dans la DLL que la DLL avec un programme compilé (chose que j'avais déjà demandée...)
2. comment interpréter adr(s$) dans un programme compilé, et comment est stockée la chaîne de caractères ?

Avec ces deux renseignements, je peux faire de sorte que la DLL s'adapte aux deux cas de figure.

Pedro a écrit:

je pense qu'une commande native de recherche d'un item dans un objet Dlist serait la bienvenue.

Tu demandes de trouver le rang d'un item?
Si tu pouvais préciser ta demande, je regarderai la possibilité de faire une recherche.

Bonsoir.

@Jack.

Un exemple concret:

Mon fichier trié 'dico_français_espagnol.txt' contient plus de 1 million d'items.
La ligne n° 148366 contient l'item suivant:

chien;ms;perro;ms;animal

Après ceci:

Code:

dim x%, chaine$

dlist 1
file_load 1,"dico_français_espagnol.txt"

chaine$="chien;"

Une commande x%=Find(n° Dlist,chaine$) renverrait donc 148366, ou 0 si l'élément n'existe pas.

Merci de la suite.

@Jack:

N'y aurait-il pas un endroit univoque à consulter pour savoir si le programme appelant contient l'interpréteur (est fait à partir de Panoramic_Editor.exe ou à partir de Panoramic.exe) ? Par exemple un endroit précis dans le fichier EXE ayant appelé la DLL ? Cela me permettrait de déterminer à coup sûr d'être dans un contexte interprété ou dans un contexte compilé.

Peux-tu me donner la structure en mémoire d'une variable dont la valeur adr(n%), adr(a%) et adr(s$) est passée, dans le cas d'un programme compilé ?

Avec ces deux informations, je peux adapter KGF.dll pour pouvoir être appelé quelque soit le contexte. C'est important, car à des dizaines d'endroits, peut-être même des centaines d'endroits, j'utilise ces adresses pour accéder, aussi bien en lecture qu'en écriture, à des données doit je crois connaître la disposition en mémoire. Et j'aimerais bien que ma DLL ne soit pas uniquement réservée à l'interpréteur, si c'est possible.

En tout cas, modifier DLL_CALL3 uniquement, spécifiquement pour l'appel d'une seule fonction de KGF.dll, cela ne résoud malheureusement rien. Désolé...

EDIT

N'ayant pas le compilateur ni tout ce qui va avec, est-ce que quelqu'un pourrait le poster l'exé issu du compilateur pour le code Panoramic suivant:

Code:

dim n%, f, s$
n%=1234567
f = 7654321
s$ = "aAbBcCdD"
end

Par comparaison avec un EXE généré par le compilateur, utilisant le même code source, je pourrai déterminer le moyen de détecter à coup sûr si je suis avec une version compilée ou interprétée.

Est-ce que quelqu'un avec un compilateur Panoramic voudrait bien me faire parvenir un EXE compilé à partir du source suivant:

Code:

dim n%, f, s$
n%=1234567
f = 7654321
s$ = "aAbBcCdD"
end

Ca pourrait être pour moi, le moyen de déterminer comment détecter si l'on est appelé à partir d'un programme compilé ou interprété, en comparant avec un EXE généré par Panoramic_Editor.

Merci d'avance !

Salut Klaus
J’ai compilé ton code avec la version 0.9 beta 10 du 29/08/2017.
Tu trouveras sur mon webdav  le résultat sous POURKlaus.rar

EDIT
Tu trouveras également PANORAMIC_COMPILER_EDITOR.zip

J'ai trouvé un moyen de transmettre une chaîne de caractères dans un mémo Panoramic, en passant soit handle(memo%) soit object_internal(memo%) à la place de adr(variable$), comme paramètre dans SearchStringList et dans toute autre fonction retournant des chaînes de caractères dans une variable Panoramic, via son adresse. Rien que dans un seul module source de KGF.dll, cela concerne les fonctions suivantes:
GetTreeViewInformation
SearchStringList
ReadStringList
ReadStringListValue
RichEditStringSave
RichEditGetLine
GetSelectedRichEditText
GetSelectedRichEditAttributes
SpiderWebAxisLabel
HistogramAxisLabel
HistogramPointLabel

Faudra que je recherche dans d'autres modules - je sais qu'il y en a d'autres. En plus, ils n'ont pas tous le même nombre de paramètres.Par conséquant, il est important de trouver une solution globale au problème, et elle pourrait être le remplacement de la variable string par un mémo caché dont on utilise TEXT$ pour récupérer la variabel, ou on travaille directement dans le mémo.

Dans tous les cas de figures, il y a des changements importants à faire. Aucun changement ne sera nécessaire pour les programmes qui continueront à tourner sous l'éditeur ou générés avec Panoramic.exe. Ils pourront continuer à utiliser une variable string. Pour ceux qui seront compilés, il faudra passer un mémo, préférablement par HANDLE(memo%). Ils pourront continuer à tourner également dans l'éditeur, puisque dans la DLL je sais faire la différence entre un handle de mémo et une adresse de chaine de caractères, et je sais réagir en conséquence.

J'ai modifié le module contenant les fonctions ci-dessus. Dans toutes ces fonctions, pour recevoir la chaîne de caractères que la DLL veut retourner, on peut maintenant passer, indifféremment, une des 3 valeurs suivantes:
adr(variable$) (comme avant)
object_internal(memo%)
handle(memo%)

Dans le premier cas, comme avant, on reçoit le texte dans une variable string (Panoramic_Editor uniquement, pas en version compilée !)
Dans les deux autres cas, le texte est déposé dans le mémo mentionné en remplaçant son contenu précédent. Ce mémo peut bien sûr être caché.

Voici une démo, à l'aide d'une petite fonction (non documentée) qui ne sert qu'à ça:

Code:

' test_Retourner_String_De_KGF_dll.bas
dim res%, s$           
alpha 11 : top 11,10 : caption 11,"OBJECT_INTERNAL"
memo 1 : bar_both 1 : top 1,30
alpha 12 : top 12,10 : left 12,width(1) + 10 : caption 12,"HANDLE"
memo 2 : bar_both 2 : top 2,30 : left 2,width(1) + 10
alpha 13 : top 13,height(1) + 40 : caption 13,"variable$"
alpha 3 : top 3,height(1) + 60 : font_bold 3 : font_color 3,0,0,255
dll_on "KGF.dll"
res% = dll_call1("TestStringFromDll",object_internal(1)) 
res% = dll_call1("TestStringFromDll",handle(2)) 
s$ = string$(255," ")
res% = dll_call1("TestStringFromDll",adr(s$)) 
caption 3,trim$(s$)
end

Voici le résultat:


Qu'est-ce que vous en pensez ? Et pour Jack, voici comment c'est implémenté:

Code:

  procedure CopyStringToPanoramic(s: string; par: integer);
  var
    p1, p2: pchar;
    n: integer;
    memo: TMemo;
    s1: string;
    control: TWinControl;

    function GetClassName(Handle: THandle): String;
    var
      Buffer: array[0..MAX_PATH] of Char;
    begin
      Windows.GetClassName(Handle, @Buffer, MAX_PATH);
      Result := String(Buffer);
    end;

  begin
    if par=0 then exit;
    try
      memo := TMemo(par);
      if memo.ClassName='TMemo' then begin
        s1 := s;
        memo.Text := trim(s1+' ');
        exit;
      end;
    except
    end;

    try
      if GetClassName(par)='TMemo' then begin
        s1 := s;
        SendMessage(par,WM_SETTEXT,0,integer(pchar(s1)));
        exit;
      end;
    except
    end;

    p1 := nil;
    n := length(s);
    if n>0 then p1 := @s[1];
    p2 := pchar(pinteger(par)^);
    while p2^<>#0 do begin
      if n>0 then begin
              if p1<>#0 then begin
                p2^ := p1^
              end else begin
                dec(p2);
              end;
            end else begin
              p2^ := #32;
            end;
      inc(p1);
      inc(p2);
      dec(n);
    end;
  end;

function TestStringFromDll(par: integer):integer; stdcall; export;
var
    test: string;
begin
  result := -1;
  test := 'Voici un texte'+#13#10+'venant de KGF.dll';
  CopyStringToPanoramic(test,par);
  result := 0;
end;
exports TestStringFromDll;

A ton avis, ce sera bon pour la version compilée ?

@Papydall:
Merci beaucoup ! J'ai téléchargé cela et je vais l'analyser !

Grâce à Papydall, j'ai pu créer une nouvelle fonction, permettant de savoir si l'on est dans unn environnement interprété ou compilé. En fait, cet état est détecté immédiatement au chargement de la DLL et conservé dans un variable interne. La nouvelle fonction ne sert qu'à retourner cette variable.

En voici une démo:

Code:

dim res%
dll_on "KGF.dll"
res% = dll_call0("IsPanoramicCompiled")
if res%=1
  message "Compilé"
else
  message "Interprété"
end_if
end

Chez moi, ça marche. Ce serait intéressant si les heureux utilisateurs du compilateur pouvaient essayer cela, chez eux...

La version est sur mon site internet, accessible via ma signature.

Bonjour.

@Klaus.

J'ai téléchargé le compilateur Panoramic, ainsi que la dernière version de KGF.DLL.

Le code permettant de déterminer le type de l'environnement (interprété ou compilé) fonctionne parfaitement sous Win 10.

Chouette ! Merci, Pedro !

J'ai mis une version corrigée de KGF.dll sur mon site, accessible via ma signature. Maintenant, les fonctions suivantes peuvent retourner une information de type chaîne de caractères, selon 3 modes indifféremment:
handle(variable$) <== non compatible version compilée !
object_internal(memo%)
handle(memo%)

Voici les fonctions concernées:
GetTreeViewInformation
SearchStringList
ReadStringList
ReadStringListValue
RichEditStringSave
RichEditGetLine
GetSelectedRichEditText
GetSelectedRichEditAttributes
SpiderWebAxisLabel
HistogramAxisLabel
HistogramPointLabel
CreateCaptcha

D'autres fonctions suivront. Si vous rencontrez un problèem avec une fonction quelconque en version compilée, faites-le-moi savoir - je ferai le nécessaire.

Bonjour.


Je pense que tu voulais dire:

Code:

adr(variable$)

au lieu de:

Code:

handle(variable$)

Oups... Merci !

Voici la version corrigée:
J'ai mis une version corrigée de KGF.dll sur mon site, accessible via ma signature. Maintenant, les fonctions suivantes peuvent retourner une information de type chaîne de caractères, selon 3 modes indifféremment:
adr(variable$) <== non compatible version compilée !
object_internal(memo%)
handle(memo%)

Voici les fonctions concernées:
GetTreeViewInformation
SearchStringList
ReadStringList
ReadStringListValue
RichEditStringSave
RichEditGetLine
GetSelectedRichEditText
GetSelectedRichEditAttributes
SpiderWebAxisLabel
HistogramAxisLabel
HistogramPointLabel
CreateCaptcha

Le code permettant de déterminer le type de l'environnement (interprété ou compilé) fonctionne parfaitement sous W7.
Danke Klaus !

J’ai profité d’un mini bug sur la structure de boucle FOR / TO / NEXT pour déterminer si l’exécutable est compilé ou interprété.
En effet dans le code suivant l’interpréteur exécute la boucle une fois (et c’est un bug) alors que le compilateur ignore la boucle (ce qui est correct)
Faites un exe du code suivant avec l’interpréteur et avec le compilateur.

Code:

rem ============================================================================
IsPanoramicCompiled()
end
rem ============================================================================
SUB IsPanoramicCompiled()
    dim_local i,ret$
    ret$ = "Compiled"
    for i = 0 to -1
        ret$ = "Interpreted"
    next i
    message ret$
END_SUB
rem ============================================================================

Tiens, c'est amusant !