Drôle de réaction de DIR_CURRENT$

Bonjour à tous,

Comme je ne veux pas faire sursauter Jack, je préfère vous en parler d'abord.

Premièrement, il faut savoir que j'ai associé les fichiers en extension *.bas à l'éditeur Panoramic.
Ce qui fait que lorsque je clique sur un fichier bas celui-ci s'ouvre automatiquement avec l'éditeur Panoramic.
Je ne dois pas être le seul à utiliser ce principe.

Une fois le code chargé l'exécution dans l'éditeur se passe sans difficulté.

Maintenant je ferme ce code depuis l'éditeur et j'en ouvre un autre depuis le menu ouvrir fichier de l'éditeur Panoramic.
sous-entendu que le nouveau code que j'ouvre ne se situe plus dans le même emplacement sur le disque que le fichier précèdent.

Si mon nouveau code contient l'instruction DIR_CURRENT$, le chemin sera celui du précèdent fichier.
Et bien sûr il y a un bug puisqu'on ne regarde pas au bon endroit.

J'utilise la version 0.9.29i9 du 18 juillet 2019 mais il me semble que le problème est identique sur les dernières versions.

Est ce que vous pourriez tester ce problème svp ?

Et si mes explications ne sont pas claires demandez moi de vous expliquer de nouveau.

Merci d'avance pour votre aide.

Bonsoir Minibug,

Bizarre,
Déjà chez moi aussi le fait de cliquer un .bas me lance l'éditeur Panoramic, et j'ai la même version, 29i9.
Je fais le programme suivant

Code:

message DIR_CURRENT$
TERMINATE

J'en fais un .bas et un exécutable .exe, que je mets dans C:\PANORAMIC\
et les deux mêmes sur un autre disque appelé Z:\.
Que j'exécute les .bas sous Panoramic_Editor ou indépendamment les exécutables , ils me donnent bien le chemin
correct d'exécution, C:\PANORAMIC\ ou Z:\ suivant où ils se trouvent.

Salut JL35 !

Merci pour tes tests.

Est ce que si tu ouvres un premier fichier bas par 'ouvrir fichier' puis tu exécutes le programme.
Ensuite tu fermes le fichier en laissant l'éditeur ouvert.
Et tu fais pareil pour le 2eme. est ce que ca marche aussi ?

Ah oui, là effectivement, si j'exécute le 1er et que je charge le deuxième sans avoir fermé l'éditeur
il me donne le chemin du 1er...
Et si je fais l'inverse c'est pareil, la 2ème exécution répète le répertoire de la 1ère.
L'éditeur mémorise le chemin de la 1ère exécution.

