Voila, en fait g une appli 16bits (et qui doit le rester), qui est utilisée sous win98. L'appli écrit dans un fichier dont on passe le chemin de le nom dans la ligne de commande.
Comment faire pour gérer les nom de fichiers (et surtout de répertoires) qui font plus de 8 caractères ?
y a pas de fonction du vieille API 16bits pour gérer ça !?

[edtdd]--Message édité par El_gringo--[/edtdd]

Dans une application 16bit on est obligé de rentrer le noms court du fichier ( propriété du fichier -> nom MSDOS).  
Il n'y a pas de fonction pour generer + de 8 char puisque que ça n'existait pas  

non, g du mal m'expliquer...du coup t'as pas compris ce dont g besoin !
 
Justement, en fait, pour que mon appli 16 bits puisse écrire dans un fichier qui serai situé (sous Win98) dans  
 
c:\NomLongDeRep\NomDeFic.txt
 
il faut qu'elle écrive à la place :
 
c:\nomlon~1\nomdef~1.txt
 
voila, c plus clair !?

C'est toujours pas clair    
 1er cas  
  c:\NomLongDeRep\NomDeFic.txt existe déja et tu veux ecrire dedans
 Dans ce cas quand tu fais un openfile tu rentre comme chemin "c:\nomlon~1\nomdef~1.txt"
 
 2eme cas :
 c:\NomLongDeRep\NomDeFic.txt n'existe pas et tu ne peux pas le créer avec ce nom puisque tu est limité à 8 char.

Voiiiila ! C qui m'interresse, c le 1er cas !
Mais vu que le traitement est automatisé, je veux que, si l'utilisateur entre un nom long de répertoire ou de fichier, il soit automatiquement remplacé par le nom de 8caractères...et il y a surement des fonctions qui permettent de faire ça automatiquement !
Parce que là, g pas que ça à faire, cette put*@§ d'appli 16bits de merd§!! va me rendre fou !!!!!  

[edtdd]--Message édité par El_gringo--[/edtdd]

En 16bit je ne crois pas qu'il y ai de solution, c'est normal puisque l'api 16bit n'a plus subit d'évolution depuis windows 3.11.
Mais si tu utilises une boite de dialogue d'ouverture de fichier fournie pas windows tu auras un chemin retourné au bon format.

La "solution" la plus simple serait d'éviter les noms trop longs dans les répertoires et noms de fichiers.
 
En 32 bits, il existe une fonction qui "contracte" les noms longs en "8+3". J'ai dû l'utiliser pour lire les métafichiers avec une fonction 16 bits sous Win 95/NT sinon ça allait pas.
 
L'inverse, pas évident, la chaîne passée n'étant pas obligée, dans l'absolu, d'être un nom de fichier. A moins de trouver l'algorithme qui met un ~1, ~2 à la fin du nom et de l'appliquer.
 
Une autre serait de l'adapter au 32 bits   (si bien écrit, plus facile ? Pb : certaines API qui ont disparu/remplacées, les int à mettre en short si accès binaire à fichier, WM_xx à adapter parfois)...

CARBON_14 a écrit a écrit : La "solution" la plus simple serait d'éviter les noms trop longs dans les répertoires et noms de fichiers.   En 32 bits, il existe une fonction qui "contracte" les noms longs en "8+3". J'ai dû l'utiliser pour lire les métafichiers avec une fonction 16 bits sous Win 95/NT sinon ça allait pas.   L'inverse, pas évident, la chaîne passée n'étant pas obligée, dans l'absolu, d'être un nom de fichier. A moins de trouver l'algorithme qui met un ~1, ~2 à la fin du nom et de l'appliquer.   Une autre serait de l'adapter au 32 bits   (si bien écrit, plus facile ? Pb : certaines API qui ont disparu/remplacées, les int à mettre en short si accès binaire à fichier, WM_xx à adapter parfois)...

 
--->Alors, ta 1ère solution, c pas terrible étant donné que j'écrit l'appli pour un client, si je peux éviter de mettre ça come contrainte c mieux !
 
--->Ta fonction 32 bits qui contracte c exactement ce que je cherche...comment elle s'appel cette fonction !?????
 
--->L'adapter au 32 bits...impossible, elle est affreusement mal écrite, ça serait énorme je pense, et g pas l'temps !
 
en conclusion: donnes moi le nom de cette fonction...please !!!!

 Bonne nouvelle. Je viens d'essayer d'associer ma "vieille" appli 16 bits avec un fichier .SP (spectre) sous Win NT. Quand je double-clique, l'appli 16 bits ouvre bien le fichier du répertoire F:\Archives perso\Spectros du labo\Machin.SP mis à la mode xx~1\yy~1\MACHIN.SP par Win NT.
 
Sous Win98, si la chaîne contenant le nom est lpCmdline, ça devrait aller.
 
L'API de "contraction" est 32 bits, donc ne peut être utilisée en 16 bits. Si je l'avais pas trouvé, j'étais coïncé.

non, ça marche pas sous Win98...  
 
Par contre ta fonction 32bits m'interresse, je t'explique :
En fait cette appli 16bits que je modifie est lancée par une appli 32bits que j'écris également. Cette appli 32 bits qui est un lanceur de l'appli 16bits pourrait convertir avant le chemin, avant de le passer dans la ligne de commande !

erare humanum est

[edtdd]--Message édité par El_gringo--[/edtdd]

Le source est chez moi, et j'ai la mémoire qui flanche (grand age).
 
J'ai cherché dans l'aide, et ce serait du genre GetShortPathName().
 
The GetShortPathName function obtains the short path form of a specified input path.  
 
DWORD GetShortPathName(
 
    LPCTSTR lpszLongPath, // points to a null-terminated path string
    LPTSTR lpszShortPath, // points to a buffer to receive the null-terminated short form of the path  
    DWORD cchBuffer  // specifies the size of the buffer pointed to by lpszShortPath
   );  
 
 
Parameters
 
lpszLongPath
 
Points to a null-terminated path string. The function obtains the short form of this path.
 
lpszShortPath
 
Points to a buffer to receive the null-terminated short form of the path specified by lpszLongPath.
 
cchBuffer
 
Specifies the size, in characters, of the buffer pointed to by lpszShortPath.
 
etc, etc.....

Putain, c génial, merci, c excellent, je m'doutais bien qu'elle existait cette fonction...
Exactement ce qu'il me fallait !
Vive le Carbon14, tant pis si t radioactif, j't'en veux pas
Merci à toi...aux autres aussi, ms surtout à toi qd même !

[edtdd]--Message édité par El_gringo--[/edtdd]