Using " <time>" wirh private commands?

Richard Gaskin ambassador at
Sat Nov 7 13:58:50 EST 2015

Mark Wieder wrote:
> On 11/07/2015 09:13 AM, Richard Gaskin wrote:
>> This works:
>> command SomeTimer
>>    DoSomething
>>    send "SomeTimer" to me in 500 millisecs
>> end SomeTimer
>> This doesn't work:
>> private command SomeTimer
>>    DoSomething
>>    send "SomeTimer" to me in 500 millisecs
>> end SomeTimer
>> I can kinda understand why, but I'd like to be able to manage a timer
>> from within a library without exposing the timer to other scripts.
>> Anyone know of a trick for that?
> Nope. That has never worked.
> I've resigned myself to making the targets of send and dispatch commands
> public. The only way I can think of to get around this is to make a
> public method that then calls the private one. Same thing with callback
> handlers.

Inelegant, but this seems to at least block outside callers:

on SomeTimer
    put item 1 of line -2 of the executionContexts into tCaller
    if (tCaller is not empty) AND (tCaller <> the long id of me) then
       exit SomeTimer
    end if
    send "SomeTimer" to me in 500 millisecs
end SomeTimer

PS - a pleasant timing surprise:

One of the things I was testing this morning was the CPU impact of 
frequently polling for the existence of a file.  I have two processes 
which (for reasons not worth getting into here) can't talk via sockets, 
so I wondered how inefficient it might be to have them communicate via 
files.  Turns out checking for the existence of a specified file isn't 
bad at all.

Testing a worst-case I polled every millisecond and it never chewed up 
more than 4% of CPU time.  Throttling back to a more reasonable 500 ms 
never registered higher than 0%.

Not sure how well that would work on Windows, but OS X and Linux file 
system caching seems to make even brute force solutions like polling 
pretty nice.

  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  Ambassador at      

More information about the use-livecode mailing list