6.6.5 and Message timing?

Andrew Kluthe andrew at ctech.me
Tue Mar 10 13:37:37 EDT 2015


Hey ya'll,

I've been trying to track down some weird behavior in a standalone built
and running on windows 7 x86.

I have a launcher which prepares and starts another non-livecode
application up.

Once sending the start commands for this application via shell() it starts
a handler to watch for when it is open and ready.

I am currently using something similar to this:

on waitForNW

wait until checkForNW() is true with messages
send "hideSplash" to me
send "watchForClose" to me in 1 second

end waitForNW

checkForNW() runs shell("tasklist") and checks the result for the presence
of the process and returns true or false

If it is running, it hides the splash and switches to the inverse function.
It is now checking to see if the process still exists. If it does not, I do
some cleanup and quit.

The inverse wait mechanism is much the same:

on watchForClose

wait until checkForNW() is false with messages
quit

end watchForClose

 Everything works exactly as I'd expect it to in the IDE. Once I build a
standalone with 6.6.5, it seems like there is a huge delay in the
watchForClose message. I've piddled with timings and using repeats with
recursive Send in time's to recall itself with a pendingMessage in place of
my wait with messages. No amount of timing or fudging makes the stand alone
behave differently outside of expected the forced slow down in my timings.

I saved this stack out in legacy format and opened it up in 5.5.5. Works
fine in the IDE.

I built the standalone in 5.5.5 now, and it works exactly as expected in
the standalone now too.

I haven't tried it in any of the 7.0 releases or any others than 5.5.5 and
6.5. Id prefer not to use the newer ones, as double digit megabyte size for
a simple splash launcher like this is a bit silly. I'd just soon as ship
5.5 in that case.


The Real Question I Have:

Were there any known issues with message timing or shell() command on
windows in 6.6.5 that would account for this?

-- 
Regards,

Andrew Kluthe
andrew at ctech.me



More information about the use-livecode mailing list