For two weeks, each day since I installed Windows 7, I have been struggling to get something to work. Something which worked perfectly ok in XP. It's driving me mad, poisoning my life, ruining my days. Why such a simple task works SO CHAOTICALLY!?
I think I discovered a bug in Windows 7, specifically in the way the ShowWindow function works in the standard theme (Aero).
To demonstrate this, I uploaded 2 C# WinForms applications and their source code.
http://www.axonnsd.org/W/P007/BugsDemo.rar
HideableApplication represents an application which you can hide in the SysTray when you close it. Double clicking the SysTray icon reveals it and right clicking will reveal the "Exit" option.
HideableApplicationRevealer attempts to show HideableApplication's window.
The reason I need to accomplish this task is because I minimize my Total Commander and FireFox to the Tray and I want to bring them back via a HotKey. Total Commander offers such a functionality but it is broken.
On Windows XP I managed to accomplish both these tasks without any problems, using the code I attached.
On Windows 7, the behavior is erratic at best, and non-functional at worst.
When HideableApplication runs inside Visual Studio everything works:
Trying to reveal it via HideableApplicationRevealer from Visual Studio => SUCCESS
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => SUCCESS
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => SUCCESS.
When HideableApplication was executed manually (via .exe from Debug folder) AND Visual Studio IS STARTED, it works if I use admin rights or run it manually:
Trying to reveal it via HideableApplicationRevealer from Visual Studio => FAIL
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => FAIL
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => SUCCESS.
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut (start menu) which has been given ADMIN RIGHTS => SUCCESS.
When HideableApplication was executed manually (via .exe from Debug folder) AND Visual Studio HAS BEEN SHUT DOWN: it only works if I run it manually (double click exe):
Trying to reveal it via manual execution of HidebleApplicationRevealer.exe from Debug folder => SUCCESS
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut => FAIL
Trying to reveal it via running HIdeableApplicationRevealer.exe via a Scheduled Task with Admin Rights => PROBLEMS: Window blinks on the TaskBar instead of being shown!
Trying to reveal it via running HideableApplicationRevealer.exe via keyboard shortcut (start menu) which has been given ADMIN RIGHTS => SUCCESS.
If it matters, I reproduced this behavior both with the Taskbar in its standard position AND also with it set to AutoHide, in the left of the screen.
Apparently, I need admin rights to show a window, but even like this, it doesn't work right when I use the Scheduled Task workaround (create Scheduled Task with admin rights and invoke the Scheduled Task via system32/schtasks.exe /run /tn "task name"). What happens is that AFTER VISUAL STUDIO IS SHUT DOWN, the window blinks on the TaskBar instead of being shown (and has no focus). It does appear, but it has no keyboard focus, which should NOT happen because I also used the SetForegroundWindow API.
This is exactly what happens when I try to run reveal Total Commander as well: read below, same behavior: blinks on taskbar instead of being shown.
And don't even get me started on the difference in behaviors between when running it from Visual Studio and when running it from its usual C:\MyProjects folder.
My TotalCommanderRevealer and FireFoxRevealer exhibit even stranger behaviors: when starting Visual Studio, the Total Commander app stops working properly. Even if I load NO PROJECT, instead of showing TC to me, it just blinks it on the TaskBar. However if I open the TCRevealer project, it starts working again! If I shut down Visual Studio, it STOPS working UNTIL I RESTART WINDOWS.
The FireFoxRevealer instead of revealing FireFox, does something very strange: it shows a small label in the top-left corner of the screen, usually with something related to the opened tab. I suspect this has to do with the Window Style and the way the ShowWindow function works in Windows 7. However, sometimes it works, showing the actual window. But most of the time it doesn't. And when it stops working, I never get it to work again until certain unknown circumstances occur and it works again. Regardless, this worked pefectly under Windows XP and does not work at all now.
If you wish to reproduce the FireFox issue, use the code I attached: instead of searching for "Hideable Application" text in FindWindow API, search for "MozillaWindowClass", install FireFox 7 or 8 and install the FireFox "Minimize To Tray Revived" addon.
I should also mention that I'm aware of the "ForegroundLockTimeout" registry setting and I have set it to 0 everywhere it appears in the Registry. On Windows XP it is set by default to 0 but in Windows 7 the default value was 200000, which I have changed. Maybe somehow it lingers somewhere??? And Visual Studio, while running, sets it to 200000 when I shut it down, until I restart the computer? I looked in the Registry and it doesn't change, it's still 0. But who knows?
Related
I am looking for a way to run selenium tests with a chrome driver, in the background. With the background I mean as in, not the foreground focussed window. I can actually do this, but as soon as actions like opening a new tab or switching between windows (so basically switching window handles) happen in the chrome driver, the browser window gets pushed to the foreground.
So my question is, how can I prevent this from happening without running the test headless?
Any suggestions are appreciated, open for discussion.
EDIT
As a somewhat temporary solution I came up with the following.
Using the Windows 10 Virtual Desktops feature, I run the test and thus the chrome browser window in a seperate virual desktop.
I then switch back to my main virtual desktop to continue with other tasks.
This prevents the chrome browser window from being forced to the foreground.
Note that this still makes a flashing chrome icon appear in the taskbar when any of the actions described above appear.
Still looking for a more solid solution, so any suggestions are still appreaciated.
To hopefully open new perspectives and discussion points, and ultimately a solution, I will provide some more detailed info of what my code is doing.
I have 5 chrome webdrivers, and each of these webdrivers contains 6 tabs (WindowHandles).
The idea is that a certain process has to be repeated continuously on each tab. So we loop over each webdriver, and within that webdriver over each tab and set this tab as the webdrivers current WindowHandle. This makes the chrome window visibly switch to the assigned tab.
After that switch has taken place, so basic selenium automation is performed on the content of the tab, after wich we repeat the whole process.
The actual issue seems to take place when a chrome webdriver switches to a new tab (WindowHandle), at this moment the chrome window containing the tab is pushed to the foreground and steals focus. Note that this does not always takes place, often it can switch tabs without any issues. So it is unclear wether there is another factor which would cause the window to steal focus.
EDIT 2
After doing the following:
I overloaded the selenium method which is used to switch between tabs (WindowHandles), and called SetWindoPos each time. Unfortunately this did not solve this issue either. I will try to look deeper into what might be causing this and will report back. – S. Van den Wyngaert
I went out for a few hours while running the tests, and came back to see that surprisingly I was still on my main Virtual Desktop (win10 feature). This means that the issue didn't occur during the time I was gone. I started working again, opened a chrome window and noticed that shortly after I did this, focus was stolen by one of the chrome driver's windows again.
What I conclude from this is that the issue only occurs when another chrome window (not opened by a chrome driver from code) is opened.
I will keep investigating and will report back with updates.
After investigating this behavior for a few more hours I noticed that when another chrome window is open, as long as this has focus, the issue doesn't take place. So to quickly summarize this:
The issue doesn't take place when:
No other chrome windows (not selenium driven) are opened or minimised
Another chrome window (not selenium driven) is opened and has focus
Another application running fullscreen mode has focus
The issue does take place when:
Another chrome window (not selenium driven) is opened and has no focus
Note that when I talk about another chrome window I specificly mean a chrome window that is not driven by selenium, so a regular chrome window opened by the user.
Easiest way would be to run a local selenium grid. Start your node(s) as a windows service. This way the test will run in the background, without being headless.
Another good option to scale your solution, and if your machine has the capacity to run docker, is to use
zalenium
It's a docker based, auto scaling, selenium-grid solution that works pretty quick out of the box.
You can watch your tests live via the management pages, watch a recording after the fact, pause/debug with live interaction via VNC. Also something to be said for not having the worry about changing browser versions.
Last time i used it, it had the odd bug and throws an end of stream error every now and then - but that was a good year ago.
I have a UWP App that implements Cortana functionality to navigate pages. I'm deploying it in VS2015 Community on the Debug/x64 configuration.
I can say "open {my app}" and it works fine, then "open {my app} to {book} and {chapter}" and it works fine if the app is already open. If the app is not already opened and I say "open {my app} to {book} and {chapter}" it will try to load the app and briefly show the screen before it disappears, presumably from a crash.
I need to debug and figure out what it's trying to do when the app is not already opened. Is there a way to do so?
I need to debug and figure out what it's trying to do when the app is not already opened. Is there a way to do so?
Of course you could trigger suspend, resume, and background events for Windows Store apps in Visual Studio. The following is the brief testing procedure regarding uwp application lifecycle events.
In the Visual Studio debugger, you can manually suspend, resume, and terminate your apps to debug process lifecycle events. To debug a process lifecycle event:
Set a breakpooint in the handler of the event that you want to debug.
Press F5 to start debugging.
On the Debug Location toolbar, choose the event that you want to fire:
Note that Suspend and terminate closes the app and ends the debug session.
I am building a .net 4.5 (c#) app and packaging it with Squirrel for Windows.
As expected, the releasify command creates one Setup.exe file and one Setup.msi. The Setup.exe installs the app as expected on the two windows 10 computers I had access to.
On the windows 7 I used to build the app though, when I try to open Setup.exe, the window where I double clicked the icone goes in "please wait mode" (with the blue progress circle instead of the usual mouse pointer) forever. If I check the processes open at that point, I see three Setup.exe that I cannot kill with the kill process button or via Taskkill command. And all I can do at that point to kill them is pretty much rebooting.
As to the Setup.msi, it seems to do nothing I can see (tells me something like "checking requirements", and once it has, it just closes with no visible effect).
Any idea about what's going on or how I could find out?
Apparently years later this keeps hitting people so I'm posting the answer I had first put in the comments:
Deactivating my antivirus solved the issue >< I wish Avast had told me "hey I'm blocking this" and saved me a few hours
I have tried two installers - Setup2go, and Installmate Builder, and I have the same problem. At the last window of the install, I select the option to "Open program after installation finish", and sometimes (about 10% of the time?), my (Winforms) app's main window will open behind the Windows Explorer directory window I used to open the installation exe from.
The frustrating thing is - I am having trouble reproducing the problem reliably (the problem seems to occur around 10-20% of the time). I am using Windows 7 if that makes any difference. To clarify, if I open up the executable directly (rather than from the installation exe), the problem never occurs.
My knowledge on this kind of thing is limited - I recall a similar frustration happening with the MessageBox from this question
Any ideas?
It does not happen when you launch the app directly from installer because the shell allows it to “steal” the focus. When you launch it from the installer, the last interaction happens in the installer app. The system prevents the new window from stealing the focus from your installer. If installer window closes, then the explorer window which you used to start the installer is activated. Since the switch of the foreground window happened recently, the system does not allow to change the foreground window.
On the other hand, if your application window is shown before the installer window disappears from the screen, the the app will be placed below the installer in the Z-order; and when the installer window is finally hidden, the application window is activated.
So it's all related to timing between showing and hiding windows.
Although I am not expert in this area. You can use message tracers and WinAPI calls tracers like Spyxx which can give you more details on what happens in the system and why the new window of your application is placed below the Explorer window.
Make sure the window's title isn't changed, until the last possible moment. I moved the Text = "blahblah" line out of the Form_load event, and into the Form1_Shown event, and now the hidden taskbar icon problem has vanished. Also, the window doesn't flicker when it's loading.
I am trying to attach to a windows service using Visual Studio 2010 → Debug → Attach to process command. When I scroll through the list of processes my Windows service is greyed out and the attach button is also greyed out.
I have tried changing the service account to local service, my account, etc., but it remains greyed out. Is there a way to troubleshoot this?
I usually have the same issue and I take care of it by adding a boolean to my configuration that triggers a debug launch. You can launch a Visual Studio debugger instance that attaches to your Windows service process by calling this:
System.Diagnostics.Debugger.Launch();
What's nice is that you can call it wherever you wish in your code.
In Visual Studio 2010, on the 'Attach to Process' dialog, check the two check boxes at the bottom that say 'Show processes from all users' and 'Show processes in all sessions'.
On doing that I found that I had my process show up twice, one running as System and one running under my local Windows login. I am not sure why (any input on this would be great!), but I was able to attach to the not-grayed-out one that showed up and was also able to step through my code this way.
The second one was the servicename.vshost.exe process as Ozz pointed out in the comments.
If you still do not see it, make sure your service is still running. Sometimes you might have a failing service that started and automatically stopped and therefore doesn't show up in the attach to options.
Not only did I have to select show processes from all users and the show processes in all sessions check boxes; I also had to click the Select button and then choose the Managed code.
Make sure you run Visual Studio as an administrator. It will require administrator rights to attach to a running service.
After installing the Windows service, start it. Then in Visual Studio open the Attach to process window (Alt + Ctrl + P), find your process and select it and click Attach Button in the bottom of the window.
You may not have permissions to attach to the service. Do you have admin privileges on the desktop? Many corporations do not allow this by default, supposedly to assist in securing their environment.
I solved my problem by changing the way the setup was generated, from RELEASE to DEBUG. And then, I installed the service and attached as usual.
I ran into the same issue today with none of the previous solutions working. As it turns out, it is not possible to attach to a process if you have a ProcDump session monitoring that process.
Use menu Tools → Attach to Process. Simply check Show Processes from all users at the bottom left. Sort by Process and try looking for your Windows service.