SimpleEditor

Bon, je crois que je vais devoir reprendre tout cela de zéro.
Là, c' est des emplâtres sur une jambe de bois.

bon courage !

J'ai regardé ton source de SimpleEditor, mais sans l'exécuter. L'appel de la fonction GetShortName est correct. Mais tu ne testes pas res% retourné par la fonction. Sa valeur doit être 0 pour que le résultat soit valable. Car en cas d'erreur, la fonction retourne 1 et le contenu de la variable court$ n'est pas changé, reste donc rempli d'espaces, et la fonction trim$ retourne une chaîne vide.

Je te suggère de faire ceci:

Code:

'  Nom court
   sub NomCourt(t$)
      dim_local res%,long$
      long$=t$
      if variable("court$")=0 then dim court$
      court$=string$(255," ")
      res% = dll_call2("GetShortName",adr(long$),adr(court$))
                if res%<>0
                  message 'Erreur dans GetShortName pour "+long$)
                end_if
      court$=trim$(court$)
   end_sub

D'ailleurs, ta variable long$ est superflue. Tu peux travailler directement avec t$ dans cette SUB.

Moi, je me pose la question de savoir si ce n' est pas le nom de fichier long qui pose un problème.
Le nom de fichier de Laurent contient de nombreux "." et, si c' est accepté par windows,
je pense que la fonction s' y perd.


En fait non.

Le source *.bas est bien recréé
L' exécutable à partir de ce source aussi.
Le source recréé est bien détruit.

Il n' y a que l' exécution de cet exécutable qui coince.

Lors de sa création, il est créé avec un nom court.
Et, si on lui rendait son nom long avant l' appel à "Execute" ?...

Non, la fonction ne s'y perd pas. J'appelle tout simplement l'API de Windows, dont voici la documentation MicroSoft:
https://msdn.microsoft.com/fr-fr/library/windows/desktop/aa364989(v=vs.85).aspx

La longueur du nom lon en entrée est limitée à MAX_PATH caractères. Chez moi, cette valeur est de 260 caractères (valeur par défaut dans un Windows non modifié).

Donc, modifie ta sub comme suit:

Code:

      sub NomCourt(t$)
          dim_local res%,long$
          long$=t$
          if variable("court$")=0 then dim court$
          court$=string$(255," ")
          if len(long$)>260
            message "long$ est trop long: "+str$(len(long$))
          end_if
          res% = dll_call2("GetShortName",adr(long$),adr(court$))
                    if res%<>0
                      message 'Erreur dans GetShortName pour "+long$)
                    end_if
          court$=trim$(court$)
       end_sub

Comme j'utilise directement l'API de Windows, si l'API ne comprend pas le nom long, c'est que le nom long n'est pas bon, ce n'est pas parce que la fonction a une erreur !

Je ne pensais pas que ce soit la fonction qui ait une erreur
mais le nom qui contenait des caractères réservés les "."
qui normalement séparent un nom de fichier de son extension.

Je crois que je vais faire encore plus simple.
Le fichier aura un nom propre à l' éditeur et pas son son nom.
Il portera le nom de :
"SimpleEditorPreview.bas" pour le fichier source reconstitué
"SimpleEditorPreview.exe" pour le fichier *.exe

Plus de problème de nom...

Fais le test que je te propose, tout simplement. S'il n'y a pas d'anomalie, ce code n'affiche rien. C'est juste pour déterminer la cause du problème.

Le point est parfaitement autorisé à l'intérieur d'un nom de fichier, au même titre que n'importe quel caractère. Seul le dernier point sert de délimiteur pour l'extension qui, elle, ene peut bien sûr pas contenir de point. Donc, un nom comme:
C:\Mes fichiers\Sources.Yannick\SimpleEditor_test.exemple.numéro.3.bas
est parfaitement valable et reconnu par le système.

J' ai bien un "Invalid file name" sur :

ActiveDir$+"SimpleEditorLog.txt"

alors que cela fonctionne très bien les 3 fois précédentes avec :

ActiveDir$+"SimpleEditorPreview.bas"
MakeExe$
ActiveDir$+"SimpleEditorPreview.exe"

Donc, soit le contenu de ActiveDir n'est pas bon, soit ActiveDir+"SimpleEditorLog.txt" depasse 260 caractères. As-tu essayé ma version de la SUB ?

Oui Klaus, j' ai aménagé la sub avec les messages.
Ce n' est pas le cas >260
C' est plus vicieux.

Une question stupide.
Un nom de fichier doit il être celui d' un fichier existant pour être raccourci ?

Non. Cet API fournit un nom court, sans considérer si le fichier existe. C'est juste une sorte de traduction, selon les règles de Windows.

Ben, cela fonctionne sur le nom d' un fichier existant
et j' ai des erreurs sur ceux qui n' existent pas...


Je vais mettre en ligne sur mon webdav une version qui fonctionne chez moi
puis ...

J'ai trouvé de quoi il retourne.

C'est un problème de paramétrage Windows. Dans Windows 10 (et probablement dans les versions précédentes 8.0, 8.1 et même 7, la gestion des noms courts est désactivée par un paramètre dans le registre. Et même si l'on rétablit ce paramètre, cela ne marchera toujours pas, dans la majorité des cas.

En fait, le nom court d'un fichier, et d'un dossier, d'ailleurs, est mémorisé avec son nom long, dans la directory elle-même. Windows essaie d'établir le nom court en parcourant l'arbre des dossiers, à partir du disque jusqu'au fichier, en déerminant pour chaque dossier intermédiaire egt finalement le fichier lui-même, le nom court de cet élément.

Or, cela ne marche que si tous les dossiers sur le chemin à parcourir ont été créés avec l'option de gestion des noms long activés !

