Losing Window Focus after printing with Fortran_Winprint.f90

Losing Window Focus after printing with Fortran_Winprint.f90

Ken's picture

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.

36 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Paul Curtis's picture

Rather than rely on some accidental and implicit compiler-related feature, use SetFocus(hwnd) to explicitly restore the focus to your parent window's handle.

Ken's picture

Well the cause of the problem is a change or bug in the complier. I have some earlier versions of the compiled program that do not have this problem. I'm not sure which version this change or bug occurred in. I think the good one was from VS2008. I have tried to install version 2011.8.278of the compiler, but in fails with a setup error. I guess I will have to report this problem to IVF support.

Steve Lionel (Intel)'s picture

It's neither a change nor bug in the compiler. The only possible compiler-related issue is if your application is a QuickWin app, but even then I am doubtful. Fortran_Winprint just uses standard Windows common dialog boxes to ask you to select a printer - all matters of focus are handled by Windows.

Steve
Ken's picture

It is a Quickwin application and it definitely only occurred after the compiler was updated.

Ken's picture

I keep a backup of the old projects so I copied the source filethat works correctly, without any changes, into the new project and recompiled and now the recompiled code has the same error. It is definitely the compiler.

Steve Lionel (Intel)'s picture

Can you attach a small program that demonstrates the problem?

Steve
Ken's picture

I have a small program made from the original file that shows the same error. I will try to attach file, but I'm sure sure how to. I can send if you give me the address. It's a little long to copy here.

Steve Lionel (Intel)'s picture

See instructions link in my signature below. Or you can use Intel Premier Support.

Steve
Ken's picture

Ok done, the files is there.

Attachments: 

AttachmentSize
Download Focus.for6.74 KB
Steve Lionel (Intel)'s picture

Which compiler verson gave you the result you prefer? This program does not run - it skips over the open of unit 2 and the setting of NPRINT to 2, causing an error later.

Steve
Ken's picture

It runs without that error here. I will attach the compiler .sln and .suo filesfor this program. It may be an option that I use.
I do know know which version I started having the focus issue. The one that works was complied 10/19/2010 and I would have been using the latest one for that time.

I have tried to install older versions starting with the last one before 2100.3.900 in order to determine which version the error occurs in. It comes up telling me that I do not need to reinstall the VS2010 files, but then when I continue I get and error telling me to try to run the setup file again and it fails. Should I be trying to load the files without the VS2010 files included? I did not want to have both VS2008 and VS2010 installed.

I would greatly appreciate any help you can provide.

Here is the contents of the .sln file for 2010 version maybe it will help you:

Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{6989167D-11E4-40FE-8C1A-2192A86A7E90}") = "Refract", "Refract\Refract.vfproj", "{A7785478-12C3-4BB2-BF59-A374727E7392}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Win32 = Debug|Win32
Release|Win32 = Release|Win32
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{A7785478-12C3-4BB2-BF59-A374727E7392}.Debug|Win32.ActiveCfg = Debug|Win32
{A7785478-12C3-4BB2-BF59-A374727E7392}.Debug|Win32.Build.0 = Debug|Win32
{A7785478-12C3-4BB2-BF59-A374727E7392}.Release|Win32.ActiveCfg = Release|Win32
{A7785478-12C3-4BB2-BF59-A374727E7392}.Release|Win32.Build.0 = Release|Win32
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal

Attachments: 

AttachmentSize
Download Focus.sln881 bytes
Download Focus.suo11.5 KB
Steve Lionel (Intel)'s picture

I need the .vfproj file - thanks.

Steve
Ken's picture

I have attached the file you were needing. Please let me know if I am missing any other info you need.

Attachments: 

AttachmentSize
Download Focus.vfproj2.01 KB
Steve Lionel (Intel)'s picture

Thanks for the .vfproj. It told me you had changed the options to add /Qsave, which eliminates the error I saw.

I can now reproduce the problem and will escalate it to the developers.

Steve
Ken's picture

Thanks for your help. Will you report their finding here? Do you happen to know in which version this first occurred?

Steve Lionel (Intel)'s picture

I have not done the "binary search" yet to see when it happened - 11.1.048 is ok. Oddly, I find that the program runs correctly when run under the debugger! I tried to create a short program that put up a message box in a loop where it also read from the "console" - oddly, this works fine in IVF and hangs in CVF!

Unfortunately, issues like this are very difficult to track down, but we have some experience doing so. Don't expect a quick fix, but if I find a workaround, I will let you know.

Steve
Ken's picture

I did some checking and version 2011.3.175 works correctly. It seemsversions 2011.5.221 and newer have the error.

Is there a way to install 2100.3.175 without its VS2008 shell and use the VS2010 shell along with 2011.9.300?

Steve Lionel (Intel)'s picture

Yes - just install it. You can select the compiler in Tools > Options > Intel Fortran > Compilers.

I suspect I know what change triggered this - it was to fix another QuickWin keyboard focus issue people were reporting on Windows 7. Looks as if we have more to do here...

Steve
Ken's picture

Do I need to load the non-shell versions? I am using the VS2010 shell version of 2011.9.300. I have tried the using the shell versions, but they usually fail to install without removing the installed firstversion or install with errors.

Steve Lionel (Intel)'s picture

You should be able to install either - it should skip the shell install. But if you want to try the "no shell" version, that would be fine.

Steve
Ken's picture

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.

Ken's picture

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

Steve Lionel (Intel)'s picture

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

Steve
Ken's picture

Have you made any progress on the fix?

Paul Curtis's picture

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.

Steve Lionel (Intel)'s picture

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.

Steve
Robert Mance (Intel)'s picture

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 Mance (Intel)'s picture

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

Ken's picture

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

Steve Lionel (Intel)'s picture

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.

Steve
Steve Lionel (Intel)'s picture

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.

Steve
app4619's picture

@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? 

Steve Lionel (Intel)'s picture

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?

Steve
Annalee (Intel)'s picture

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

app4619's picture

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.

Login to leave a comment.