Plex 2E

 View Only

 Application buttons disappear when waking from sleep in Windows 11.

MARUBUN SUPPORT's profile image
MARUBUN SUPPORT posted Feb 17, 2023 01:29 AM

Hi Team,

We have a problem when we run an application created from Plex in Windows 11.

If we put the PC to sleep with the application open and then wake it up from sleep, the buttons that were displayed in the application's GUI disappear.

If the application is moved off screen and returned to its original position, the buttons may or may not display correctly.

We have also tried with Build 24.005 and the same bug occurs.

This problem does not occur in Windows 10.

Please let us know how to fix this problem.

Thanks,

HIFUMI ONISHI's profile image
HIFUMI ONISHI

Hello,

I have uploaded a test local model for this issue.

REPRODUCTION STEPS: 
1. Generate/Build 'WinC.ButtonsDisappear' function.
2. Run 'WinC.ButtonsDisappear' on Windows 11.
3. Put your computer on sleep mode.
4. Wake your computer.
   *In our environment many buttons disappeared from the screen. (see AfterComputerWakes.png)

Regards,
Hifumi

Jeremy Stent's profile image
Jeremy Stent

Out of curiosity, which controls are you using?  Have you tried setting "PushButton=" in your INI (1 for MFC, 0 for WinWidgets)? 

I notice that the test model does not any tab sequences.  I know that with the MFC controls the z-order is reversed from the older WinWidgets (https://ftpdocs.broadcom.com/cadocs/0/CA%20Plex%206%201-ENU/Bookshelf_Files/PDF/Plex_Release_Notes_ENU.pdf).  Have you tried setting "Clip Control", or specifying a tab sequence (which sets the z-order) such that the buttons have a lower tab sequence than anything under them?  (Your test panel should not have this issue, but I wonder if a tab sequence would help.)  I seem to remember there may be an INI setting to adjust how tab sequence and z-order interact, but I cannot find it at this time.

HIFUMI ONISHI's profile image
HIFUMI ONISHI

Hi Jeremy,

Thank you for your comment.

We use the Winwidgets (0) setting for GUI controls.

With the Winwidgets (0) setting, the following controls other than PushButton have the same problem.
(Setting the tab sequences did not solve the problem.)

ListBox
SingleLineEdit
SingleLineEditNumeric
MultiLineEdit
ComboBox
RadioButton
CheckBox
Statics

For the MFC controls (1) setting, the PushButton does not have the problem, but the following controls have the same problem.

ListBox
MultiLineEdit

Even with the Winwidgets (0) setting, there is no problem with any of the controls on Windows 10.

We have opened a case ticket with Broadcom but still no progress.
Let me know if you come up with another idea.

Regards,
Hifumi

Jeremy Stent's profile image
Jeremy Stent

I can suggest a workaround, although it would require a rebuild of all panels rather than a proper runtime fix from CA.

We are not running windows 11 yet, however, if you have a clean pattern (most or all of your panels inherit from one function), and if you are willing to use some source code, you could register to receive windows events, and monitor for the WM_POWERBROADCAST windows event (https://learn.microsoft.com/en-us/windows/win32/power/wm-powerbroadcast).  If the message details include  PBT_APMRESUMEAUTOMATIC, then you could trigger a panel repaint.  (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-redrawwindow).

To do this sort of thing, I create an event (PanelEvent) on the panel.  I then use source code WINAPI/TrapPanelEvent in the initialization of the pattern function.  I would pass the WinMessageID as the value "PBT_APMRESUMEAUTOATIC", and the Event as "PanelEvent".  Then in the Events I add the "PanelEvent".  I normally have this "Go Sub Handle PanelEvent".  I create a subroutine "Handle PanelEvent" in which I check if we are C++, and then use the WINAPI/GetCurrentMessage api.  If the WinMessageID = WM_PowerBroadcast, and the WPARAM value is "PBT_APRESUMEAUTOMATIC" then you could run some source code to trigger RedrawWindow passing in the HWND of the panel.  (Search for HWND in plex help, and use ObPanelAPI::GetPanleHandleByName(*Current) to get the hwnd).

Note that this will only work if the event source code executes BEFORE any inherited Get or Put statements.  I have had issues with a panel that had "Get" in the "Any Event" edit point.  I had to remove the code from the Any Event edit point.

According to https://learn.microsoft.com/en-us/answers/questions/48395/cannot-receive-wm-powerbroadcast-message-on-win10 we may need to specifically register to receive suspend resume notifications (https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registersuspendresumenotification).  If this is necessary I would try to have it notify the window handle.  No experience using this, just a thought it might work.