Discussion :

[kunda]

Bonsoir,

J'avais posté quelque part que j'avais trouvé un comportement bizarre a FindFirstFile, mais que ca ne me dérangait pas. Ben finalement ca m'embète quand même.

Le problème se situe dans le path qu'on donne a manger a FindFirstFile. Partout ou il y a un / ou un \ dans le chemin de fichier, on peut mettre à la place n'importe quelle combinaison de / et \ (voir exemple). La seule exception est celui situe juste apres le double-point (f:\)



Dans une premiere version de mon programme ca ne me genait pas, il s'agissait juste d'afficher les noms de fichiers, alors la solution que j'avais trouvé c'étais juste de verifier qu'il n'y en avais pas a la fin, puis de rajouter \*.* pour avoir tous les fichiers.

Sauf que maintenant, je voudais sortir la liste de ces fichiers avec le chemin complet, et avec tous ces //\//\ ca fait moche. Sans compter que je ne suis pas sur que les autres fonstions qui reclame un chemin en parametre soient daccord si je leurs refile ca !

Bon, on me diras peut-être que c'est une drole d'idée d'en mettre autant, que le plus simple c'est de ne pas en mettre, etc ... Mais bon, maintenant que je sais que c'est possible, ca m'enquiquine. Je voudrais nettoyer le chemin pour qu'il ai l'air normal, même dans le cas ou quelqu'un s'amuse a rentrer n'importe quoi.

Alors mes questions sont : Est ce un comportement normal de cette foncion ? Quel est le moyen le plus sure d nettoyer tout ca (avant de concatener avec le nom et d'envoyer tout le bazar a une autre fonction) ?

Merci d'avance !

(je vous mets un bout de code pour essayer, c'est plus simple)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
#include <windows.h>

LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM);

VOID SearchFiles (char*);

HINSTANCE hinst;
HWND hwnd;
HWND hListBox;
HWND hFoldEditBox;    
HWND hSearchButton; 

#define ID_BUTTON_GO 100

char szClassName[ ] = "WindowsApp";

int WINAPI WinMain (HINSTANCE hThisInstance,
                    HINSTANCE hPrevInstance,
                    LPSTR lpszArgument,
                    int nFunsterStil)

{
    hinst = hThisInstance;
    MSG messages; 
    WNDCLASSEX wincl; 

    wincl.hInstance = hThisInstance;
    wincl.lpszClassName = szClassName;
    wincl.lpfnWndProc = WindowProcedure; 
    wincl.style = CS_DBLCLKS; 
    wincl.cbSize = sizeof (WNDCLASSEX);

    wincl.hIcon = LoadIcon (NULL, IDI_APPLICATION);
    wincl.hIconSm = LoadIcon (NULL, IDI_APPLICATION);
    wincl.hCursor = LoadCursor (NULL, IDC_ARROW);
    wincl.lpszMenuName = NULL; 
    wincl.cbClsExtra = 0; 
    wincl.cbWndExtra = 0; 
    wincl.hbrBackground = (HBRUSH) COLOR_BACKGROUND;

    if (!RegisterClassEx (&wincl))
        return 0;

    hwnd = CreateWindowEx (
           0,  
           szClassName,
           "Rechercher les fichiers vides", 
           WS_OVERLAPPEDWINDOW,
           CW_USEDEFAULT, 
           CW_USEDEFAULT,
           544, 
           375, 
           HWND_DESKTOP, 
           NULL,        
           hThisInstance,
           NULL  
           );

    ShowWindow (hwnd, nFunsterStil);

    while (GetMessage (&messages, NULL, 0, 0))
    {
        TranslateMessage(&messages);
        DispatchMessage(&messages);
    }
    return messages.wParam;
}

LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
      
    switch (message)  
    {
    case WM_CREATE:
            {
             hListBox = CreateWindowEx(WS_EX_CLIENTEDGE,"LISTBOX", "Texte", 
                                       WS_VISIBLE|WS_CHILD|LBS_SORT|LBS_NOINTEGRALHEIGHT|LBS_NOTIFY|WS_HSCROLL|WS_VSCROLL,
                                       0, 0, 0, 0, hwnd, NULL, hinst, NULL);
                                       
             hSearchButton = CreateWindowEx(WS_EX_CLIENTEDGE,"BUTTON", "GO", 
                                       WS_VISIBLE|WS_CHILD|BS_PUSHBUTTON|BS_NOTIFY|BS_TEXT,
                                       0, 0, 0, 0,  hwnd, (HMENU)ID_BUTTON_GO, hinst, NULL);
                                       
             hFoldEditBox = CreateWindowEx(WS_EX_CLIENTEDGE, "EDIT", "", 
                                       WS_VISIBLE|WS_CHILD|ES_AUTOHSCROLL|ES_NOHIDESEL,
                                       0, 0, 0, 0, hwnd, NULL, hinst, NULL);
                                       
             SendMessage(hFoldEditBox, EM_SETLIMITTEXT, (WPARAM) MAX_PATH, 0);                     
             
            break;
            }        
        
        
        case WM_SIZE:
            RECT clientRect;
            GetClientRect(hwnd, &clientRect);        

            MoveWindow(hListBox, 0, 50, clientRect.right, clientRect.bottom -50, TRUE); 
            MoveWindow(hSearchButton, 10, 20, 30, 20, TRUE);
            MoveWindow(hFoldEditBox, 50, 20, clientRect.right - 70, 20, TRUE);
                                             
            break;  
                 
        case WM_COMMAND:

            if ((LOWORD(wParam) == ID_BUTTON_GO) && (HIWORD(wParam) == BN_CLICKED))
            {
                char path[MAX_PATH];
                SendMessage(hFoldEditBox, WM_GETTEXT, (WPARAM) MAX_PATH, (LPARAM) path);
                SendMessage(hListBox, LB_RESETCONTENT, 0, 0); 
                SearchFiles(path);       
            }  
             break;                                           
        case WM_DESTROY:
            PostQuitMessage (0);     
            break;
            
        default:   
            return DefWindowProc (hwnd, message, wParam, lParam);
    }
    return 0;
}

