Xojo Timers & GUI

I have a couple of timers in my Xojo program that send out a “heartbeat” message via a TCPSocket every second, to let the app they’re connected to know that the Xojo app is still “alive”.

Works fine when the Xojo app is on the screen. If I minimize the app or the screensaver comes on, after about 1 minute, the timers stop. They restart again after about 10-20 seconds, but that’s enough time for the connected app to feel that they’re disconneted.

Is it normal for a timer to pause (or maybe the app is sleeping) after it’s not in the foreground for a minute or so?
Other than forcing my app to never minimize, is there a way to keep a timer from “sleeping”?

Oh, this is when running on MacOS. I haven’t tested to see if this issue happens on Windows, but I will.

Doesn’t happen on Windows.

Doing a little digging, it sounds like it’s a MacOS thing called “AppNap”?
Any idea how to disable this? Does it only affect GUI apps?

AppNap definitely would do it as thats a power conservation thing
I know there are posts that have code to disable it - let me find one

Looks like going into terminal and typing
defaults write com.checkcheckonetwo.YammieRemote NSAppSleepDisabled -bool YES
does the trick.
Would I be able to shell that command?

I feel like this would be one of those things that might keep my app from being able to be notarized…

Yeah DONT do that :stuck_out_tongue:
It will prevent an app from being notarized
give me more than 30 seconds to find a good one ?

EDIT Have you got MBS plugins ?

1 Like

well damn all the “good ones” are no longer available (as they were in samples not posted directly as code in the forums)

there is sample code for using MBS in the Forums - search for NSProcessInfoMBS
like this one https://forum.xojo.com/conversation/post/158995

I’ll dig out some declares from code I have

1 Like

its a tad more than just a few declares

I do have MBS.
Do you know if separate threads are affected by AppNap? I was thinking about moving the heartbeat to a separate thread or maybe a shelled console app…

Found this:

Not sure how to translate that to declares in Xojo though…

I sent you a link to project with a sample privately

1 Like

Xojo threads arent, as far as I know, since they are cooparative

Appnap is basically “dont shut my apps power off or slow me down while I’m doing this task”

So please use NSProcessInfoMBS to declare the activity and end it when it’s done.
This allows the system to safe battery.

Norman I would like that too ! thanks.

here

http://great-white-software.com/miscellaneous/AppNap.zip

1 Like

Not 100% on Variable scoping and Class destructors… If I add a property for the MainWindow of
AppNapToken As AppNap.AppNapToken
and in MainWindow.Open Event:
AppNapToken = New AppNap.AppNapToken("Keep Alive")

Then in MainWindow.Close Event:
AppNapToken = Nil

Does setting the variable to Nil call the Destructor, or is there another way classes are destroyed in Xojo?

Scope and destructors arent inherently tied together

SCOPE
This refers to the places where an item (method property etc) can be referenced
ie/ using just local variables we can see the effects

      for i as integer = 1 to 10
           // using i is LEGAL here as i was defined in a way it is IN scope

          dim j as string

           // using j is LEGAL here as j was defined in a way it is IN scope

     next i

    // using i is NOT legal here as i was defined in a way it is only available in the loop
    // using j is NOT legal here as j was defined in a way it is NOT in scope (it literally doesnt exist)

When it is things like properties & methods they have a different way of denoting what can and cannot access them

a PUBLIC property on an instance of a class can be manipulated by any code that has a reference to the instance
a PROTECTED property can only be altered by code IN the instance, or a subclass
a PRIVATE property can only be altered by code IN this class (not subclasses)

A property on a window will be “in scope” for any code on that Window

DESTRUCTORS
A destructor for an object will be run AS SOON AS the reference count to an instance is set to 0
So if your code setting AppNapToken = NIL IS the last reference (ie/ its not held in any other statics or other properties on the window) then setting the reference to NIL SHOULD make the destructor run right away

1 Like

Works like a hot damn. Thank you, Norm!!