Not the foreground application
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Not the foreground application
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
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
Re: Not the foreground application
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 -
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 -
-
- VIP Livecode Opensource Backer
- Posts: 9663
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Not the foreground application
Hi,
I used to use idle.
Don't.
Make a button and a field on a new card. In the button script:
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
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
Craig Newman
Re: Not the foreground application
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
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
Re: Not the foreground application
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 -
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.
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
Re: Not the foreground application
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".
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
-
- VIP Livecode Opensource Backer
- Posts: 9663
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Not the foreground application
Bogs wrote:
This was not meant to be a finished app. One might have said instead:
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
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.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.
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
"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
Re: Not the foreground application
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
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
-
- VIP Livecode Opensource Backer
- Posts: 9837
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Not the foreground application
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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Not the foreground application
Very nicely put, even I understood it!
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Not the foreground application
That's as good as your "get a mop" analogy.FourthWorld wrote: ↑Sat Feb 10, 2018 4:52 pmImagine a courier continually driving around the block in the hopes that once in a while he will be asked to carry a letter.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Re: Not the foreground application
Oh ? Do tell, do tell!jacque wrote: ↑Sun Feb 11, 2018 9:59 pmThat's as good as your "get a mop" analogy.FourthWorld wrote: ↑Sat Feb 10, 2018 4:52 pmImagine a courier continually driving around the block in the hopes that once in a while he will be asked to carry a letter.
Re: Not the foreground application
I like the turtle trap story to explain the message path