Explorer GET/SAVE FILEOPEN dialog not modal..

[isn-removed200637]

I use VF version 5.0D on WIn NT (I have to type this in the 'subject' box when posting, but this info fails to appear in the message.. why?....)

I have found that it is possible to open multiple copies of the Explorer-type Open common dialog box from one of my dialogs, all of which remain active, even after I have closed the dialog box which opened them.
How can I find out if there is already an instance of an Open dialog box to stop another (superfluous one) being created?

The problem appears to arise because the Open dialog box is not modal and therefore permits switching to other dialogs/windows before it is closed.

[Jugoslav_Dujic]

I guess this is mea culpa... Well, I'm not 100% sure what's going on, but if you followed my suggestion for positioning GetOpenFileName dialog box,
this might happen -- I haven't thought of that "side effect". Problem is, that Open dialog box is, AFAIK, modal, but the dummy popup window you created behaves like a modeless dialog, and that behaviour is "extended" to its children. It's a bit tough to explain, but in general, modal dialogs aren't application-modal; they are modal for the window that created them, but the other popups and modeless dialogs in the application remain active. Does it happen when you don't use that dummy popup edit-box? I guess not.

As a workaround, you may:

a) Define a global flag (say, bgOFNopened) using it something like this:

 
IF (.NOT.bgOFNOpened) THEN 
      bgOFNOpened=.TRUE. 
      iSt=GetOpenFileName(...) 
      bgOFNOpened=.FALSE. 
END IF 

Looks like a tweak, though.

b) Use the solution suggested by Guus recently (i.e. define a hook for
OFN dialog which sets the window position at WM_INITDIALOG).

Regards,

Jugoslav

[Jugoslav_Dujic]

...just got another, simpler, idea -- why not disable the "open" button/menuitem before GetOpenFileName and enable it on return?
If necessary, you could disable entire parent dialog using EnableWindow(Dlg%Hwnd, .FALSE.)

Jugoslav