GetOpenFileName fait planter SHELL32.dll

Version imprimable

8O
c'est vraiment trés bizarre, j'ai essayé pas mal de choses, en particulier les exemples d'utilisation de la faq visualc++ pour le cfiledialog , et moult autres exemples dédiés à la selection d'un fichier, mais j'arrive toujours au même resultat.
lorsque je veux selectionner un fichier situé sur le bureau windows, la premiere selection se passe parfaitement bien, mais la deuxieme, finit invariablement par faire planter le programme dans son ensemble, sans meme un message, rien.
Petite précison, le plantage ne se produit QUE lorsque c'est le deuxieme fichier que je vais chercher, et exclusivement sur le bureau windows, et que lorsque je passe ma souris sur une icone de fichier existant. le passage sur les liens ne fait pas planter la boite de dialogue..
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 CString t1,t2; t1.LoadString(IDS_STRING32836); //Tous fichiers t2.LoadString(IDS_STRING33285); //Selection du fichier TCHAR file[MAX_PATH]=TEXT(""); TCHAR path[MAX_PATH]=TEXT(""); OPENFILENAME ofn= { sizeof(OPENFILENAME), AfxGetMainWnd()->m_hWnd, NULL, TEXT("all files\0*.*\0\0"), NULL, 0, 1, file, MAX_PATH, NULL, 0, path, TEXT(t2), //"Selection du fichier"), OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST, 0, 0, TEXT("*.*"), 0, NULL, NULL }; int a=GetOpenFileName( &ofn );
et ca me donne en mode debug un splendide
unhandled exception in shell32.dll 0x0000000C5 access violation...
et cela ne se produit QUE lorsque c'est la deuxieme fois que je vais selectionner un fichier sur ce satané bureau..
quelques fois aussi, j'ai des faux espoirs, car cela ne se produit que la troisieme fois...
j'ai trouve un poste sur usenet qui pourrait décrire le meme probleme et son eventuelle solution, à savoir augmenter la taille du stack, mais probleme, comment faire sous visual c++6.???
autrement, je suis à la recherche de toute autre solution qui me permettrait de selectionner un fichier à la fois sans faire planter cette satannée dll..
:aie:

04/08/2006, 22h59
Médinoc

1. Bizarre, le coup du TEXT(t2)...
2. Tu es en MFC, tu devrais essayer avec une CFileDialog...
05/08/2006, 00h13
eomer212

essayer avec un cfiledialog

oui, en effet,j'ai essayé aussi, mais ca donne le meme resultat.
j'ai même ét jusqu'à prendre le source de la faq visual c++ cfiledialog pour le mettre dedans et j'ai exactement le meme plantage
07/08/2006, 00h16
eomer212

arrggg

:arf: arggg
j'y perds mon latin, j'ai essayé d'augmenter la pile, des morceaux de code recuperes ici ou la, mais j'ai toujours le meme probleme, et seulement quand je vais chercher un fichier pour la deuxieme fois sur le bureau..
ya t-il quelque chose qui doit etre reinitialisé dans le cfiledialog ou le getopenfilename.?? j'y perds mon latin, car c'est vraiment à l'intérieur de cette fichue dll que se produit l'erreur.
j'arrive meme pas à la recuperer en faisant des try/catch..
07/08/2006, 00h33
Médinoc

Je ne sais pas, il y a peut-être un truc mal initialisé...

Pour les try/catch, c'est normal, le "C++ exception handling" n'arrête pas ce type d'exceptions car ce ne sont pas des exceptions C++.
Essaie le Structured Exception Handling pour cela...
18/08/2006, 01h17
eomer212

bon, quand il faut, ben, il faut...

:furieux:
constatant une fois de plus que le shell de windows est codé avec des pieds d'imbécile cul de jatte, plus qu'une chose à faire...
j'ai recodé complétement le composant...ca m'a pris quelques jours pour maitriser la chose, mais au moins, je suis sûr que ca ne va pas me provoquer un plantage intempestif.
encore un bel exemple de l'absence de révision des codes sources de windows.
:arf:
18/08/2006, 09h09
Médinoc

En fait, j'ai remarqué un paramètre qui ne correspond à rien de spécifié:
lpstrInitialDir (dans lequel tu mets path) est supposé être NULL ou spécifier un répertoire. Windows n'apprécie peut-être pas la chaîne vide non-nulle...

Ah-HA! Je crois que j'ai trouvé!

