GetOpenFileName from console app.

GetOpenFileName from console app.

I've got a small problem that might be of general interest.

I'm updating an older console based utility. It takes a number of files as input, interacts with the user a little, then spits out a processed file and exits. Instead of forcing the user to type in path and filename, I'm now using the WinAPI call GetOpenFileName.
This has worked for me in several QuickWin and mixed QuickWin/WinAPI programs. In this console application, however, the first occurrence of the dialog appears without the focus and behind the console window. After shifting focus and selecting a file, the program proceeds and subsequent instances of the dialog appear with focus as desired.
How can I force the first occurrence to have focus when GetOpenFileName is called?
Thanks, Cliff

15 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

My guess is that you're setting hwndOwner to NULL. Set it instead to the value returned by GetForegroundWindow().


Steve - Intel Developer Support

A very good guess. I had read this comment in one of the samples I cut and pasted into this project

ofn%hwndOwner = NULL
! For non-console applications, set this to the hWnd
! of the Owner window. For QuickWin and Standard
! Graphics projects use GETHWNDQQ(QWIN$FRAMEWINDOW)

and assumed it did not need to be set for a console application.
Unfortunately, when I tried the following

ofn%hwndOwner = GetForegroundWindow()

the behavior is unchanged. The dialog still appears behind the console window.
Am I using this wrong? Is there another way to force the focus to the dialog?
Thanks, Cliff

Don't know - it works for me. Try building the GETOPENFILENAME sample that comes with CVF and see if it does the same thing.


Steve - Intel Developer Support

Of course, the sample you suggested worked as intended. But I couldn't see any significant difference between it and my code. So I started with the sample and made a minimal number of changes, one by one, until I got the same behavior.
The first change was to make the sample Program a subroutine

Subroutine GetFile( FileName )

Then I wrote a minimal test routine

Program Test_GetFile
Character FileName*256
Print *, ' Ready to try. '
nTry = Number( 'tries you want to make' )
Call GetFile( FileName )
Print *, ' Got ', FileName
End Program

User input is required for the function Number, as I intended to loop over the GetFile several times in the next iteration of this code.
The function Number is one of a collection of tiny utility routines I wrote ages ago for structured user input. Here's its code

Function Number(Question)
Character Question*(*)
Write(*,'(a)',Advance='NO') &
' Enter the number of '// Trim(Question) //':'
Read ( *, * ) Number

And guess what? Adding the call to this routine caused the problem to reappear. The behavior seems to be associated with a read from the console and occurs whether I use the default IO LUN or read explicitely from unit 5. If the Read is commented out, the problems goes away.
Any ideas why this is occurring?
Thanks, Cliff
Incidentally, CVF 6.1.

This is Windows 2000 or XP, yes? I think these versions of Windows don't like to take focus away from a window accepting input.


Steve - Intel Developer Support

Yep, Win2K SP2. Is there any way to force the change of focus to the dialog?

I tried to figure out how you might get the dialog box to take focus, but couldn't. This is not really my area of expertise. The problem is that your code doesn't create the dialog window, so you can't call SetFocus on it. I haven't tried this, but I wonder what happens if you call SetFocus with NULL before you call GetOpenFileName...


Steve - Intel Developer Support

No luck. I tried to SetFocus immediately before GetOpenFileName and the behavior was identical.
I could make the whole project QuickWin, rather than console, but that seems like overkill.

Any other suggestions?
Thanks, Cliff

Perhaps someone else (Jugoslav?) has an idea - the key seems to be to get focus off of an input window.


Steve - Intel Developer Support

Hi, I am using a console application and have noticed the same annoying behaviour of the OpenFileName dialog. I have tried lots of things to solve it but the problem seems to be that there is no working (nor documented) method for removing the focus of the console.

However, I recently found a workaround that solves the problem! The idea for the solution came from the observation that the OpenFileName dialog comes on top only if it is called AFTER having entered and exited another dialog first.

So the thing to do is the following:

1. Create a dummy dialog DLG (that will never be displayed)

2. Create an initialization subroutine INIT for the DLG dialog (see below).

3. Make sure that the INIT sub is called before displaying the DLG dialog by calling DlgSetSub before launching the DLG dialog with the DlgModal(DLG) call. This is an undocumented feature that is used in some of the DF98 code samples (to find examples of this just search the DF98 samples folder for DlgSetSub).

4. In the INIT sub do the following:

hWNDCM = FindWindow(0,'MyConsoleTitle'//CHAR(0))
I = SetWindowPos (hWNDCM,HWND_NOTOPMOST , 0, 0, 0,

5. Launch the dummy DLG before using OpenFIleName for the first time.

The DLGEXIT kills the DLG dialog before displaying it. Modify the console title so that it (exact) matches your console. The net result of this is that the console loses its topmost focus. I dont know why this works but somehow creating the dummy dialog stirs the windows API status in the right direction.

A slightly modified trick can be used to solve another problem, namely to ensure that the keyboard focus is on the console window after having launched other processes using e.g. CreateProcess.

I hope this helps. I have tried it on Windows 2000SP3 using DVF6.5a. If you run into problems I am happy to mail anyone a short code snippet.

Erik Traneus

Sorry, I somehow missed that November thread.

However, guys, I cannot reconstruct the annoying behaviour on my Win2k SP3. Attached is a console app which just displays the OFN dialog, and it always appears on top of console window on my computer, ran from VS, Explorer or command prompt; there's nothing special in the code. Could someone verify it please?

About the only parameter that should be taken care of is OFN%hwndOwner. I set it to 0 and it worked fine for me. Perhaps one should specify console HWND but obtaining it can be a PITA. (I can post how, but it doesn't make sense if the attached sample works).



Oh, I see now; I didn't read frieler's posts carefully. Cancel my previous post; READ(*,*) seems to be the culprit; why, I don't know.

I played with it a bit and it seems that a clearer solution is to call SetForegroundWindow from hook procedure (keep on reading -- it ain't that hard). Like with DFLOGM dialogs, SetFocus or SetActiveWindow or hWnd anything won't work either before or after call to modal; you have to insert the call during the lifetime of dialog. To do it, specify a hook callback in OFN:


(requires EXTERNAL or explicit interface)

And insert the following hook procedure (may be shared accross different OFN calls):

INTEGER FUNCTION PXOFNHook(hDlg, Msg, wParam, lParam)

INTEGER,INTENT(IN):: hDlg, Msg, wParam, lParam

INTEGER::         iSt

   iSt = SetForegroundWindow(hDlg)

I'll try to offer an explanation for the behaviour as well: new Windows don't allow the applications to arbitrarily steal the focus. However, it is allowed for certain, "friendly" processes (you probably saw Explorer, IE timeouts or OE errors sometimes popping up) but under certain conditions. OFN dialog is kind of Explorer window; somehow, READ affects the state of console window so that Windows "thinks" that the application is receiving the input; thus, it does not bring the OFN to foreground, because it doesn't attempt to bring itself to the foreground explicitly. Explicit call to SetForegroundWindow seems to fix it.

The above are more my conclusions than it is explicitly documented; the whole thing rather muddy.


Hi Jugoslav,
You are perfectly right, the open file dialog appears on the top in your .exe. But try to do a fortran write/read to the console before calling GetOpenFilename ! Then the dialog is behind the console the first time.



> But try to do a fortran write/read to the console
> before calling GetOpenFilename ! Then the dialog is
> behind the console the first time.

Correct. But the dialog pops up in front as a result
from the "Hook-routine". We've been using this for the
last few years. I'll attach a small example file.


Leave a Comment

Please sign in to add a comment. Not a member? Join today