Not the foreground application

[Maxiogee]

Hi,

I want to have Livecode display, and update as necessary, the day, date and time on my Mac.

I have it working fine with an "On Idle" script. but only when LiveCode is the foremost, active, application.
How can I oblige LiveCode to carry on working when in the background.

Thanks,

Tony

[bogs]

Not trying to sound too dense, but are we talking about an individual application you made in Lc? A stack you have running in the IDE? Something else entirely?

If it is an application you already compiled, it should update whether in the background or not, here is a simple timer I wrote running in the background on Linux, for example -

[dunbarx]

Hi,

I used to use idle.

Don't.

Make a button and a field on a new card. In the button script:

Code: Select all

on mouseUp
   incrementTime
end mouseUp

on incrementTime
   add 1 to fld 1
   send "incrementTime" to me in 60
end incrementTime

This will count up happily forever, regardless of whether the card is in front, some other stack is in front, or some other application is in front. In fact, the only way to stop it is to destroy your computer.

Craig Newman

[Maxiogee]

Thanks.

What's wrong with using idle?

Incidentally. your incrementer incremented in leaps and bounds. One time it was increasing by fours, and another - when I restarted it, by nines.

Thanks
Tony

[bogs]

I think it showed up that way because you didn't put any kill step in, so each time you 'start' it, it is running the incrementer loop multiple times.

Try something like this -
One button on the card, one field named txtTimeElapsed, code in the button -

Code: Select all

local boolT, theHours, theMins, theSecs

on mouseDown
    if the label of me is "Start" then
        set the label of me to "Stop"
// set all the counters to 00...
        put "true" into boolT
        put 00 into theHours
        put 00 into theMins
        put 00 into theSecs
// call the updater...
        updateTimer
    else
        set the label of me to "Start"
// updater will exit on false...
        put "false" into boolT
    end if
end mouseDown

on updateTimer
    if boolT = "true" then
// this is only necessary if you want the added seconds to update across the field...
        if the length of theSecs < 2  then put 0 before theSecs
        if the length of  theMins < 2 then put 0 before theMins 
        if the length of  theHours < 2 then put 0 before theHours
// this puts the formatted time in the field...        
        put theHours & ":" & theMins & ":" & theSecs into field "txtTimeElapsed"
// this adds the seconds each second...
        add 1 to theSecs
// this updates the minutes and resets the seconds...
        if theSecs = 60 then 
            add 1 to theMins
            put "00" into theSecs
        end if
// this updates the hours and resets the minutes...        
        if theMins = 60 then 
            add 1 to theHours
            put "00" into theMins
        end if
    else 
// you've hit the button again, exit the updater...
        exit updateTimer
    end if
// keep sending the message as long as booT is true...
    send updateTimer to me in 1 second
end updateTimer

I wrote this a long time ago when I was just starting, it isn't the best way to do it, but it is functional.

[bogs]

If your looking for a better way to display and update the time, date, etc, this would be easier (just tested it).

Same button and a field named "txtTime".

Code: Select all

local boolState

on mouseDown
   if the label of me is "Start" then 
      set the label of me to "Stop"
      put "t" into boolState
   else if the label of me is "Stop" then
      set the label of me to "Start"
      put "f" into boolState
   end if
   updateTimer
end mouseDown

on updateTimer
   if boolState is "f" then
      exit to top
   else
      put the long time into field "txtTime"
      send updateTimer to me in 1 seconds
   end if
end updateTimer

[dunbarx]

Bogs wrote:

I think it showed up that way because you didn't put any kill step in, so each time you 'start' it, it is running the incrementer loop multiple times.

Oh yes. If you reClick several times, you create weirdness. You would have to set a flag or custom property to make sure only one click was processed.

This was not meant to be a finished app. One might have said instead:

Code: Select all

on mouseUp
   incrementTime
end mouseUp

on incrementTime
put the seconds into fld 1
   send "incrementTime" to me in 60
end incrementTime

You need to understand pendingMessages and how to manage them.

"Idle" is just considered passé, and can eat up processing time, since those messages occur often and are handled each time. The "send in time" is far more powerful and flexible.

Craig

[Maxiogee]

Thank you all.
I have learned all I need to know.
And, as often on boards such as these, I have been introduced to ideas which are above my current need to know.
However, in a small corner of my brain, I will file some of the ideas, and will - when the need arises - come back here and find these notes.

If I remember to.

Thanks
Tony

[bogs]

If I remember to.

My single biggest problem as well

[FourthWorld]

What's wrong with using idle?

Imagine a courier continually driving around the block in the hopes that once in a while he will be asked to carry a letter. That's a lot of resources devoted to something that many not be needed most of the time.

Then imagine that there's only one courier. No matter how many letters need to be sent, they all go into one vehicle, and are all delivered on the same schedule. If one letter is more urgent, too bad: there's no way to make sure it gets delivered first.

HyperTalk's idle message was like that, an invitingly simple mechanism but the very simplicity that made it easy to use also made it a resource hog and somewhat inflexible.

LiveCode also supports idle, but with many limitations to minimize its impact on other processes (see the caveats in the Dictionary entry for the idle message).

Instead, LC offers a more modern approach, one we see in most other languages: timers, the ability to send a message after a specified duration has elapsed.

This is like have multiple couriers, each devoted to carrying only a single message, and each driving at whatever speed is needed for the message they're being asked to deliver.

If a message needs to be sent repeatedly, as Craig and Bogs have shown you have have the recipient of the message initiate another send.

This leaves the scripter in control of message queuing and scheduling, and ensures that at any given time the only messages queued are those that are asked for, as opposed to the idle message which in HyperCard is limited to that one message and is always running, even if unused, like an empty car continually driving around the block.

[bogs]

Very nicely put, even I understood it!

[jacque]

What's wrong with using idle?

Imagine a courier continually driving around the block in the hopes that once in a while he will be asked to carry a letter.

That's as good as your "get a mop" analogy.

[bogs]

What's wrong with using idle?

Imagine a courier continually driving around the block in the hopes that once in a while he will be asked to carry a letter.

That's as good as your "get a mop" analogy.

Oh ? Do tell, do tell!

[SparkOut]

I like the turtle trap story to explain the message path