Jump to content

c0d3r

Members
  • Content Count

    137
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by c0d3r


  1. 20 minutes ago, Remy Lebeau said:

    For all we know, your windows got recreated and that is why messages are being lost.  Who knows.  Did you try verifying that the TTimer's HWND and the TMemo's HWND are still the same before the Standby and after the Wakeup?

    We don't see why windows got recreated and how to check HWND values before standby and after the wakeup, because we never know when its entering modern standby mode and when its waken up.


  2. 1 hour ago, Remy Lebeau said:

    Have you tried using the TApplication[Events].OnMessage event, and TApplication.HookMainWindow() and overriding the TForm.WndProc() method, to actually check that window messages are really no longer being processed?

    Yes. we did:  WM_KEYFIRST..WM_KEYLAST, WM_MOUSEFIRST..WM_MOUSELAST,  seems working.


  3. 39 minutes ago, Remy Lebeau said:

    In any case, an application can detect support for Modern Standby by checking the AoAc field returned by GetPwrCapabilities().  And register for notification of Modern Standby/Resume using RegisterSuspendResumeNotification().

    HI, Remy

     

    As stated in my post #1,  we are using  PowerRegisterSuspendResumeNotification, call back routine, but we get ZERO notification when entry/exit from Modern Standby/Resume (regular Windows sleeping/wake up is working fine).  Any difference between  PowerRegisterSuspendResumeNotification  and your RegisterSuspendResumeNotification.  

     

    As the sample code we use to test,  very simple,  a TTimer and a Memo field on a vcl form, and OnTimer event (every 1 second):

     

    procedure TForm1.Timer1Timer(Sender: TObject);
    begin
      Memo1.Lines.Add(TimeToStr(Now));
    end;

     

     

    NO output in the memo field after exit from Modern StandBy mode.


  4. On 2/16/2025 at 1:33 PM, Anders Melander said:

    So instead of assuming that WM_TIMER doesn't work I recommend that you simply verify with a simple application that does nothing but write a time stamp to a TMemo every time a 1 second TTimer fires.

    If that doesn't work then there's a problem with TTimer and we can start examining what that is.

    Got the report back:  TTimer was suspended and never resumed after exit from Modern standby mode (S0).  It looks to me that all activities in the applications threads and windows message handlers were suspended, never being resumed.


  5. 40 minutes ago, Anders Melander said:

    So instead of assuming that WM_TIMER doesn't work I recommend that you simply verify with a simple application that does nothing but write a time stamp to a TMemo every time a 1 second TTimer fires.

    If that doesn't work then there's a problem with TTimer and we can start examining what that is.

    Good idea.  will do it and report back. 


  6. 13 hours ago, dwrbudr said:

    Try using RegisterPowerSettingNotification in combination with GUID_MONITOR_POWER_ON power setting GUID

    Is this the new requirement for this?   The regular Windows sleeping/wake up don't need this GUID, which was working just fine.


  7. 13 hours ago, Anders Melander said:

    I think the timer is still alive. It just takes a (unusually long) while to fire after resume from standby.

     

    See also: https://github.com/cyd01/KiTTY/issues/475

    I thought so,  BUT  there is no new PING records in the server database after exit from the standby, so I think the timer is dead completely (I was at least waiting for 5+ minutes to check).


  8. Hi, All

     

    Our client application used a timer (TTimer) to send a ping to our application server every 60 seconds. It seems that the timer being killed by Windows when entering the Modern Standby mode, and never being re-activated when exit.  The big problem is that Windows seems never send notification to all the applications when entering/exit from the modern standby mode.  any way we could restart the timer?  

     

    BTW,  We did register power notification call back, like this:

     

    var

       LParameters: DEVICE_NOTIFY_SUBSCRIBE_PARAMETERS;

     

    LParameters.ACallback := @DeviceNotifyCallbackRoutine;
    LParameters.AContext := nil;

    PowerRegisterSuspendResumeNotification(DEVICE_NOTIFY_CALLBACK, @LParameters, @FPowerNotify);

     

    However, we never got any notifications from Windows,  no entry/no exit notifications at all.

     

    Any help would be appreciated.  Thanks.

     

    Regards,

    William


  9. 23 hours ago, Remy Lebeau said:

    On Vista+, you can use RegisterPowerSettingNotification() to register to receive WM_POWERBROADCAST notifications for certain power events.

     

    On Windows 8+, you can use PowerRegisterSuspendResumeNotification() to receive power notifications via a callback function instead of WM_POWERBROADCAST.

     

    IIRC, however, modern Windows also has a newer fast standby/hibernation mode that doesn't sent power notifications to applications, it just pauses and resumes them as if nothing had happened.  I can't find the details about that, but I remember being involved in past discussions about it, I just don't remember where.

    Something must be changed, was told it was working just fine on the same computer, and then stop working.  They are using Windows 10.


  10. HI,  All

     

    I'm getting a strange issue, the following codes were trying logout users when Windows is going to sleep mode. For some reason,  it works for some laptops, but it doesn't work for others:

     

    procedure WMPowerBroadCast(var Msg: TMessage); message WM_POWERBROADCAST;

     

    procedure TMainForm.WMPowerBroadCast(var Msg: TMessage);
    begin
      if (Msg.wParam = PBT_APMSUSPEND) or (Msg.wParam = PBT_APMSTANDBY) then
      begin
        try
          Signout;
        except
        end;
        Msg.Result := 1;
      end;
    end;

     

    Got the report from my client,  the signout routine didn't get called when some laptops went to sleep (leave them opened and auto entered Sleep mode or Hitting Power button to force sleeping),  but other laptops/PCs were working just fine.

     


  11. @Remy LebeauAlthough we still can't figure it out after weeks (we don't deal with any TCP/IP socket codes), we found a workaround: kbmMW's Server component has a property called 'DisconnectAfterResponse'.  By setting it to True, Most of our clinic customers don't have any TCP/IP socket close freezing issues, however few were still having the problem, they were the large and busiest clinics.  We are planning to use Indy Github version to see if it helps, I'm just wondering whats difference between GitHub version and the one comes with Sydeny?


  12. 9 hours ago, Trevor S said:

    The 64bit  path issue is listed in the "Known Issues" section of  the installation notes.  

    http://docwiki.embarcadero.com/RADStudio/Sydney/en/Installation_Notes#Known_Installation_Issues

     

    Sorry, too late for you now...

     

    It said the problem would occurs when using offline installer,  but I was using web installer,  still my 64bit LIBRARY (Windows) paths were wiped out.

×