ShortName$(F) [Cloturé]

Bonjour Jack,

Voilà quelque temps que l' on est confronté à des soucis de Nom Long / Nom court
pour les fichiers.
Plusieurs solutions sont disponibles pour Windows mais voilà que se pose le souci
de portabilité d' un programme.

Si je veux que mon programme soit utilisable sur Mac PC ou Androïd, il doit être 
Tout Panoramic ( ex : un éditeur ).

Se pourrait il d' avoir une Variable système ShortName$(F) renvoyant le nom court d' un fichier
quelque soit l' OS ?
A moins que ce ne soit qu' un problème lié à Windows.

Ce que tu demandes n'est pas une variable mais une fonction.
Tu as déjà 4 fonctions sur les noms de fichier.

En supposant que f$ vaut c:\repertoire\fichier.txt

FILE_EXTRACT_DISK$(f$) retourne c:
FILE_EXTRACT_EXTENSION$(f$) retourne .txt
FILE_EXTRACT_NAME$(f$) retourne fichier.txt
FILE_EXTRACT_PATH$(f$) retourne c:\repertoire\

Je ne comprend pas très bien ta question, mais je pense que la 3ème fonction FILE_EXTRACT_NAME$() répond à ta demande car elle extrait un nom relatif à partir d'un nom absolu de fichier.

@ Jack,

Le problème vient des noms de fichier longs du type "Mon fichier de calcul.txt" avec des espaces dans le nom.
Et, si on peut maitriser les noms de dossier ou de fichier que l' on distribue, on ne maitrise pas ceux présents
sur l' ordi de l' utilisateur ex : "C:\Users\Jean Claude\".

si j' ai un chemin du type : "C:\Users\Jean Claude\Desktop\mon_fichier.txt"
et que j' essaie de le lancer par execute ou execute_wait, j' ai droit à un message de fichier introuvable :
"C:\Users\Jean"

D' où la nécessité d' avoir le nom court.

la sub de papydall fonctionne sur Windows mais pas sûr que cela soit valable sur Mac ou Androïd.
A moins que le problème ne soit que sur Windows.

sub de Papydall :

Code:

rem ============================================================================
rem          Nom_Court        Papydall
rem ============================================================================
dim fcourt$
Nom_Court("C:\Users\Jean Claude\Desktop\DSC05026.JPG") : ' chemin à adapter
message fcourt$
if fcourt$ <> "" then execute_wait fcourt$
end
rem ============================================================================
SUB Nom_Court(f$)
    if file_exists(f$) > 0
      execute_wait "cmd /c for %i in ("+chr$(34)+f$+chr$(34)+") do echo.%~sfi |clip"
      fcourt$ = clipboard_string_paste$
    else
      message "Ce fichier n'existe pas!" + chr$(13)+"Vérifier votre chemin"
    END_IF
END_SUB
rem ============================================================================

Oups ... j' ai dit variable et c' est une fonction...méa culpa, je fais des noeuds.

@Yannick,

je viens de regarder la To Do List que Jack à publier.

il y a notamment ceci: - correction du bug signalé sur les passages de paramètres avec EXECUTE et EXECUTE_WAIT. Cette correction est une modification lourde qui va prendre du temps qui est dans les priorités hautes.
Je ne suis pas certain de le justesse de ce que je vais dire, mais je tente....
Le problème "des noms courts" serait bien résolu avec la correction du bug évoqué ci-dessus.

A+

Jean Claude a écrit:

Le problème "des noms courts" serait bien résolu avec la correction du bug évoqué ci-dessus.

Tout à fait.
Lorsque Yannick a posé sa question sur les "noms longs" et les "noms courts" d'un fichier, j'ai d'abord cru qu'il appellait "nom long" le nom absolu d'un fichier (car il contient le path et le nom) et "nom court" le nom relatif (qui est plus court que le nom absolu car il ne contient pas le path).

Je viens seulement de comprendre qu'il appelle "nom long" un nom de fichier qui contient des espaces, et "nom court" un nom de fichier qui ne contient pas d'espaces !

Je confirme que EXECUTE et EXECUTE_WAIT pourront utiliser des noms de fichier avec ou sans espace.
Cette correction est très lourde car elle implique un changement du compilateur (celui qui sert à compiler Panoramic) avec tout le flot des problèmes qui en découle... car avec ce nouveau compilateur, la syntaxe a un peu changé.
Par exemple les commandes SEPARATOR_IS_POINT et SEPARATOR_IS_COMMA ne se programment plus de la même façon.
Certaines fonctions mathématiques comme POWER, HCOS et HSIN ne sont plus dans la même bibliothèque et ne s'utilisent plus de la même façon.
Certains objets ne sont plus les mêmes, par exemple, le ON_CLICK ne fonctionne plus sur le HVIEWER, l'objet SERIAL est loin d'être recodé, car l'ancien ne fonctionne plus du tout, le SYNEDIT n'est plus le même, le CHART non plus, etc, etc.
Le plus touché est la 3D avec le chaînage, les textures et les couleurs des objets ... car la biliothèque 3D que j'utilisais depuis le début de Panoramic ne fonctionne plus. Elle a évolué et beaucoup de choses ont changé...
Mais tout cela une fois terminé sera "transparent" pour l'utilisateur ...

@ Jack,

J' ai fait une pose pour mes yeux hier soir et ce matin j' ai vu ton post avec la todo_list.