Citation:

Envoyé par MSDN

lpstrDefExt
Pointer to a buffer that contains the default extension. GetOpenFileName and GetSaveFileName append this extension to the file name if the user fails to type an extension. This string can be any length, but only the first three characters are appended. The string should not contain a period (.). If this member is NULL and the user fails to type an extension, no extension is appended.

Et toi, tu y passes "*.*"

non, vraiment pas...

salut, bon t'as l'air comme moi, tu t'accroches tant que t'as pas la solution.
j'ai essayé en suivant le point que tu as soulevé, mais rien à faire.
donc je me suis dit que ca venait peut-être de mes variables.

alors, j'ai fait table rase et j'ai essayé avec ce bout de code tiré du msdn.
Code:

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 // #define MAX_PATH 1024 // pour rappel TCHAR szFilter[MAX_PATH]="all files\0*.*\0\0"; TCHAR szFile[MAX_PATH]=""; TCHAR szFileTitle[MAX_PATH]=""; TCHAR szDefExt[MAX_PATH]=""; Ofn.lStructSize = sizeof(OPENFILENAME); Ofn.hwndOwner = NULL; Ofn.lpstrFilter = szFilter; Ofn.lpstrCustomFilter = (LPSTR)NULL; Ofn.nMaxCustFilter = 0L; Ofn.nFilterIndex = 1L; Ofn.lpstrFile = szFile; Ofn.nMaxFile = sizeof(szFile); Ofn.lpstrFileTitle = szFileTitle; Ofn.nMaxFileTitle = sizeof(szFileTitle); Ofn.lpstrInitialDir = (LPSTR) NULL; Ofn.lpstrTitle = (LPSTR)NULL; Ofn.Flags = OFN_SHOWHELP | OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST; Ofn.nFileOffset = 0; Ofn.nFileExtension = 0; Ofn.lpstrDefExt = szDefExt; int a=0; a=GetOpenFileName( &Ofn );
et la, surprise, ca plante à fond les gamelles!!!
jamais la premiére fois, non, toujours à la deuxiéme visite sur le bureau, lorsque le curseur de la souris passe au dessus d'un fichier présent sur le bureau, non pas un lien.
je précise que je fais l'appel depuis ma classe cmainframe, j'ai des timers, des threads en route, et des liaisons ftp, et autres qui peuvent être aussi en route, mais j'ai essayé en les supprimant, purement et simplement, mais elles sont pas en causes, (j'ai même supprimé leurs délarations et les variables associées au cas ou...)
et donc, au moment ou le popup de description du fichier essaye de se mettre en place, le programme disparait, purement et simplement.

je repasse sur mon composant, au moins il est béton lui..
merci d'avoir regardé..:merci:

18/08/2006, 13h54
Médinoc
Salut,
Déjà, remplace tes sizeof() par des ARRAYSIZE(). Si tu compiles en unicode, c'est le plantage assuré.
Code:

1 2 3 #ifndef ARRAYSIZE #define ARRAYSIZE(x) (sizeof(x)/sizeof(x[0])) #endif
Et je le répète, il y a des endroits où l'aide dit qu'on peut mettre NULL, mais ne dit rien sur les chaînes vides... (ne pas oublier que "" != NULL)

PS: Initialise bien ta OPENFILENAME à zéro (avec {0} à la déclaration ou ZeroMemory() dessus) pour que les variables non-mentionnées (ou futures) soient bien à zéro)
http://msdn.microsoft.com/library/de...enfilename.asp

