Problems with GetOpenFileName and GetSaveFileName
Leslie Milburn
I have a weird problem using GetOpenFileName at only one (out of hundreds)
of my client sites. They have recently updated to Windows XP SP2, the
problem did not occur whilst they were using XP SP1.
I have got the "crash" sequence down to this:
The user clicks a "select" button and the Open File dialog opens (by default
to Desktop).
They move their mouse around the screen without clicking any files and then
click the cancel button.
So far no problems.
Now they hit my "select" button a second time.
Now when they move the mouse around without clicking anything, my
application exits, no message nothing and basically we are back at the
windows desktop.
What is interesting is that the crash also happens when I call
GetSaveFileName() elsewhere in the application.
My gut feeling is that the crash is triggered by the Tooltips that are
trying to display within that dialog.
I have spent hours reading many other posts wth similar issues and I
occasionally come across references which seem to indicate there might be
some special stack/heap requirements in order to call these fuinctions.
Can anyone help? This is not a unicode application, the open Code follows...
Thanks Leslie
************************************
OPENFILENAME FileInfo;
char FilePath[256];
memset(FileInfo, NULLBYTE, sizeof(FileInfo));
FileInfo.lStructSize = sizeof(FileInfo);
FileInfo.hWndOwner = hWnd; // Confirmed its a valid handle.
FileInfo.lpstrFile = FilePath;
FileInfo.nMaxFile = sizeof(FilePath);
FileInfo.lpstrFile[0] = '\0';
FileInfo.Flags = OFN_HIDEREADONLY | OFN_FILEMUSTEXIST | OFN_PATHMUSTEXIST;
if (GetOpenFileName(&FileInfo) == 0)
return CANCEL;
else ...........
James Brown
news:ODPBtOZZ...@TK2MSFTNGP12.phx.gbl...
Can't help directly but...
Are you compiling with UNICODE macro defined? Your FilePath buffer is
defined
in CHARs, you would have a problem if your program was Unicode because
you have 256 bytes of storage in FilePath, but you say that
FileInfo.nMaxFile is
256 *characters* long (this would be interpreted as 512 bytes by
GetOpenFileName
if you were using Unicode and would cause a crash because your FilePath is
only
256 bytes long).
Better to declare FilePath as:
TCHAR FilePath[MAX_PATH];
FileInfo.nMaxFile = MAX_PATH; // or
FileInfo.nMaxFile = sizeof(FilePath) / sizeof(FilePath[0]);
the snippet you have posted looks OK - it is identical to what I use apart
from you specify FilePath as 256 chars, I use MAX_PATH which is 260.
Also I use the FileInfo.lpszFileTitle member as well - but neither of these
should cause you
problems.
You don't specify the FileInfo.hInstance - try this:
FileInfo.hInstance = GetModuleHandle(0);
but I think it is not necessary in your case.
If you paste this snippet into a separate program (i.e. with just a main()
function)
does it still crash?
You could try allocating FilePath on the Heap with malloc rather than being
a local stack variable - perhaps you have so many buffers like this on the
stack that
it is overflowing? Or make it a global variable.
James
--
www.catch22.net
Free win32 software, sourcecode and tutorials
David Lowndes
>of my client sites. They have recently updated to Windows XP SP2, the
>problem did not occur whilst they were using XP SP1.
A needle in a haystack problem :(
In this circumstance, given the weird repro, I suspect it's unlikely
to be your problem - more likely a graphics device driver issue, or
some low-level 3'rd party software that's on that machine.
I'd try getting the user to check in safe mode (std VGA driver), and
if they can't repro it then, suspect the graphics card driver.
Dave
Leslie Milburn
Thanks for the reply, answers inline.........
"James Brown" wrote in message
news:429c52a5$0$338$cc9e...@news.dial.pipex.com...
> Are you compiling with UNICODE macro defined?
No. ANSI all the way.
> Your FilePath buffer is defined
> in CHARs, you would have a problem if your program was Unicode because
> you have 256 bytes of storage in FilePath, but you say that
> FileInfo.nMaxFile is
> 256 *characters* long (this would be interpreted as 512 bytes by
> GetOpenFileName
> if you were using Unicode and would cause a crash because your FilePath is
> only
> 256 bytes long).
I did try TCHAR but sizeof() reported same size so its definitely ANSI.
> the snippet you have posted looks OK - it is identical to what I use apart
> from you specify FilePath as 256 chars, I use MAX_PATH which is 260.
Given they click cancel I doubt its the buffer as it should not be populated
but even so I would expect a buffer too small error.
> You don't specify the FileInfo.hInstance - try this:
> FileInfo.hInstance = GetModuleHandle(0);
I'll give it a try.
> If you paste this snippet into a separate program (i.e. with just a main()
> function) does it still crash?
I did as you suggested and it still crashes the same way. This test program
is just a window with a select button. Behaviour is exactly as stated
before.
> You could try allocating FilePath on the Heap with malloc rather than
being
> a local stack variable - perhaps you have so many buffers like this on the
> stack that it is overflowing?
I had previous tried a global variable but no luck. It definitely feels like
a stack crash to me. I have shown all files below, nowhere does the stack
size get set by me, so I am wondering what the default is?
> Or make it a global variable.
I have previously tried that.
Here's the whole latest test code I am now using.......... its a WIN32
program using VC5.
/*************** The C Code ************************/
#include <windows.h>
#include <commctrl.h>
/************************ Static Function Declarations
**********************/
static void cmsback_SelectFolder (HWND hWnd);
/********************************************************************/
HINSTANCE hInstance;
char szAppName[30];
BOOL CALLBACK EXPORT MainWndProc(HWND, UINT, WPARAM, LPARAM);
int WinMain(HINSTANCE hInst, // Application Instance Handle
HINSTANCE hPrevInstance, // Previous Instance Handle
LPSTR lpszCmdLine, // Pointer to Command Line
int nCmdShow) // Show Window Option
{
MSG msg;
HWND hWndMain;
WNDCLASS wndclass;
hInstance = hInst;
lstrcpy(szAppName, "cmsback");
if(NULL == (hWndMain = CreateDialog(hInstance,
MAKEINTRESOURCE(cm0back),
NULL,
MainWndProc)))
{
MessageBox(NULL, "Unable to display main dialog", "System Error",
MB_OK);
return FALSE;
}
ShowWindow(hWndMain, nCmdShow);
UpdateWindow(hWndMain);
while(GetMessage(&msg, NULL, 0, 0))
if(!IsDialogMessage(hWndMain, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return msg.wParam;
}
BOOL CALLBACK EXPORT MainWndProc(HWND hWnd, UINT uMessage, WPARAM wParam,
LPARAM lParam)
{
WORD CtlId;
WORD Notify;
HWND CtlWnd;
switch(uMessage)
{
case WM_INITDIALOG :
return TRUE;
case WM_COMMAND :
#ifdef WIN32
CtlId = LOWORD(wParam);
Notify = HIWORD(wParam);
CtlWnd = (HWND)lParam;
#else
CtlId = wParam;
Notify = HIWORD(lParam);
CtlWnd = (HWND)LOWORD(lParam);
#endif
if(!CtlWnd)
{ // Process Menu Commands
switch(CtlId) // Determine which Menu ID
{
}
}
else
{
switch(CtlId)
{
case CMSBACK_PBBROWSE :
{
if (Notify == BN_CLICKED)
cmsback_SelectFolder(hWnd);
}
break;
case IDCANCEL :
{
PostMessage(hWnd, WM_CLOSE, 0, 0);
}
break;
}
}
break;
case WM_CLOSE :
{
DestroyWindow(hWnd);
return TRUE;
}
case WM_DESTROY :
{
PostQuitMessage(0);
break;
}
default :
return FALSE;
}
return FALSE;
}
/**************************************************************************
*
*
* Function: cmsback_SelectFolder()
*
* Description: This function looks after the Folder Selecltion.
*
*
* Entry Conditions: The Window Handle Must be Passed.
*
*
* Exit Conditions: None.
*
*
*/
static void cmsback_SelectFolder(HWND hWnd)
{
OPENFILENAME FileInfo;
char FullPath[260];
/* Clear the File Information. */
memset(&FileInfo, (BYTE)0, sizeof(FileInfo));
/* Initialise the FileInfo Structure. */
FileInfo.lStructSize = sizeof(FileInfo);
FileInfo.hwndOwner = hWnd; // The Owner Window Handle.
FileInfo.lpstrFilter = "All Files\0*.*\0"; // File Filter.
FileInfo.nFilterIndex = 1;
FileInfo.lpstrFile = FullPath;
FileInfo.nMaxFile = sizeof(FullPath);
FileInfo.lpstrFile[0] = '\0';
FileInfo.lpstrTitle = "Crash Test #12";
FileInfo.Flags = OFN_HIDEREADONLY |
OFN_FILEMUSTEXIST |
OFN_PATHMUSTEXIST;
/* Display the Open File Dialog. */
if (GetOpenFileName(&FileInfo) == 0)
{
MessageBox(GetDesktopWindow(),
"User Clicked Cancel",
"Information",
MB_OK | MB_ICONHAND | MB_TASKMODAL);
return;
}
MessageBox(GetDesktopWindow(),
"User Clicked Open",
"Information",
MB_OK | MB_ICONHAND | MB_TASKMODAL);
}
/******************** The Make File ****************************/
#
# Makefile for ANSI C application : cmsback
#
SRCDIR = ./
INCDIR = ./
OBJDIR = ./
RESDIR = ./
LIBDIR = ./
EXEDIR = ./
LNKRSP = @cmsback.lnk
# Error listing file
ERROUT = >> Errors
CC = cl.exe
LINK = link.exe
RC = rc.exe -DWIN32
IMPLIB = lib.exe
CFLAGS = -c -W3 -DWIN32 -D_X86_ -nologo -O2
CDEFINES = -D_WINDOWS -DSTRICT
LINKFLAGS = -align:0x1000
MACHINE = -machine:IX86
LINKDEBUG =
GUIFLAGS = -subsystem:windows -entry:WinMainCRTStartup
COMPILE = $(CC) $(CFLAGS) $(CDEFINES)
ALL : $(EXEDIR)cmsback.exe
.Silent:
$(OBJDIR)cmsback.obj : $(SRCDIR)cmsback.c
echo compiling cmsback.c
$(COMPILE) -Fo$(OBJDIR) $(SRCDIR)cmsback.c $(ERROUT)
$(RESDIR)cmsback.res : $(RESDIR)cmsback.rc $(INCDIR)cmsback.id
$(RESDIR)*.dlg
echo compiling Resources...
$(RC) -r $(RESDIR)cmsback.rc $(ERROUT)
$(EXEDIR)cmsback.exe : $(OBJDIR)cmsback.obj \
$(RESDIR)cmsback.res \
$(LIBDIR)cmsback.def \
echo linking...
$(LINK) $(LINKFLAGS) $(LINKDEBUG) $(GUIFLAGS) \
$(RESDIR)cmsback.res\
-out:$(EXEDIR)cmsback.exe \
$(MACHINE) $(LNKRSP) $(ERROUT)
echo Finished
/******************** The Link File ****************************/
cmsback.obj
libc.lib
kernel32.lib
user32.lib
gdi32.lib
winspool.lib
comdlg32.lib
/*********************************************************/
Leslie Milburn
Thanks for the reply, answers below..............
"David Lowndes" <dav...@example.invalid> wrote in message
news:fiuo91ljr9pe466hf...@4ax.com...
> A needle in a haystack problem :(
Don't you just hate these ones.
> In this circumstance, given the weird repro, I suspect it's unlikely
> to be your problem - more likely a graphics device driver issue, or
> some low-level 3'rd party software that's on that machine.
I would agree if its was only one machine but they have 10+ workstations and
although the crash happens differently on each one, it *does* happen. What
is annoying is that with XP SP1 there was no problem, its only with SP2
which to me indicates a change inside windows itself.
I got them to try mspaint using File - Open (which looks like the same
dialog). Guess what - its perfectly fine. That why I'm thinking stack crash
or something.
I have posted my entire code in response to James' reply. Perhaps you can
notice the stupid mistake I'm making as its now a totally isolated test
program.
> I'd try getting the user to check in safe mode (std VGA driver), and
> if they can't repro it then, suspect the graphics card driver.
I might just do that.
Thanks
Leslie
Alexander Grigoriev
"Leslie Milburn" <CD...@NOSPAM.bigpond.com> wrote in message
news:efXyfSk...@TK2MSFTNGP12.phx.gbl...
Alexander Grigoriev
"Leslie Milburn" <CD...@NOSPAM.bigpond.com> wrote in message
news:OMLe2WkZ...@TK2MSFTNGP15.phx.gbl...
James Brown
> Hi James,
>
> Thanks for the reply, answers inline.........
>
[code snipped]
OK I've tested your program with VC6 SP6. I made myself a little
resource file with a simple Dialog in it. I also didn't use your makefile +
compiled
straight using VC workspace.
Couple of comments:
BOOL CALLBACK EXPORT MainWndProc(HWND, UINT, WPARAM, LPARAM);
I don't know what EXPORT means in this context. I had to remove it from the
declaration
in order to compile. It shouldn't be there anyway - and you don't need to
export (In the DLL sense)
window-procedures anyway.
int WinMain(HINSTANCE hInst, // Application Instance Handle
HINSTANCE hPrevInstance, // Previous Instance Handle
LPSTR lpszCmdLine, // Pointer to Command Line
int nCmdShow) // Show Window Option
You are missing one important detail here:
int WINAPI WinMain
As you don't seem to be specifying a calling convention in your makefile I
am surprised
your code compiled, as WinMain should be WINAPI (__stdcall) - this will
definitely cause
problems but not with the filename dialog.
There doesn't appear to be any problem with the rest of your program.
Anyhow I ran your program and it seemed OK - I got "User Pressed OK", "User
Pressed Cancel"
messages and no crashes...
I have copied a ZIP up to my website which contains the binary+sources for
your program,
compiled with VC6 for you to test:
www.catch22.net/source/zips/ofn_test.zip
Maybe try a different compiler? Or the latest service-pack for VC5?
Try compiling with maximum warning level to make sure there isn't something
subtle
tripping you up..
There may be a way to work around the problem by specifying more options
rather
than less....
Also, what version of the Platform SDK are you using? Make sure your version
and it's headers are all up-to-date.
What is _WIN32_WINNT #defined as before you #include <windows> and
<commctrl> ??
Try:
#define _WIN32_WINNT 0x500
#include <windows.h> etc
This will give you different versions of the OPENFILENAME structure, with
extra fields
so the structure will be different. It will still work under 9x/NT4 etc but
could potentially
be the source of the problem. But you need recent (i.e. Feb 2003+) platform
SDK installed
and available to the VC compiler..
You can email me via my website (www.catch22.net) - I'm on UK time so will
not
be able to help until this evening. GetOpenFileName crashes are very
difficult to track down -
I know this from experience so can sympathise with your problem..
Cheers,
James Brown
There could be a shell-namespace-extension on your customer's system which
is causing the open-file dialog problems when invoked from your program
(i.e. older app compiled with VC5 and using old platform sdk headers).
this might explain why your program is not getting to see the exception that
is being generated by the OS - because the namespace extension is catching
it and exiting whatever process it is loaded into..just a guess could be
totally wrong,
but it does seem to be a 3rd-party kind of problem.
Having said that, shell-extensions only load into explorer, but it could
still be
a 3rd party shell-dialog hook or extension that is causing you problems.
Also, I remember in the past when the GetOpenFileName dialog opened
in an "odd" directory like My Documents / My Pictures, then it would
sometimes
crash if there were problems with the app - try opening the dialog
and forcing it to start in C:\ - I think there's a field in OPENFILENAME
which
allows you to do this.
Also, try using:
__try
{
GetOpenFileName(&ofn);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
// problem occured but we caught it. Don't exit the app,
// just let the user know.
}
Cheers,
James
Leslie Milburn
"Alexander Grigoriev" <al...@earthlink.net> wrote in message
news:#lK4x8mZ...@TK2MSFTNGP12.phx.gbl...
> You should not use a desktop window as an owner for your message boxes.
Give me a break ;-)
Actually its a good point but as I just sort of hacked it up on the fly
thats what happens when you're in a hurry. But I will make the change to use
hWnd.
Leslie.
Leslie Milburn
Thanks for your efforts. Answers inline......
"James Brown" <remove_james_dot_brown7_at_virgin_dot_net> wrote in message
news:429d66e5$0$290$cc9e...@news.dial.pipex.com...
>
> OK I've tested your program with VC6 SP6. I made myself a little
> resource file with a simple Dialog in it. I also didn't use your makefile
+
> compiled straight using VC workspace.
>
> Couple of comments:
>
> BOOL CALLBACK EXPORT MainWndProc(HWND, UINT, WPARAM, LPARAM);
>
> I don't know what EXPORT means in this context. I had to remove it from
the
> declaration
Actually in this context EXPORT is nothing as in
#define EXPORT
The reason being is that this code was actually migrated years ago from
16bit and so theres a lot of legacy defines going on around the place.
> int WinMain(HINSTANCE hInst, // Application Instance Handle
> HINSTANCE hPrevInstance, // Previous Instance Handle
> LPSTR lpszCmdLine, // Pointer to Command Line
> int nCmdShow) // Show Window Option
>
> You are missing one important detail here:
>
> int WINAPI WinMain
Actually, thats a typo !!
> Anyhow I ran your program and it seemed OK - I got "User Pressed OK",
"User
> Pressed Cancel"
> messages and no crashes...
Which is what I get as well on my four different machines.
> I have copied a ZIP up to my website which contains the binary+sources for
> your program, compiled with VC6 for you to test:
>
> www.catch22.net/source/zips/ofn_test.zip
Thanks I will download it and give it a whirl.
> Maybe try a different compiler? Or the latest service-pack for VC5?
> Try compiling with maximum warning level to make sure there isn't
something
> subtle tripping you up..
>
> There may be a way to work around the problem by specifying more options
> rather than less....
>
> Also, what version of the Platform SDK are you using? Make sure your
version
> and it's headers are all up-to-date.
I am using Visual Studio 97 for this application. The SDK is old but I still
have users using Win95 for some applications (yeah I know - cheapskates - I
even offered them free upgrades to 98SE but they didn't go for it). Anyway
thats why I haven't upgraded as yet.
> What is _WIN32_WINNT #defined as before you #include <windows> and
> <commctrl> ??
> Try:
>
> #define _WIN32_WINNT 0x500
> #include <windows.h> etc
I looked into that I don't have OFN_NT4 (or whatever it is) in my headers
and will need to change the SDK. If I can definitely identify my development
environment as the problem then I'll change it, but I have to be sure first
before I resort to that. Your program will help out here because if it
crashes then I know its not me and if it doesn't then I know it is :-)
> This will give you different versions of the OPENFILENAME structure, with
> extra fields so the structure will be different. It will still work under
9x/NT4 etc but
> could potentially be the source of the problem. But you need recent (i.e.
Feb 2003+) platform
> SDK installed and available to the VC compiler..
I have downloaded that SDK but I am not sure if it is compatible with VC5,
so I might even upgrade to VC6, just to make sure I keep current ;-)
> You can email me via my website (www.catch22.net) - I'm on UK time so will
> not be able to help until this evening.
> GetOpenFileName crashes are very difficult to track down -
Once again thanks for your time on this problem. I'll let you know tomorrow
how your program fared !! I will also do the same thing and ignore my
makefile and do it via the IDE as well (which i detest - I still use Brief
and the command line).
Leslie.
Leslie Milburn
"James Brown" <remove_james_dot_brown7_at_virgin_dot_net> wrote in message
> One other thought.
>
> Also, I remember in the past when the GetOpenFileName dialog opened
> in an "odd" directory like My Documents / My Pictures, then it would
> sometimes crash if there were problems with the app
You see thats the problem - it only crashes in the Desktop Folder no where
else and trhats what I find irriating. ITs alomost as if theres something on
the desktop that tooltips has a heart attack about.
> and forcing it to start in C:\ - I think there's a field in OPENFILENAME
> which allows you to do this.
Yep, its find for any other folder than the desktop - its damn weird. I'd
expect it to fail regardless of the location.
> Also, try using:
>
> __try
> {
> GetOpenFileName(&ofn);
> }
> __except(EXCEPTION_EXECUTE_HANDLER)
> {
> // problem occured but we caught it. Don't exit the app,
> // just let the user know.
> }
>
I've never used these modern fangled constructs, I'm an 80's kind of C
programmer :-)
I'll give it a go if your program also crashes.
Thanks
Leslie.
Leslie Milburn
> Call CoInitialize(NULL) in the start of your program.
I'll give it a try, but I'm skeptical (and willing to try anything).
Are you saying that the GetOpenFileName() uses COM ??
Can you point to some documentation, cause I've never read that anywhere
(yet !)
I did think about InitCommonControls() but again do I need it for the
GetOpenFileName() ?
Leslie.
Gary Chanson
As far as I know, you don't need wither InitCommonControls or CoInitialize
before calling GetOpenFileName.
--
-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
- http://www.mvps.org/ArcaneIncantations/consulting.htm
-gcha...@mvps.org
Leslie Milburn
"Gary Chanson" <gcha...@No.Spam.TheWorld.net> wrote in message
news:urb2Q$qZFH...@TK2MSFTNGP12.phx.gbl...
> As far as I know, you don't need wither InitCommonControls or
CoInitialize
> before calling GetOpenFileName.
Yeah thats what I thought, thanks for confirming.
Leslie
Alexander Grigoriev
"Leslie Milburn" <CD...@NOSPAM.bigpond.com> wrote in message
news:OLzMYRqZ...@TK2MSFTNGP15.phx.gbl...
Carsten Neubauer
I would give it a try.
In 2002 I had similar OpenFilename-crashes and
a call to InitCommonControls at program-start
fixed the problem.
CoInitialize might have worked too.
Regards,
Carsten Neubauer
http://www.c14sw.de
http://www.edcomponents.com
James Brown
news:1117638455.2...@g44g2000cwa.googlegroups.com...
Interesting that the GetOpenFileName docs don't mention you
require CoInitialize - compared to real-world experience as mentioned
where it fixed the problem. Perhaps there is a 3rd party dialog extension
which is assuming the caller did a CoInitialize - without this call the 3rd
party
software breaks..??
Leslie Milburn
"Leslie Milburn" <CD...@NOSPAM.bigpond.com> wrote in message
news:#mvZBNqZ...@TK2MSFTNGP09.phx.gbl...
>
> > Anyhow I ran your program and it seemed OK
Can you try this:
1. Run program.
2. Click Ok
3. Click on the desktop icon on the LHS.
4. Move the mouse around in the listview so that the tootips pop up (no
clicking though).
5. Click Cancel.
6. It will display cancel message.
7. Repeat steps 2 - 6 a couple of times.
Does it crash for you because it doesn't for me.
> > I have copied a ZIP up to my website which contains the binary+sources
for
> > your program, compiled with VC6 for you to test:
> >
> > www.catch22.net/source/zips/ofn_test.zip
Your compilation of the program also crashed :-(
But in another respect, this is good news as I now don't have to worry about
my SDK etc.
I am going to give InitCommonControls() and CoInitialize() a whirl and see
if they make any difference (I've got nothing to lose). I am also getting
the user to move all of the desktop icons to another folder and then see if
we have the problem with a blank desktop.
Thanks for your efforts, at the very least you have helped me regain
confidence in my current development setup.
Leslie.
Carsten Neubauer
I tried James' edition of your source and could
reproduce the crash. Definitely happening deep
inside GetOpenFileName, possibly connected with
long tooltip-texts on the desktop and/or with
those symbolic pathes like 'desktop'.
Alexander and me thought about COM before.
Now InitCommonControls had no effect,
after calling CoInitialize, I could
open the file-dialog, go to desktop etc.
again and again, but then the program crashed
when calling CoUninitialize...
However, I found a 'solution' comparing with
another app, where the problem didn't happen.
Don't ask me why, just try calling OleInitialize
at program-start and OleUninitialize right before
exit.
Greetings,
Leslie Milburn
Thanks for your input, what version of XP (original, SP1, SP1A or SP2) ??
Further testing at this end has revealed that the crash happens in my case
when there is a PDF file on the desktop. Tooltips falls over when trying to
do its stuff with that file (actually its any PDF file). Remove all PDF's
and its fine. Move all icons into a subfolder (including PDFs) and its fine.
I also tried InitCommonControls() and found that it made no difference -
the test still crashed.
So I then tried CoInitialize(NULL) and CoUninitialize(). Guess what NO CRASH
even upon exit !!!!!!
According to the documentation CoInitialize() and OleInitialize() are the
interchangeable for this type of implementation.
The only difference between my machine and my clients machine is that I use
Adobe Reader 6 and they have upgraded to Adobe Reader 7. They have sent me
the PDF file and I have no problems, so I am about to upgrade to version 7
and see what happens.
So it could actually not be related to XP SP2 but rather Adobe Reader which
was apparently upgraded around the same time. I am still searching for a
conclusive answer, but IMO this shows a real hole in windows implementation
if you ask me.
Leslie.
"Carsten Neubauer" <c...@c14sw.de> wrote in message
news:1117693321.2...@z14g2000cwz.googlegroups.com...
Carsten Neubauer
> Hi Carsten,
>
> Thanks for your input, what version of XP (original, SP1, SP1A or SP2) ??
> Further testing at this end has revealed that the crash happens in my case
> when there is a PDF file on the desktop. Tooltips falls over when trying to
> do its stuff with that file (actually its any PDF file). Remove all PDF's
> and its fine. Move all icons into a subfolder (including PDFs) and its fine.
Well, I have a lot of PDFs on my desktop, but I think
it happened also, when moving over zip- or other files.
Though the PDFs were still there and got processed.
> I also tried InitCommonControls() and found that it made no difference -
> the test still crashed.
Like here.
> So I then tried CoInitialize(NULL) and CoUninitialize(). Guess what NO CRASH
> even upon exit !!!!!!
Hm, unlike here, strange.
> According to the documentation CoInitialize() and OleInitialize() are the
> interchangeable for this type of implementation.
Just guessing, but perhaps OleInitialize does a bit more,
whatever this is.
> The only difference between my machine and my clients machine is that I use
> Adobe Reader 6 and they have upgraded to Adobe Reader 7. They have sent me
> the PDF file and I have no problems, so I am about to upgrade to version 7
> and see what happens.
The same, I use Acrobat 7.
> So it could actually not be related to XP SP2 but rather Adobe Reader which
> was apparently upgraded around the same time. I am still searching for a
> conclusive answer, but IMO this shows a real hole in windows implementation
> if you ask me.
Well, OSes got really complex, where the complexity
grew faster than the human ability to care for side-effects.
Now we have spooky effects, where workarounds like this one
remind me of ancient rituals to prevent bad luck...
This time I'd count on modern tooltips with more than
256 characters, too long strings behind 'desktop' or
someting else, which nobody ever used when they invented
the common controls.
Perhaps OleInitialize & Co replace critical buffers by
bigger ones, but that's just an idea.
Leslie Milburn
> That was XP home with SP2.
Good, something consistent.
> Well, I have a lot of PDFs on my desktop, but I think
> it happened also, when moving over zip- or other files.
> Though the PDFs were still there and got processed.
Yes thats right. In my case its the presence of a PDF that triggers the
problem. You do not neccessarily need to be over that file for it to crash.
> > So I then tried CoInitialize(NULL) and CoUninitialize(). Guess what NO
CRASH
> > even upon exit !!!!!!
> Hm, unlike here, strange.
> Just guessing, but perhaps OleInitialize does a bit more,
> whatever this is.
You are right OleInitialize() prepares the application for Drag On Drop, In
place activation and other stuff in addition to what CoInitialize() does. I
think the Drag on Drop is the issue as I can drag files into the Open File
Dialog. This is why I think we need to call InitializeOle(). So I think
thats what I am going to use for the time being.
Of course I now have to worry about what happens to my RichEdit Controls if
I do call that :-(
>
> The same, I use Acrobat 7.
Yes, I am very suspicious. I would just like to recreate the problem on one
of my machines here.
> Well, OSes got really complex, where the complexity
> grew faster than the human ability to care for side-effects.
> Now we have spooky effects, where workarounds like this one
> remind me of ancient rituals to prevent bad luck...
You are right, except that given that Windows is a Proprietry system and we
are calling a Common Dialog - this mess is Microsoft's responsibility. I
have now spent 6 days hunting this problem down and so far I am less than
happy with these interim results.
> Perhaps OleInitialize & Co replace critical buffers by
> bigger ones, but that's just an idea.
You know what, that sounds like malloc to me. Call me critical but I think
that if the dialog requires COM then it should initialise it itself - The
API allows for nested calls.
I will let you know the Adobe 7 results shortly.
Leslie.
Carsten Neubauer
> "Carsten Neubauer" <c...@c14sw.de> wrote in message
> news:1117701219.2...@z14g2000cwz.googlegroups.com...
>
>
> > Well, OSes got really complex, where the complexity
> > grew faster than the human ability to care for side-effects.
> > Now we have spooky effects, where workarounds like this one
> > remind me of ancient rituals to prevent bad luck...
>
> You are right, except that given that Windows is a Proprietry system and we
> are calling a Common Dialog - this mess is Microsoft's responsibility. I
> have now spent 6 days hunting this problem down and so far I am less than
> happy with these interim results.
>
try using the waveAPI, especially the useful
callback-function, they prepared for you...
>
> > Perhaps OleInitialize & Co replace critical buffers by
> > bigger ones, but that's just an idea.
>
> You know what, that sounds like malloc to me. Call me critical but I think
> that if the dialog requires COM then it should initialise it itself - The
> API allows for nested calls.
>
Perhaps we can track it down to some hidden y2k-bug,
but I think we just have to live with it for a while.
One day, we all gonna meet in the mental asylum
for windows-programmers...
BTW: You don't need a testproject, you can open up notepad,
open file, view all files on the desktop, cancel, open file
a second time and voila, notepad crashes. Tried on w2k, but
there I only see short tooltips and notepad works fine.
So long,
David Lowndes
>open file, view all files on the desktop, cancel, open file
>a second time and voila, notepad crashes.
Good catch, I can repro that on XP SP2 with Acrobat 7 installed.
Dave
Leslie Milburn
> Leslie Milburn schrieb:
> > "Carsten Neubauer" <c...@c14sw.de> wrote in message
> > news:1117701219.2...@z14g2000cwz.googlegroups.com...
> >
> try using the waveAPI, especially the useful
> callback-function, they prepared for you...
Never used it, I'm glad to say.
> BTW: You don't need a testproject, you can open up notepad,
> open file, view all files on the desktop, cancel, open file
> a second time and voila, notepad crashes. Tried on w2k, but
> there I only see short tooltips and notepad works fine.
I did try mspaint but it must initialise COM or Ole becuase it was fine.
Becuase of that I simply believed I had done something stupid. I guess the
stupid thing I did was not to have faith in my setup of like 7 years now.
Leslie.
Leslie Milburn
proved invaluable in resolving this problem with GetOpenFileName() and
GetSaveFileName(). Actually it makes you wonder what else.
I have now been able to reproduce the crash effect simply by installing
Adobe Acrobat Reader Version 7.0 (not version 6) on my Windows XP SP2
machine.
This crash only happens to me when the Open File Dialog is in the Desktop
Folder. It appears that the crash will occur after a number of Tooltips has
been displayed. FYI: You do not even need to have any PDF's on the desktop -
its the mere installation of Reader that is the problem.
This problem may indeed be caused by some sort of hook as James Brown
suggested a few days ago. Or it could be that Adobe is installing a DLL
which is incompatible with XP SP2 (the old DLL Hell) - I simply am too tired
to go into this level of detail. If anyone else ever follows up on this bit
I would be interested to know the outcome.
The solution is to call either CoInitialize() or OleInitialize() and of
course the uninit functions at the end.
Leslie.
Leslie Milburn
"Carsten Neubauer" <c...@c14sw.de> wrote in message
news:1117693321.2...@z14g2000cwz.googlegroups.com...
> However, I found a 'solution' comparing with
> another app, where the problem didn't happen.
>
> Don't ask me why, just try calling OleInitialize
> at program-start and OleUninitialize right before
> exit.
I am interested to find out why CoInitialize worked for me and not you. The
code below is not bullet proof (its just a test prog), but I do it upfront
and at the end of winmain, not for each call of GetOpenFileName(). Where did
you place the OleInitialize() and OleUninitialize() calls ??
Thanks
Leslie.
int WINAPI WinMain(HINSTANCE hInst, // Application Instance
Handle
HINSTANCE hPrevInstance, // Previous Instance Handle
LPSTR lpszCmdLine, // Pointer to Command Line
int nCmdShow) // Show Window Option
{
MSG msg;
HWND hWndMain;
WNDCLASS wndclass;
hInstance = hInst;
lstrcpy(szAppName, "cmsback");
// Test #12
// InitCommonControls();
// Test #13
CoInitialize(NULL);
if(NULL == (hWndMain = CreateDialog(hInstance,
MAKEINTRESOURCE(cm0back),
NULL,
MainWndProc)))
{
MessageBox(NULL, "Unable to display main dialog", "System Error",
MB_OK);
return FALSE;
}
ShowWindow(hWndMain, nCmdShow);
UpdateWindow(hWndMain);
while(GetMessage(&msg, NULL, 0, 0))
if(!IsDialogMessage(hWndMain, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
CoUninitialize();
return msg.wParam;
}
Leslie Milburn
(Preferably one that has not had Windows Updates applied).
Thanks
Leslie.
Carsten Neubauer
Leslie Milburn schrieb:
> I did try mspaint but it must initialise COM or Ole becuase it was fine.
> Becuase of that I simply believed I had done something stupid. I guess the
> stupid thing I did was not to have faith in my setup of like 7 years now.
>
Argh.
Wasted a lot of time myself on similar subjects,
so I can imagine how it hurts. Usually the bugs
are in our own code and a lot of times we have
to search hard for those little creatures.
This time the riddle seems solved, but unfortunately
XP with SP2 and Acrobat 7 are out, so we have to care
about this bug, even if it would get fixed one fine day.
I can even clear up the CoInitialize-difference.
I had placed both calls exactly like in your new
example, but by accident I had written
CoUninitialize(NULL), which was compilable,
but crashed by itself.
Now using CoUninitialize() without a parameter
works fine. Good that you insisted!
Greetings,
![Severian [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWrEr4AHeFsCJeSqv2uPJV4Zjd0QWRhH1ruoxh86gWKtsicMA=s40-c)
Severian [MVP]
I *think* GetOpenFileName() creates its own thread, so the exception
can't be caught this way.
--
Phillip Crews aka Severian
Microsoft MVP, Windows SDK
Posting email address is real, but please post replies on the newsgroup.
Norman Bullen
I know it does. I have trouble when I let the debugger in VC6 run
through a call to GetOpenFileName(). I select a file and GOFN() returns
normally. About 30-40 seconds later the debug window shows two (I
believe) threads terminating and my primary thread is usually hung in
the debugger.
Each of the programs in which I seen this problem work fine if run
without the debugger (either debug or release builds) and they run fine
in the debugger if I pass the file name on the command line and never go
to GOFN().
Norm
--
--
To reply, change domain to an adult feline.
Leslie Milburn
"Carsten Neubauer" <c...@c14sw.de> wrote in message
news:1117726414.8...@f14g2000cwb.googlegroups.com...
> Argh.
> Wasted a lot of time myself on similar subjects,
> so I can imagine how it hurts. Usually the bugs
> are in our own code and a lot of times we have
> to search hard for those little creatures.
Yes, well I totally forgot about notepad which I think from now on will be
what I use. A good find becuase its also a hold over from the beiginnings of
windows time - like me :-)
> This time the riddle seems solved, but unfortunately
> XP with SP2 and Acrobat 7 are out, so we have to care
> about this bug, even if it would get fixed one fine day.
I have filed a bug report with Adobe so I'm hoping it will get some
attention especially as I talked tech and not the usual "it doesn't work
gasping plea".
> I can even clear up the CoInitialize-difference.
> I had placed both calls exactly like in your new
> example, but by accident I had written
> CoUninitialize(NULL), which was compilable,
> but crashed by itself.
> Now using CoUninitialize() without a parameter
> works fine. Good that you insisted!
>
This is fantastic news because I was having other issues by starting ole,
not good for what is supposed to be a quick bug fix.
OK, so all mysteries are solved (or at least explainable).
Leslie.
David Lowndes
>attention
If you can, please let us know if you hear anything from them.
Dave
Leslie Milburn
I will do, although they say the won't contact the person who reports the
bugs - thats customer service for you.
Leslie.
"David Lowndes" <dav...@example.invalid> wrote in message
news:4ec0a15kgm29kn3pc...@4ax.com...
Alexander Grigoriev
execution" exploit for this apparent buffer overflow in Acrobat7 shell file
handler. This will give the necessary publicity.
"Leslie Milburn" <CD...@NOSPAM.bigpond.com> wrote in message
news:OwphXHMa...@TK2MSFTNGP09.phx.gbl...
David Lowndes
>execution" exploit for this apparent buffer overflow in Acrobat7 shell file
>handler. This will give the necessary publicity.
A vicious rumour of one may be good enough.
Thinking about it, I'm sure there must be scope for such a thing with
this horrible wide reaching problem ;)
Dave