Mais ça ne devrait pas le faire si on lance des exécutables (sans l'éditeur évidemment).
Après vérification (par ex. sur une clé usb) ça donne bien toujours le chemin de l'exécutable où qu'il soit.
C'est ce qui compte il me semble...

Et bien disons que lors du chargement du source le chemin devrai correspondre à l'emplacement du fichier lancé.
Enfin c'était le cas précédemment...

Concernant les EXEcutables, il n'y a pas de soucis effectivement.

J'attends de voir s'il y a d'autres avis partagés.
Mais donc tu valides comme moi pour un bug dans l'éditeur ?

Bof, je ne sais pas si c'est un bug, l'exécution dans l'éditeur c'est pour la mise au point,
l'essentiel c'est que ça marche en exécutable.
Mais bon, ça se discute.
En tout cas ça ne m'empêchera pas de dormir, foot ou pas :
Bonne nuit !

Pour le problème que tu décris, c'est peut-être une caractéristique de l'éditeur, il ne doit mémoriser que le dernier path qui a servi à charger ou enregistrer un programme, et pas celui de chaque onglet; Donc dir_current$ renvoie ce path et pas celui de l'onglet actif.

Et aussi, avant la version 0929i9 de panoramic_editor le fichier temporaire était créé dans le dossier du source, alors param_value$(0) nous renvoyait le chemin du source. Maintenant, il est créé dans le dossier TEMP de windows, donc param_value$(0) renvoie le dossier TEMP.

Une parade serait que le programme choisisse un chemin codé en dur si on est dans le dossier TEMP, sinon le chemin de l'application. Par contre, cela ne facilite pas le développement d'un programme, c'était plus simple avant.

Voici un code qui pourrait t'aider:

Code:

peek_reverse
dim p$,ret%

dll_on "kernel32"

' retrouve le nom de l'application courante
p$=string$(4096," ")
ret%=dll_call3("GetModuleFileNameA",0,peek32(adr(p$)),4096)
print trim$(p$)

' retrouve le chemin du répertoire dans lequel s'éxécute l'application
print
print file_extract_path$(param_value$(0))

' retrouve le chemin du répertoire courant
print
p$=string$(4096," ")
ret%=dll_call2("GetCurrentDirectoryA",4096,peek32(adr(p$)))
print trim$(p$)

' retrouve le chemin du répertoire courant
print
print dir_current$

' retrouve le chemin du répertoire TEMP de windows
print
p$=string$(4096," ")
ret%=dll_call2("GetTempPathA",4096,peek32(adr(p$)))   :' obtient le chemin
print trim$(p$)

dll_off

Bonjour à tous !

Le problème de dir_current$ est indépendant du fait d’associer les .bas à Panoramic_Editor.

En faisant l’impasse de cette association, utilisez Make_Exe.exe avec un éditeur alternatif et vous n’aurez plus de problème de dir_current$.

Avec EliP, vous pouvez ouvrir simultanément différents sources localisés dans différents répertoires ou disques durs, la variable système dir_current$ vous retournera toujours le bon chemin !

Bonsoir à tous et merci de vous êtes penché sur ma question.

Dans la doc il est dit ceci :

Cette variable système DIR_CURRENT$ retourne le nom du répertoire courant dans un string.

Mais à quoi donc corresponds le répertoire courant ?!
Peut être Jack pourra nous apporter une réponse...

Effectivement Marc tu as raison avec nos éditeurs maison et MAKE_EXE cela ne pose pas de problème.
Ce qui amène à penser que le répertoire courant corresponds bien au répertoire de lancement de l'exécutable.

Je laisse le fils en suspends en attendant d'en savoir davantage. Si Jack passe par ici il apportera peut être une réponse...

En attendant merci pour votre participation et vos réponses.

MiniBug a écrit:

Mais à quoi donc corresponds le répertoire courant ?!

Pour moi, le répertoire courant, mis dans la variable système DIR_CURRENT$, est au départ celui de l’éditeur lors de son lancement.
Puis, cette variable sera mise à jour en prenant le nom du chemin sélectionné par OPEN_DIALOG, SAVE_DIALOG ou DIR_CHANGE.
Toutes les commandes FILE_xxxxxx et FILEBIN_xxxxxx ne modifieront pas DIR_CURRENT$.

Merci les amis.  

Je laisse le Post ouvert et en attente.

Si Jack passe par ici il apportera peut être quelques explications.
Ou des corrections selon sa vision des choses.

Résolu, pas vraiment !!!
Si on s'en tient à la façon dont fonctionnait la version 29i7 que j'utilise toujours,
si on utilise un : file_load N°,"Nom-du-fichier.ext" (sans préciser le chemin)
ça marche en utilisant automatiquement le chemin du programme appelant.
On peut aussi faire : file_load N°,chemin-complet-du-fichier+"\Nom-du-fichier.ext"
ça marche aussi bien.
Et si on fait : DC$=dir_current$, cela nous donne le chemin du programme appelant,
ce qui est normal. Il me paraît tout à fait illogique de donner un autre chemin.
Alors à mon avis, IL S'AGIRAIT BIEN D'UN BUG
(je mets ça en évidence, car si Jack (toujours très occupé) passe par là seulement vite fait,
il pourra mieux s'apercevoir qu'il y a un problème).

@Minibug:
Si tu veux mon avis,
tu devrais enlever le [Résolu]
qui est trompeur...