J' ai quelques boites de Paracetamol  en rab...


Tu dis que l' objet Synedit n' est pas le même, c' est ce que j' avais vu en téléchargeant Tokyo.
Et là, c' est un mal pour un bien. Cela offrira plus de possibilité avec cet objet et notamment le repli des lignes.
 
Pour ce qui est du souci de ce post, si ce changement résout le problème, bingo !
je patienterai, pas de souci.

En tout cas, merci pour ta réponse.
Le sujet est donc clos.

@Jack:

Citation :

Je confirme que EXECUTE et EXECUTE_WAIT pourront utiliser des noms de fichier avec ou sans espace.
Cette correction est très lourde car elle implique un changement du compilateur (celui qui sert à compiler Panoramic) avec tout le flot des problèmes qui en découle... car avec ce nouveau compilateur, la syntaxe a un peu changé.
Par exemple les commandes SEPARATOR_IS_PO

Je suis étonné, car le l'ai fait facilement dans KGF.dll, via une API de Windows. Cela donne la fonction suivante dans KGF.Dll:

Code:

res% = DLL_call2("GetShortName",adr(long$),adr(court$))

Le code source est le suivant:

Code:

function GetShortName(inp:pchar; out:integer):integer; stdcall; export;
var
  fil: string;
  ATmp: array[0..255] of Char;
  pstr: ^string;
begin
  try
    result := 1;
    fil := pchar(pstring(inp)^);
    if GetShortPathName(PChar(fil),ATmp,SizeOf(ATmp)-1)=0 then exit;
    fil := StrPas(ATmp);
    pstr := @fil;
    CopyTextToPanoramic(integer(pstr),0,out);
  finally
  end;
  result := 0;
end;
exports GetShortName;

On appelle cette fonction de la manière suivante, en Panoramic:

Code:

dim res%, court$, long$
long$ = C:\Mon dossier avec espaces\Mon fichier avec espaces.txt"
court$ = string$(255," ")
res% = DLL_call2("GetShortName",adr(long$),adr(court$))
court$ = trim$(court$)

et le tour est joué.

@ Klaus,

Cela réponds tout à fait pour Windows.
Et quand je fais un programme pour moi en priorité qui suis avec cet OS, j' utilise KGF
pour une multitude de ses fonctions dont celle ci.

Là il s' agissait d' avoir une fonction portable tout OS ( Win,Mac,Androïd) pour que
Execute et Execute_Wait fonctionne correctement.
D' ailleur, je n' ai pas eu de réponse à savoir si ce souci entre noms longs et courts
étaient uniquement lié à Windows ou si il y avait le même sur les autres OS.

Jack à répondu que ce souci n' existerait plus à la correction de ces deux commandes
qu' il doit adapté à un nouveau compilateur.
Quand il dit que la correction est lourde, c' est que de nombreux objets,commandes et fonctions ont changé avec ce nouveau compilateur.

Peut être auras tu toi aussi des surprises avec les fonctions de Kgf sur des objets Panoramic.

Citation :

Là il s' agissait d' avoir une fonction portable tout OS ( Win,Mac,Androïd) pour que
Execute et Execute_Wait fonctionne correctement.

Je pense que c'est un faux problème. La difficulté des noms longs ou courts est propre à Windows et n'existe pas pour les autres systèmes.

Mais il faut bien garder à l'esprit que la syntaxe des arborescences des dossiers et fichiers sous d'aures systèmes est différente. Il y aura peut-être d'autres problèmes dans ce contexte, mais les noms longs/courts sont propres à Windows (toutes versions).

KGF.dll est spécifique à Windows. La grande majorité des fonctions n'ont un sens que sous Windows.

Nous sommes tout à fait d' accord.
Et, je te remercie d' avoir répondu à question.
Maintenant je sais que ce pb de nom long ou court est lié à Windows.
Il se pose maintenant une question.

Comment informer le programme qu' il est utilisé sous un OS ou un autre ?

Prenons ce cas de nom long/court.
on peut placer une condition sur l' OS pour le re-conditionnement des noms de fichiers
ex :

if OS$=Win
  dll_on kgf$
  .....
end_if

Encore faut il pouvoir renseigner la variable OS$....

Dans la doc, la variable Environment$ renvoi l' environnement pour lequel Panoramic a été créé mais que faire de celle ci si le programme ne sait pas dans lequel il est ?

Tel que je vois l'utilisation de cette variable, ce serait comme ceci:

Code:

if environment$="CLASSIC"
  ' ici, on est sous Windows...
else
  '' ici, on est dans un autre système, sans savoir lequel...
end_if

Je crois que l' on va attendre une explication de Jack...

Dans un ancien post de Jack:
SYSTEM$ : retourne le système d'exploitation utilisé par PANORAMIC ("WINDOWS" ou "ANDROID" ou "MACOS")
ENVIRONMENT$ : retourne l'environnement pour lequel PANORAMIC a été créé ("CLASSIC" pour Windows, "MULTIPLF" pour un environnement multi-plateforme Windows/Android/MAC OS))

Merci Silverman.

Comme quoi, j' ai la mémoire courte...

Depuis Windows 95, toutes les versions du système d’exploitation de Microsoft limitent à 260 le nombre maximum de caractères pour nommer les fichiers.

Bonne lecture:

Bon visionnage: