Losing Window Focus after printing with Fortran_Winprint.f90

[Ken2]

I have a program that seems to lose the Window focus after printing using the Fortran_Winprint routines.I am using version 2011.9.300of thecompiler. On my home printer, which is a wireless printer, the input cursor comes back on and accepts input only after the print is complete, but at work on a network printer I never get the cursor back for an input. In my program I am picking a selection from a list of options on the screen, when I pick 6 the print subroutines are called and the printout proceeds and then the list of options are again printed out in the output window.Which seems to say the window is still active. At that point I should be able to input a number for the option wanted next, but it will not take any input from the keyboard. I have to mouse click on the desktop and then click back on the window before it will accept input again. Does any one have any ideas on fixing this? I do not remember having the problem in this same program before this version of the compiler.

[Ken2]

The non-shell worked fine. Version 2001.4.196 also works fine. FYI. I tried the flawed version of my programon both and XP SP3 32 bit and a Windows7 64 bit and the error occurs in both operating systems. When compiled in aversion without the problem there is no errors in either operating system.

[Ken2]

I installed latest version 2011.10.325 last night. This version does not have a fix for this problem.

[Steven_L_Intel1]

No, it wouldn't. We can reproduce this and are working on it.

[Ken2]

Have you made any progress on the fix?

[Paul_Curtis]

THINK about your "issue" for a moment.

The "fix" for this "problem" will without doubt be to add a SetFocus(hWnd) into the code, whether somewhere internal to a QWin routine or in your own code. When a particular window loses focus, a Windows issue entirely and nothing at all to do with Fortran as has been pointed out, the API provides an explicit means to recover the focus, no big deal, happens all the time, that's why that tool exists.

Instead of offloading this trivial nonsense to Intel with lots of boohoohoo-ing (big waste of their time), you could simply add a SetFocus() to your own code as an explicit operation, which would be much superior to relying on implicit behavior, which clearly varies, by a library routine which you have not written and have no control over. Then, this major show-stopping problem completely disappears, whether Intel ever "fixes" it or not.

[Steven_L_Intel1]

I'm not sure that would help, Paul. The issue is not focus but rather the message handling loop that handles keypress messages. The window has focus but the messages aren't being processed correctly. We greatly simplified QuickWin's previous keyboard input processing, after many customers had problems on Win7. We consulted with Microsoft on how to do this. And for most customers, that worked. Yet for this case, it made things worse.

Diagnosing this sort of problem is very difficult - it's not made any easier by the problem going away when you run the program under the debugger! Don't expect a quick fix for this.

[Robert_M_Intel4]

Just as an update, we are working on this problem. As Steve mentions, debugging issues like this in Quickwin is difficult. I do wish that simply using SetFocus would work, but the issue here, again as Steve mentions, has to do with the message queues and the changes made to Quickwin to accomodate Window Manager changes in Windows 7.

We have not forgotten you and are working toward a solution. If I find a circumvention I'll post it here.

Bob

[Robert_M_Intel4]

Ken,

I'd like for you to try something for me. Edit FORTRAN_WINPRINT.F90, removing the call to GetForegroundWindow() and assigning NULL to that member of the PrintDlg_Struct structure:

! Initialize PRINTDLG_Struct
!
PRINTDLG_Struct%lStructSize = SIZEOF(PRINTDLG_Struct)
!PRINTDLG_Struct%hwndOwner = GetForegroundWindow()
PRINTDLG_Struct%hwndOwner = NULL

I'm seeing good results here with this change. Give it a try and let me know what you see.

Thanks.

Bob

[Ken2]

That fixes the problem and I see no other issues at this time. Thank you.

[Steven_L_Intel1]

That is just a workaround, not a solution, however. What it means is that the dialog has no parent window and will come up centered on the desktop.

[Steven_L_Intel1]

Bob has convinced me, showing various discussions on Microsoft boards and blog posts, that the use of GetForegroundWindow here is in fact incorrect and the source of the problem. Please use NULL.

I will be correcting all of the samples where GetForegroundWindow is used.

[andrew_4619]

@Steve Whilst looking for something else I found this thread. I used some code from the getfileopen sample some years back and I note having checked the latest release that this is modified to use NULL rather than GetForegroundWindow() for the file structure. I have had a play in my code using both options and done some googling but learned very little. There appears to be no obvious effect. What does setting =NULL actually do?

As an aside I note on my current computer if I open  a file open dialog I used to be able to right click on a file and (for example) open it in notepad, edit save and then open in my fortran application. These days on Win 7 x64 if I right click on the file my Fortran app always hangs on the point of click and has to be process killed in task manager. Any ideas? Do other people see this behaviour? 

[Steven_L_Intel1]

NULL means it uses the desktop as the owner window. Years ago I thought GetForegroundWIndow() was the right thing to use here, but later learned that this was a common misconception and it created problem for QuickWin applications.

I have no idea regardimg the right-click behavior. Perhaps the control is not handling that properly. Did you try changing the owner to NULL to see what happens then?

[Anonymous66]

Hello,

Setting PRINTDLG_Struct%hwndOwner to NULL allows the application window to get its focus back once the dialog has been dismissed. GetForegroundWindow() does not.

Are you using the latest version of the compiler? If so, could you attach a test version of your application?

Annalee

[andrew_4619]

Did you try changing the owner to NULL to see what happens then?.....

Yes my thought was it might fix the issue but it hangs just the same. It was a nice feature to have, many a time you think at the last moment it would be good to make a safe copy of the file you are about to open.