"Minimize to Tray" command bug when screen is turned off

[reaper]

Hi,

if the "Minimize to Tray" command is used to minimize a window to the Windows System Tray bar the icon gets orphaned when the screen is turned off. When the icon is clicked the window isn't restored.
If the window is restored by the "Restore" command and minimized again by the "Minimize to Tray" command a second icon is created at the System Tray bar.
The orphaned icon remains at the System Tray bar, even if the application is closed, see attached screenshot.
If EventGhost is restarted, the orphaned icon remains at the System Tray bar until the cursor hovers over them, then it disappears.

This doesn't happen while the screen keeps turned on.

A solution would be highly appreciated!

[kgschlosser]

if the "Minimize to Tray" command is used to minimize a window to the Windows System Tray

what command are you referring to?

bar the icon gets orphaned when the screen is turned off. When the icon is clicked the window isn't restored.

Which icon? The EG icon?

If the window is restored by the "Restore" command

what restore command?

second icon is created at the System Tray bar.

Your screen capture shows only a single EG icon.

The orphaned icon remains at the System Tray bar, even if the application is closed, see attached screenshot.

again I only see a single EG icon and EG is running in your screen shot as well, so nothing out of place there.

This doesn't happen while the screen keeps turned on.

So you are changing the layout of the GUI when you cannot see it????

[reaper]

Thanks for your reply!

Please look at the example EventGhost file shown in the screenshot and attached.
I'm referring to the "Minimize to Tray" command of EventGhost.
In the example I minimized Microsoft Notepad with this EventGhost command to the Windows System Tray. But this issue is also reproducible with other applications.
Then I powered off the monitor. When I power it on again the Notepad System Tray icon gets orphaned. As you can see on the screenshot, Notepad is already closed but the orphaned System Tray icon is still there, until I hover the cursor over it.

[Sem;colon]

Hi reaper,

What you describe is a bug in Windows, nothing EG can fix unfortunately.
You find the same behavior with other apps in system tray, no matter of Eventghost sent them there or not.

[kgschlosser]

That would be a bug in Windows and nothing to do with EventGhost. I can check and see if there is a way I can force a refresh of your desktop/start bar but there is still a chance it will not work.

[reaper]

Thanks for your replies, appreciated!

I doubt that this is a bug of Windows, for the following reasons:
1. There are several other application icons in the SysTray bar and all "survive" the screen power off/on.
2. If I minimize the affected application to the SysTray bar using the minimize to SysTray function of the application itself, the issue doesn't happen as well.

[kgschlosser]

OK so here is the skinny on how this works. Right now EG grabs the icon from the application and uses that icon to create a tray icon and then it hides the application. there is a single thing this icon does. when clicked on it shows the original application. There in lies the problem. if the application gets manipulated in any programmatically before clicking on that icon in the system tray then the icon is not going to function properly. so when you use the restore and the close actions this bypasses how the icon works. currently the icon has no way of knowing that the application has been manipulated. I can register for windows messages for the application but if the application gets closed or exists while it is hidden there may not be a message that the windows has been destroyed. this is because windows also uses the same destroyed message when hiding a window. kind of stupid actually. a hidden window is not a destroyed window. but that's Microsoft for ya.

I am not able to access the icon using Find Window in order to simulate the thing getting clicked. I tried this. So I am going to have to write an extremely complex routine to handle programmatically altering an application and whether or not the icon should disappear or not.

I am going to do some digging and see if there is a way to access the tray icons. I really do not want to do a system hook to grab the windows notifications. It is recommended to not do this if possible.

[reaper]

Thanks for your support, kgschlosser!
I fully volunteer to any tests and you can use my EventGhost file to reproduce this issue. Currently my SysTray bar is littered by many orphaned icons so I'd really appreciate a solution.

Interestingly this issue only occurs on window state changes while the monitor is powered off.

[kgschlosser]

So I was reading through the code for EventGhost specifically the section of code that handles programmatic changes to a windows visual state. There are concessions that have been made to handle destroying the icon when the applications visual state changes through the use of an action in EventGhost. Not all of the actions have had the handling added to them and this I am going to correct. This handling does function properly whether the monitor is in a powered on or powered off state. So now we went round robin with this thing. It is actually a bug in Windows. Even tho windows has been told that the tray icon has been deleted Windows decided that it is not going to update the GUI because there is no GUI being displayed to the user (the display has been turned off). I am not sure if there is a way to programmatically give Windows a kick in the ass so it will redraw the GUI. The end result is if I change the code so it will use an applications notification of it closing to remove the icon from the system tray the end result is still going to be the same. In the end I am still removing the icon when the display is powered off and windows is still not going to update the GUI.

Let me do some more digging and see if there is a way I can get it to force a GUI update.

[reaper]

Very interesting!
Sounds like you're getting closer to a solution! At least you've found the problem cause.

[reaper]

Any new findings, kgschlosser?
I'm really looking forward to it.

[reaper]

Hi kgschlosser,

how are you?
Are there any news?