Mais ce n'est plus l'option par défaut des Windows récents. Et cet API échoue donc systématiquement dès qu'on passe un chemin complet avec un nom de fichier. Par contre, après avoir activé cette option, cet API marche pour un nom de fichier seul, sans chemin.

La clé concernée dans le registre est:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
La valeur concernée est:
NtfsDisable8DotFieNameCreation
Pour activer les noms courts, sa valeur doit être 0 (zéro). Chez moi, c'est 2, et donc bloqué.

Conclusion:
Il faut absolument abandonner l'histoire des noms courts et travailler uniquement avec les noms longs (noms normaux).

EDIT

D'après MircoSoft et plusieurs forums concernant les systèmes Windows, le fait d'activer cette option conduit à une baisse notable des performances de Windows. Voilà une raison de plus de s'affranchir des noms courts. De toutes façons, il n'y a plus aucune raison de recourir aux noms courts, puisque tout fonctionne maintenant en noms longs, à condition qu'ils soient construits correctement.

EDIT bis

Si les noms longs posent problème avec les commandes EXECUTE er EXECUTE_WAIT, je conseille d'utiliser les fonctions

Code:

res% = DLL_call4("ExecuteProgram",adr(path$),adr(param$),adr(folder$),borderless%)
ou
res% = DLL_call3("ExecuteProgramAndWait",adr(path$),adr(param$),adr(folder$))

On y spécifie séparément le chemin vers le programme, la liste des paramètres et le dossier de démarrage. Ca peut siumplifier le codage.

Ok Klaus, merci pour cette information.

J'ai été confronté moi aussi à ce problème dans GPP entre autre...

C'est vrai que l'on rencontre régulièrement des difficultés entre noms longs et noms courts et j'avoue parfois être un peu perdu !    
Du coup c'est vrai que j'avais pris l'habitude de tout passer en nom court...

J’espère que cette façon de faire résoudra tous nos problèmes !  

Citation :

Du coup c'est vrai que j'avais pris l'habitude de tout passer en nom court...

J’espère que cette façon de faire résoudra tous nos problèmes !

Ben, justement.. non ! Si tu avais bien lu mon post ci-dessus, tu aurais vu que depuis les versions récentes de Windows, l'option "noms courts" est systématiquement désactivée. De ce fait, même pour les dossiers, les noms courts ne sont plus mémorisés. Et comme pour un chemin complet, les dossiers doivent exister, la conversion en noms courts échous systématiquement.

Il faut vraiment se défaire des noms courts et tout passer en noms longs !

Sous Windows 10 : il n’y a plus de limitation à 260 caractères pour les chemins d’accès à un fichier.
Mais …
Cette fonctionnalité n’est pas activée par défaut et il faut le faire manuellement.

Rendez-vous ici pour savoir comment faire.

Merci, Papydall. Mais ça ne marche pas sur W10 Home Edition - il n'y a ni l'utilitaire, ni les clés de registre indiquées.

Voici comment faire dans ce cas, selon ce link:


Changer la valeur de 0 à 1, valider, puis redémarrer le PC.

Merci Klaus pour toutes ces explications.
Dans mon cas, l' éditeur doit fonctionner pour tous et ce sans avoir à aller trifouiller 
dans la base de registre.
L' avenir sur windows étant w10, cela sera donc avec des noms longs.

Je remets tout en nom long et je publie une version 0.2
J' avais pubié cette nuit une version et du coup je ne saurai pas si elle fonctionnait chez Laurent.

J' ai déposé un zip vs 0.2

"Preview" tout en nom long.
Cette version fonctionne chez moi avec windows 10 edition familiale.

Le pb ne viens pas des noms courts ou longs, mais de la partie qui exécute le source:

Code:

' ! Timer de verif pour preview
VerifPreVi:
    laptime%=laptime%+1
    caption 0,PreviewFile$
    end
 if file_exists(PreviewFile$)=1
 Timer_off TimerPreVi%
 NomCourt(PreviewFile$)
 PreviewFileCourt$ = court$
 execute PreviewFileCourt$
else
...

'PreviewFile$' est le nom LONG du fichier à exécuter, alors que le fichier créé par la sub 'preview()' dans le disque dur est  un fichier avec un nom COURT. Donc 'file_exists(PreviewFile$)=0' et 'execute PreviewFileCourt$ ne peut pas être effectué.'

Klaus a écrit:

Non. Cet API fournit un nom court, sans considérer si le fichier existe. C'est juste une sorte de traduction, selon les règles de Windows.

Erreur, le fichier doit exister, sinon 'getshortname' ne converti pas.(testé sous XP)
Du coup, 'PreviewFile$' est le nom LONG du fichier à exécuter mais ce fichier n'existe pas, alors 'NomCourt(PreviewFile$)' retournera une chaine vide dans 'court$' et 'execute PreviewFileCourt$' n'exécutera rien.

On s'est croisé Yannick
Si tu as utilisé les noms courts, c'est pour que les commandes 'execute/xexcute wait' fonctionnent en toute circonstance, non? Le pb avec les espaces est réglé?

Il faut systématiquement entourer le chemin du progamme à exécuter ainsi que les paramètres, par des gullemets (chr$(34)). Ceci règle le problème des espaces.

Sur mon webdav, il y a deux versions

- Preview avec noms courts aménagés (3h35)
- Preview avec noms longs (14h01)

@ Silverman et Laurent,

Y en a t il une des deux qui fonctionne chez vous ?

Echec de téléchargement sur les deux fichiers...

C' est de ma faute, là les "." ne sont pas supporté dans le nom du fichier.


Je commence à devenir gaga avec ces histoires de nom de fichier.


C' est corrigé !