Discussion :

[fbalien]

Bonjour

je viens de galérer un moment avec un dev sous linux a cause du comportement de GetModuleName
GetModuleName semble ajouter un #0 dans la chaine de retour
si on lit un fichier ou on enregistre le résultat de GetModuleName en ajoutant .fblog cela donne la chose suivante

/^@f^@b^@t^@e^@s^@t^@f^@b^@l^@o^@g^@l^@i^@n^@u^@x^@^@^@.^@f^@b^@l^@o^@g^@"^@^M^@

il y a ^@^@ entre le nom du module name '/fbtestfbloglinux' et le '.fblog' que j'ajoute
le code qui génère le soucis est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

strTemp := GetModuleName(0)+ '.fblog';

Cela forcement pose des soucis lorsque je cherche a générer ou accéder a un fichier
Mais cela plante l'IDE si je fait un Writeln du resultat
pour contourner le soucis j'utilise ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    strTemp := GetModuleName(0) ;
    SetLength(strTemp,length(strtemp)-1);
    strTemp := strTemp + '.fblog';

est ce un bug ou faut il éviter d'utiliser GetModuleName sous Linux ?
Embarcadero® RAD Studio 10.4 Version 27.0.38860.1461

[SergioMaster]

Bonjour,

GetModuleName(0) je ne connaissais pas, il est d'ailleurs indiqué que

Avertissement : Sous MAC OS, GetModuleName ne réussit pas toujours.

c'est peut-être le cas pour d'autres OS.
D'autre part, les résultat est peut-être aussi dû à un encodage particulier ?

est ce un bug ou faut il éviter d'utiliser GetModuleName sous Linux ?

AMHA c'est un bug, cette fonction appelle GetModuleFilename qui est un appel à une API windows , pourtant pas de directives de compilation {$IFDEF WINDOWS} mais je n'ai peut-être pas assez fouillé dans le source.

J'aurais simplement utilisé paramstr(0) qui lui semble fonctionner dans tous les OS.
Néanmoins pour du multiplateforme j'aurais utilisé l'unité IOUtils.Tpath et obtenu un répertoire particulier (pas forcément celui de l'application, souvent protégé)
ce tableau en donne une liste précise

[fbalien]

Bonjour SergioMaster

merci pour ta réponse
surtout le lien vers le tableau de IOUtils.Tpath
je vais regarder çà

[pprem]

J'sais pas si c'est officiellement fonctionnel, mais si tu as un programme d'exemple n'hésite pas à ouvrir un ticket d'incident. Au pire ils répondront qu'il n'est pas pris en charge pour le moment.

Pour le #0 c'est sans doute parce que Linux a historiquement des chaines en ASCIIZ. Ca aussi, si tu as un programme d'expie, tu peux le faire remonter parce qu'à mon avis c'est passé à la trappe dans certains modules de l'OS. (après ça dépend aussi du type de chaine utilisé)

[fbalien]

Bonsoir
@pprem : ticket ouvert RSP-32373
@SergioMaster : si je vais dans le répertoire contenant le programme et que je l’exécute paramstr(0) me renvoie que le nom du programme
contrairement à GetModulename(0) qui lui me renvoie le chemin complet peu importe comment est exécuté le programme

[SergioMaster]

@SergioMaster : si je vais dans le répertoire contenant le programme et que je l’exécute paramstr(0) me renvoie que le nom du programme
contrairement à GetModulename(0) qui lui me renvoie le chemin complet peu importe comment est exécuté le programme

Il va falloir que je prenne le temps d'essayer autrement que sur une machine virtuelle (wsl)

[pprem]

Merci pour le RSP

si je vais dans le répertoire contenant le programme et que je l’exécute paramstr(0) me renvoie que le nom du programme

Me souvenais plus de cet effet de bord, mais effectivement, ce sont les morceaux de la ligne de commande, donc c'est logique.

Il y a des chances que System.IOUtils.TDirectory.GetCurrentDirectory ne soit pas non plus d'une grande aide si le programme a été lancé d'ailleurs.

Par contre tu as peut-être une chance avec System.IOUtils.TPath.GetFullPath sur paramstr(0) qui devrait recalculer le chemin du programme.