Discussion :

[eomer212]

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 :

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

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..

[Médinoc]

1. Bizarre, le coup du TEXT(t2)...
2. Tu es en MFC, tu devrais essayer avec une CFileDialog...

[eomer212]

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

[eomer212]

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..

[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...

[eomer212]

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.

[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é!

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 "*.*"

[eomer212]

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 :

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
 
//	#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é..

[Médinoc]

Salut,
Déjà, remplace tes sizeof() par des ARRAYSIZE(). Si tu compiles en unicode, c'est le plantage assuré.

Code si tu n'es pas sous Visual :

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

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 C/C++ perso :

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

1
2
3
4
5
#ifndef NULL_T
#define NULL_A ((LPSTR)NULL)
#define NULL_W ((LPWSTR)NULL)
#define NULL_T ((LPTSTR)NULL)
#endif

[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

[Ngork]

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 :

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
 
#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() ...

[Gojir4]

Merci pour ta solution ca marche bien, plus de plantages intempestifs. Tu viens de mettre un terme à 2 jours d'arrachage de cheveux.

[Mat.M]

Bonjour,

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() !!!
GetOpenFileName() est une fonction C du SDK de Windows contenue dans comdlg32.dll

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 :

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

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

[Mat.M]

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 :

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
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;

[Ngork]

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.

[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.

[Ngork]

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 !