Call to getopenfilename causes subsequently invoked thread not to start

[acar]

In my application I am running dialogs in a seperate thread so as to keep the main window etc active whilst the dialog is open. This works fine. However, if I make a call to getopenfilename, which seems to work correctly, and then call a dialog, the seperate dialog thread doesn't start - the threadhandle returned by createthread is zero leading to failure of the functions setthreadpriority and resumethread. Does anyone have any experience of this problem and how to circumvent it. Thanks, ACAR.

[IanH]

Quoting acar

In my application I am running dialogs in a seperate thread so as to keep the main window etc active whilst the dialog is open. This works fine...

Are you sure? That is an unusual threading arrangement, one that I imagine if you didn't get right then all sorts of wierd and wonderful things could start happening.

Typically you would have one thread that handles all your user interface interaction - it creates all windows, receives all user input messages (runs the message loop), does all significant manipulation of those windows and ultimately destroys all those windows. In response to user input, worker threads are be created (or existing worker threads are tasked) to carrying out lengthy calculations that might otherwise prevent the user from being able to interact with your application.

Dialog boxes and other user interface elements often need to notify their parent and owner windows about changes in their state (messages to say "someone clicked on me", "I've been (de)activated", "I've been moved", etc). If the thread that handles input for that window is busy doing calculations then it can't handle those notifications, and the dialog box will either stop responding or start behaving badly (as all children are wont to do when the folks aren't paying attention).

There are a number of options for how worker threads can communicate with the UI thread. Whatever you choose, avoid having threads other than the one that initially created a window from directly manipulating the window. Leave all user interface stuff to the user interface thread.

Even if you could merrily do cross thread manipulation of windows, there's no point having multiple threads just processing user interface events, because users simply aren't that quick.

[acar]

Yes Ian that is what I've been doing. The reason is that I'm using a third-party gui so if I call a dialog then the gui's message loop is blocked (i.e. the window becomes unresponsive) until the dialog returns unless I run it in a seperate thread. The approach has worked fine until today when I added the call to getopenfilename and I got the behaviour I reported. I can only presume that something is not being reset properly following the call to getopenfilename. The problem does not occur when I use other common dialog boxes such as choosecolor. I'll have another fiddle about tomorrow to see if I can get to the bottom of it.

[IanH]

Out of curiosity - which third party gui?

You are creating modal dialog boxes? The windows api calls that create modal dialog boxes (such as GetOpenFileName) have their own internal message loop. I don't understand why this internal loop wouldn't continue to dispatch messages (other than input messages - the owner window is disabled by design) to your main window. It might be unrelated, but the fact that you have to create threads just to get dialog boxes to work makes me suspicious.

What does GetLastError say after the call to CreateThread?

[acar]

Gino (www.gino-graphics.com) is the third-party gui.

Most of my dialog boxes are actually modeless as the application is fundamentally dialog driven the user can have a number of dialogs open simultaneously and can also access toolbar buttons and operate 'dynamically' on the model with the mouse. To avoid blocking of the message loop I have threaded the calls to open dialogs. The only issue with this is that I need to post callbacks from the thread to the now independent message loop.

The dialog that is causing the problem is actually modal and is opened prior to the message loop being activated - it is effectively the starting dialog for the application where the user is prompted to either open an existing model or create a new one. This dialog then calls the (as you say) modal dialog GetOpenFileName.

I've just tried changing the dialog type from modal to modeless - and it has made no difference. I shall explore further today and see if I can't get a solution to this problem.

[acar]

Just looked at the last error following my abortive call to CreateThread - it tells me: 'Not enought storage is available to process this command'. I'm still not getting this to work so if you have anymore ideas then I'd be pleased to receive them. Thanks, ACAR.

[acar]

I've discovered a fix to this although I don't understand the reason behind it - see recent IVF Forum Thread titled getopenfilename and getsavefilename.