Home page Home page Home page Home page
Pixel
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
Pixel
By Sprezz | Saturday 21 March 2020 15:14 | 0 Comments
Imagine the scenario - your client is a frugal sort and wants to have your system available to 25 of their office users but knows that it is highly unlikely that all 25 users will want to access the system at the same time - so they pay you for a 20 seat license.

All is well - until their users start to leave the app running on their laptop - and their laptop is configured to sleep after a pre-set period to conserve battery life. Their laptop sleeps and takes with it an OI license. This happens on 5 machines - so now they have 20 users active in the office - but only 15 available licenses. And somehow this is YOUR fault. (Isn't it always - it's probably a bug :D).

Is there anything to be done?

Don't you just love those sort of rhetorical questions? If there wasn't then this blog post would be a little pointless.

Those of you who've read our last blog post on the genesis of OpenInsight will realise that Windows is always trying to tell OpenInsight stuff that frankly, OpenInsight doesn't really care about. And most of the time, the stuff that it ignores, isn't of practical benefit to neither the user nor the developer. But in the situation we're describing there's a Windows message that we DO care about - the WM_POWERBROADCAST message. This is the Windows message that notifies the application that a power management event has occurred, and luckily for us - sleeping or suspending is just such an event. So if we can somehow listen out for that event we can take whatever action we want when it occurs. Well, as long as that action takes less than 2 seconds - the length of time that Windows waits after sending the message and actually doing the suspension.

Using OI 10 to illustrate this we only have add two small snippets of code. The first tells OpenInsight that actually, yes, we are interested in knowing about the WM_POWERBROADCAST message. The second looks at the contents of the message, determines that this particular message is a suspension/sleep message and if it is, kills OpenInsight.

Listen Up!

To tell OpenInsight that we want to be told about the WM_POWERBROADCAST message we add the following lines to our main application window's create event.

   message   = 0x218
   newQual  = 1
   prevQual = Exec_Method( @window, "QUALIFYWINMSG", message,  newQual)

218 HEX (536 DEC) is the code for WM_POWERBROADCAST and the newQual parameter is defined as follows in the documentation "OpenInsight 10 Presentation Server Reference Manual.pdf" in the documents folder. We're effectively saying "If Windows tells you about this, please let me know by raising the WINMSG event on the current Window".

ZZ(Zzzzzzzzzzzzzz)

To act upon the notification we simply have to add this code to the WINMSG event (or any other event if you prefer (See the above documentation))

   If wParam = 4 Then
      call exec_Method("SYSTEM", "DESTROY", "SYSTEM")
   end

Where 4 is the code for PBT_APMSUSPEND - the system is suspending operation. Naturally, we don't HAVE to close down OpenInsight - we can take whatever actions we want in the remaining 2 seconds before Windows actually suspends operation.

Of course, when your user repowers up their workstation, OpenInsight will no longer be there - a surprise to them given that the point of a SLEEP is to return to where you left off - but if that's what you as the developer opt to do, that's your prerogative - and your parsimonious bill payer will remain happy!

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]



<< Home

Pixel
Pixel Footer R1 C1 Pixel
Pixel
Pixel
Pixel