Windows Taskbar Stealing Focus from Panel?

[amhas]

I have a situation where we run through several startup applications on our system and then eventually one of our applications calls system(main_gui.exe) to load a panel that is full screen. The taskbar is set to hidden on Windows 10.  Once the main GUI is loaded, I would expect that a keyboard press would operate a button on the panel, but it does not do that until the panel is clicked (anywhere on the panel, does not have to be a button).  It seems as if the panel is not in focus.

I've tried adding MakeApplicationActive(), ProcessSystemEvents(), and SetActivePanel() in various combinations and orders after the DisplayPanel() call.  Nothing works. 

We originally wrote the program for NT/XP on an embedded system many many years ago using CVI 5.0.  We finally have upgraded to CVI 2015 SP1 and Windows 10 and I'm now experiencing this issue.

I believe the way Windows 10 tries to notify the user that the application launched (pops up the taskbar and blinks the icon) steals focus from CVI's panel until you either click on the panel or the taskbar icon. 

I'm getting ready to try modifying ForegroundFlashCount to see if this might help the issue.  I'm hoping that I don't have to modify ForegroundLockTimeout as I have no idea how this may impact applications written by other companies that run on our system.

Additional Info:

• Windows 10 with CVI 2015 SP1
• Panel size is set to screen resolution.
• Panel has no menu bar, no scroll bar, close control is None, set to Auto center on load.
• Everything is left unchecked in "Other Attributes" (Sizable, movable, can maximize, can minimize, title bar visible, has taskbar button, conform to system colors, use windows visual styles for controls, scale contents on resize)
• Panel is set to float always.
• Switching to a visible taskbar or making the panel float to never does not help.
• The buttons do not use callback functions, after the DisplayPanel() is called the app a while loop runs with GetUserEvent() to determine what key has been pressed.

[amhas]

Changing both ForegroundFlashCount and ForegroundLockTimeout to 0 helps keep focus on the panel.  However, this only applies to the current user. The problem is that when a new user is created the settings for those two registry items are set to the default.  I could set them during each startup with a script, but this is not ideal.

I'd really like to know if there is something I'm missing from a CVI side that I could call to regain focus from the taskbar? 

I'm not sure why MakeApplicationActive(), or SetActivePanel() doesn't work to regain keyboard focus correctly.

[Sil.VI]

Hi Amhas, 

Thank you for the details, from a CVI perspective and to my knowledge the MakeApplicationActive and SetActive Panel functions would be the ones to help you best for this issue. Another detail that I found while searching for this issue was that if you configure the Floating Panel attribute to other than Never, it should force the application to be focus whenever it i active. Perhaps a combination of your current setup with this property set to always or app active will help you. 

Hope you can find this information useful! Let us know if you have furhter questions

[amhas]

Thank you, Sil.VI.  The panel is set to float always.  But I've also tried the other options with no luck.

I was able to put together a couple projects that duplicate my issue (at least on my system).

Interesting to note is that if I use the command line and pass only 3 or less then I don't have the issue.  Once I pass 4 (loops) or more then I no longer can use the keyboard when the main gui loads until the panel is clicked first.

The code is pretty explicit, but here are some notes on the project and some additional observations:

• Launcher.exe is the project I use to fire off everything.
  • Launcher will execute 4 loops of Launcher2.exe as the default
  • If using the command line then you can pass a number (i.e. "- Launcher 3" to run 3 loops of Launcher2.exe)
• Launcher.exe uses system() calls to execute Launcher2.exe but LaunchExecutableEx() to launch the main gui
  • This mimics a similar routine in the actual project.
• Launching gui_startup.exe directly works fine
• 3 calls or less to launcher2.exe works fine, 4 or more makes the keyboard unresponsive until a panel click
• This happens on both my deployed system and dev system (runtime only vs IDE system)
  • Both have Windows 10
• Running this on another developer system that has Windows 7 does not have an issue no matter how many calls to Launcher2.exe (tested 15 loops).

[Sil.VI]

Hi Amhas,

Thank you for the attached code and the explanation, I ran the launcher application and passed through the loops and buttons multiple times but the panel was always set in front of my other panels. I am running CVI 2017 though. Is there a specific combination of clicks needed to reproduce this behavior?

[amhas]

Thanks, Sil.Vi.

The steps I run through to duplicate the issue are to fire off the Launcher.exe and don't touch anything until after it loads the final main GUI.  Then without using the mouse, or touchscreen/touchpad if you have one, I then press F12 to try to activate the shutdown button (it only closes the panel, it doesn't shutdown windows).  If the keyboard doesn't respond, then I click anywhere on the panel and then immediately try F12 again.  This then makes the panel respond to keyboard input.

For me, the panels always appear in front of everything, even the final GUI with buttons, it is displayed in front but won't respond to keyboard presses until the panel is clicked somewhere.

I wonder if this is not an issue for CVI 2017 as I'm using CVI 2015 SP1.  Also, what OS do you happen to be running on?  I was able to duplicate on both of my Windows 10 (v1709) systems but not on my Windows 7 machine.

Thank you very much for trying out my project.

[amhas]

I have an update if anyone is interested in this or someone down the road runs into to something similar.

I replaced the code that launches the final executable that displays the main GUI from using LaunchExecutableEx() to system() with a cmd call.

I changed it from:

//Loop Launcher2.exe a bunch of times
...

//now launch main GUI
LaunchExecutableEx ("..\\startup\\gui_startup.exe", LE_SHOWNORMAL, &launchHandle);
RetireExecutableHandle(launchHandle);

To the following:

//Loop Launcher2.exe a bunch of times
...

//now launch main GUI
system("cmd /c start \"\" \"..startup\\gui_startup.exe\"");

Now I can loop it 20+ times without interfering with the keyboard input to the main GUI.

My question is, why does this work?  I was using LaunchExecutableEx() because I wanted the program to return back without waiting for gui_startup.exe to finish executing.  It does return, and the program exits as expected, but this grabs the focus from gui_startup.exe (despite the gui_startup being visually on top of everything).

However, when launching it from the command window through a system call, the cmd window opens and closes rapidly, returns back to the program, and the program exits, but the focus remains on gui_startup.exe throughout this and so the keyboard responds as expected.

Anyways, this seems like a better option than changing ForegroundLockTimeout in the registry, but it still feels like a bandaid.  Curious if anyone has any thoughts on why the two calls return back to the original program differently and thus affect the keyboard behavior after the main GUI is launched.