VOID SearchFiles (char searchPath[MAX_PATH])
{     
    HANDLE searchHandle;    
    WIN32_FIND_DATA fileSearchStruct;    
    BOOL result = TRUE;
    
    char fullPath[MAX_PATH] ="" ;
    
    searchHandle = FindFirstFile( searchPath, &fileSearchStruct);
    
    if (searchHandle == INVALID_HANDLE_VALUE)
        {
            result = FALSE;
            char errorString[] = "Ce n'est pas un chemin valide\n\n";
            strcat(errorString, searchPath);
            
            MessageBox(hwnd, errorString, "Erreur", MB_OK);
            return;
        }
    else
        {
            MessageBox(hwnd, searchPath, "Chemin", MB_OK);            
        }    
        
    
    while (result != FALSE)
        {
         fullPath[0] = '\0';
         strcat(fullPath, searchPath);
         strcat(fullPath, " ## Fichier -> ");
         strcat(fullPath, fileSearchStruct.cFileName);
         SendMessage(hListBox, LB_ADDSTRING, 0, (LPARAM) (LPCTSTR) fullPath );            
         result = FindNextFile(searchHandle, &fileSearchStruct); 
        }    
        FindClose(searchHandle);
    return;
}

[ram-0000]

Après plusieurs essais, j'ai l'impression que
1/ \ ou / sont strictement équivalents dans un nom chemin
2/ le premier \ (de c:\) peut aussi être un /
3/ le nombre de / ou \ consécutif est sans importance (par habitude, 1 suffit mais si on est tordu on peut en mettre 3 ou 17)
4/ //// est aussi équivalent à /./././
5/ c:/temp/toto.txt est aussi équivalent à c:/temp/../temp/../temp/toto.txt

Donc dans ton cas, il faut nettoyer le chemin avant de l'afficher si tu veux que cela soit propre

[pascal.barbier]

GetFullPathName devrait faire le travail.
Ca marche même pour le nom d'un fichier ou d'un répertoire qui n'existe pas.

[kunda]

@ram_000

Après plusieurs essais, j'ai l'impression que
1/ \ ou / sont strictement équivalents dans un nom chemin
2/ le premier \ (de c:\) peut aussi être un /

4/ //// est aussi équivalent à /./././
5/ c:/temp/toto.txt est aussi équivalent à c:/temp/../temp/../temp/toto.txt

Normal, c'est ce que dit la msdn. On peut utiliser soit \ soit / dans un chemin, mais rien d'autre comme separateurs, et que les . et .. represente le repertoire courant et son parent. Jusque la pas de problème.

3/ le nombre de / ou \ consécutif est sans importance (par habitude, 1 suffit mais si on est tordu on peut en mettre 3 ou 17)

Donc dans ton cas, il faut nettoyer le chemin avant de l'afficher si tu veux que cela soit propre

C'est justement ce que je disais. Normalement un seul suffit, mais comme il s'agit d'une entrée utilisateur, rien ne me garanti qu'un "tordu" ne va pas en saisir plusieurs. Et si FindFirstFile semble l'accepter, je ne suis pas sur qu'une autre fonction travaillant avec un chemin soient elle aussi d'accord pour l'accepter. Donc justement, mon souci c'étais de nettoyer un peu, pour 'betonner' les entrees utilisateur.

En fait c a ne fait que repeter ce que je disais, mais merci d'avoir essayé.

@pascal.barbier

GetFullPathName devrait faire le travail.
Ca marche même pour le nom d'un fichier ou d'un répertoire qui n'existe pas.

J'ai essayé, mais tous ce que ca fait, c'est de remplacer les / par des \
Donc en fin de compte \/\///\\\/\ devient \\\\\\\\\\\ alors que je cherchais juste a n'avoir qu'un seul \

Bon en fin de compte, je crois qu'il doit s'agir d'une "fonctionnalité non prevue" parce je ne vois pas de raison d'admettre ce genre de chemin. Je pensais dabord faire une fonction qui enleve les signes en trop, mais finalement je vais juste en controler le nombre et renvoyer un mesage d'erreur a l'utilisateur en cas de chemin bizarre.

Merci a tous deux !