Et les casts en (LPSTR) sont inutiles. (Même si moi, j'ai l'habitude d'utiliser un truc du genre qui suit)
Code:

1 2 3 4 5 #ifndef NULL_T #define NULL_A ((LPSTR)NULL) #define NULL_W ((LPWSTR)NULL) #define NULL_T ((LPTSTR)NULL) #endif
18/08/2006, 17h03
Ti-R

eomer212, j'ai eu le même problème... la boite de dialogue me faisait planter mon logiciel... plusieurs mois plus tard, je m'y suis remis, en recopiant à droite et gauche du code pour l'utiliser, et après plusieurs jours d'acharnement, j'ai finalement laissé tombé... :?, j'ai fait comme toi mon propre composant, et depuis aucun problème :?

Solution

Bon, OK le post initial date pas mal, mais on le trouve encore dans les premiers liens avec une recherche Google, et comme j'ai eu le même problème et que j'ai trouvé une solution sans avoir besoin de recoder la fonction, voilà :

Il suffit au début de l'application de faire un appel à la fonction CoInitialize() - initialisation des fonctions de la librairie COM - déclarée dans objbase.h et incluse dans la librairie ole32.

Puis à la fin de l'application, un appel à CoUninitialize() pour libérer les processus.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 #include <windows.h> #include <objbase.h> int WINAPI WinMain(/** arguments **/) { /** déclaration et création de la fenêtre principale **/ CoInitialize(NULL); { /** boucle des messages **/ } CoUninitialize(); /** retour **/ }
C'est tout et ça marche !
Plus de problème avec GetOpenFileName() ...

14/07/2010, 10h50
Gojir4

Merci

Merci pour ta solution ca marche bien, plus de plantages intempestifs. Tu viens de mettre un terme à 2 jours d'arrachage de cheveux.
14/07/2010, 15h51
Mat.M
Bonjour,

Citation:

Envoyé par Ngork

Il suffit au début de l'application de faire un appel à la fonction CoInitialize() - initialisation des fonctions de la librairie COM - déclarée dans objbase.h et incluse dans la librairie ole32.
...
Plus de problème avec GetOpenFileName() ...

CoInitialize() n'a absolument rien à voir avec GetOpenFileName() !!! 8O
GetOpenFileName() est une fonction C du SDK de Windows contenue dans comdlg32.dll

Citation:

GetOpenFileName Function

--------------------------------------------------------------------------------

The GetOpenFileName function creates an Open dialog box that lets the user specify the drive, directory, and the name of a file or set of files to open.

Function Information

Minimum DLL Version comdlg32.dll
Header Declared in Commdlg.h, include Windows.h
Import library Comdlg32.lib
Minimum operating systems Windows 95, Windows NT 3.1
Unicode Implemented as ANSI and Unicode versions.

CoInitialize() est une fonction contenue dans ole32.dll qui permet de créer des objets COM avec CoCreateInstance() !
S'il y a des plantages c'est que GetOpenFileName() est mal initialisée
Code:

1 2 AfxGetMainWnd()->m_hWnd==NULL ?
8O

Il faut faire un ZeroMemory au préalable pour bien initialiser la structure de type OPENFILENAME

Voilà du code que j'utilise il fonctionne parfaitement

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
case IDM_FILE_OPEN:
					OPENFILENAME ofn;
					wchar_t wFile[256];
					ZeroMemory(&ofn, sizeof(ofn));
					ofn.lStructSize = sizeof(ofn);
					ofn.hwndOwner = hWnd;
					ofn.lpstrFile = wFile;
					ofn.lpstrFile[0] = '\0';
					ofn.nMaxFile = sizeof(wFile);
					ofn.lpstrFilter = TEXT("*.txt\0");
					ofn.nFilterIndex = 1;
					ofn.lpstrFileTitle = NULL;
					ofn.nMaxFileTitle = 0;
					ofn.lpstrInitialDir = NULL;
					ofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
					if (GetOpenFileName(&ofn)==TRUE) 
					{
						// alors faire					}
				break;

27/10/2010, 02h27
Ngork

Mmm ...

Merci pour tes informations.

Toutefois, après essai, faire un ZeroMemory pour initialiser la structure OPENFILENAME ne change rien au problème exposé dans ce post ...

Alors qu'initialiser les objets COM résoud effectivement ce problème !

Cordialement,
N'gork.
27/10/2010, 09h16
Médinoc

C''est bizarre, je pensais que GetOpenFileName() échouerait sans planter sur une non-initialisation de COM...

En tout cas, c'est normal que ça ait besoin de COM, parce que GetOpenFileName() ouvre un Explorer. Et donc, charge des extensions du shell.
16/04/2021, 18h46
Ngork

Mise à jour

Je suis tombé l'autre jour sur l'information ad-hoc dans la doc Microsoft avec une fonction très proche : SHBrowseForFolder.
https://docs.microsoft.com/en-us/win...owseforfoldera

Suis-je passé à côté de cette doc à l'époque ou n'était-ce pas encore documenté ?
En tout cas, la réponse est claire sur le fait que "You must initialize Component Object Model (COM) before you call SHBrowseForFolder", mais ce n'est bizarrement pas repris pour GetOpenFileName qui en est pourtant très proche et présente le même curieux effet de bord ! :D