GetOpenFileName and GetSaveFileName

[acar]

I'm having some problems with these routines. GetOpenFileName works but seems to screw up subsiquently called threads (see recent Forum Thread) whilst GetSaveFileName won't work at all - I type in a file name and press save and nothing happens - I was hoping that the dialog would return with the name I'd input in the ofn structure. Does anyone have any experience of these routines and possibly even some code examples that I can examine. Thanks for your help. ACAR.

[Steven_L_Intel1]

We provide an example of using GetOpenFileName in the compiler samples. GetSaveFileName is almost identical.

[acar]

Yes, I think that is where I originally got my routine from. The only thing that I appear not to be doing is to set ofn%hinstance (I've set it as in the example code to NULL although my program is a W32 application). I dug about a bit and found the following Forum Thread from 2002:

HomeForumsIntel Visual Fortran Compiler for Windows ODBC and getopenfilename

In my application I had previously set the Stack Reserve Size to 100M (I can't recall why I did this) so I reduced it to 10M and now these routines work - the thread I call after the call to getopenfilename starts correctly and the call to getsavefilename returns correctly when I press the save button.

This seems totally bizarre to me (in my relative ignorance of what is going on behind the scene). Anyway I seem to have solved the problem for the time being unless my application happens to need a larger Stack Reserve Size or any other parameter I happen to change affects it. I wonder if anyone can explain in laymans terms what is happening here. Also, since it is a recurrent issue might a note of the fact be put into the help system and/or as a comment in the sample files?

[IanH · Accepted solution]

Are you sure that when your threads are done they are being cleaned up correctly (with a call to CloseHandle)? At 100 MB a pop it wouldn't take too many to exhaust your virtual memory address space on a 32 bit system. The error message from CreateThread that you reported in the other thread would be consistent with that.

[tropfen]

Hello,

having a similar problem, i would like to understand the reason . What ist the conection between StackReserveSize and getopenfilename?

Thanks in advance
Frank

[acar]

Ian, it is true that I have not been correctly cleaning up with the CloseHandle function in that routine - I've used ExitThread in other threaded routines but I must have forgotten it here!!! So, I've just added that to the threaded routine. I pumped the stack reserve back up to 100MB and yes it now works. I'm really grateful for your help - Many thanks. ACAR.

[IanH]

ExitThread and CloseHandle deal with different concepts. ExitThread is what you call when you want the thread executing the call to stop processing there and then. It can be a bit brutal for things like language run-time libraries (I don't know whether this is significant for ifort or not - I don't do bare win32 threads in fortran (and it's been a while since I did this stuff in any language)), so generally its a better idea that that your code for the thread is structured so that your thread's execution sequence just ends up RETURN'ing from the top level thread procedure when you want the thread to go away. But that all just relates to the execution sequence of the thread.

CloseHandle deals more with the system resources associated with the thread (I don't know whether that includes the thread's stack or not, but your experience indicates that it does). The handle returned from CreateThread is owned by your program's process and can be used by any thread in your process to manipulate/query information about the thread. When all handles to the thread have been closed and the thread has stopped executing the system can blow away the resources associated with the thread. If you are never going to do something like manipulate the thread/wait on it/query its exit code, then just call CloseHandle immediately after a successful call to CreateThread.

This has little to with fortran and all to do with the Win32 api. MSDN is your best resource for this stuff, you just need to translate the C code to fortran.

I'm not familiar with the windowing library that you are using, but the fact that you need to have multiple threads for user interface stuff still bothers me. Care to share the code that creates the thread and maybe the message loop/modal dialog box call part of the thread's code?

[acar]

Okay I think I will replace ExitThread with CloseThread throughout the program and see how that works. The windowing library does offer its own dialogs which presumably work from the libraries message loop. My application, however, was originally written in CVF using the quickwin graphic features and plenty of dialogs. When I moved up to IVF I decided to bite the bullet and go for OpenGL graphics via GINO. Rather than recreate some 150 dialogs in GINO I decided to stick with the ones I'd already created in the CVF resource editor. And, as you noted previously, these dialogs run in their own thread which cannot (I presume) be made to communicate with the GINO message loop. If I simply run the dialogs unthreaded then my application becomes unresponsive. The application also becomes unresponsive if I do a large time-consuming calculation like a FE analysis. As such, I've put all dialogs and time-consuming calculations into their own threads. When, in a seperate thread, I need to get something plotted to the screen, for example, I have to use a postcallback function from GINO to force the primary application thread to conduct the plotting. In general all this has seemed to have worked well and the application performs like a normal windows application but I do admit it is somewhat complicated!! I've attached the dialog_threaded routine to which I added yesterday the CloseThread routine. I have also added a sample dialog routine (for creating points) - you will see calls to GMPostCallBack which excite the primary loop to take some action. I'd certainly be interested in any thoughts you may have Ian and thanks again for your interest and continued help.