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
   --
   DoSomething
   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
 ____________________________________________________________________
 ambassa...@fourthworld.com                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to