Hi Dunbar,
I do not have LiveCode installed in this computer, so i could not
test the following idea:
Why not make both, the process and the script, to depend
from an external source, for running and, then they call
each other?
For example, both runs only if certain fixed time has passed
or
Al.
But this is the way it runs now, and perfectly well, though only in one
direction as you laid it out. The background process is live all the time. The
stack does its thing.
I was only concerned if there was a way, however odd, to interrogate a
running script from the outside. This
Al.
But this is the way it runs now, and perfectly well, though only in one
direction as you laid it out. The background process is live all the time. The
stack does its thing.
I was only concerned if there was a way, however odd, to interrogate a
running script from the outside. This
On 9/24/10 8:36 AM, dunb...@aol.com wrote:
Is there a way to interrupt, or rather, interrogate, the repeat loop? I
am not talking about checking the property within that running code.
I think what you want is:
wait 1 millisecond with messages
Put that into the repeat loop somewhere. It
On Fri, Sep 24, 2010 at 4:57 PM, dunb...@aol.com wrote:
Al.
But this is the way it runs now, and perfectly well, though only in one
direction as you laid it out. The background process is live all the time. The
stack does its thing.
I was only concerned if there was a way, however odd, to
Remind me, can you actually check a property of an object while a handler
that sets the property is running? It works fine when setting a variable,
but I can't make it work when repeatedly changing a property in a repeat
loop. (I suspect it would work if it was a send in time that set the
Nevermind, it works fine. Have no clue why I couldn't make it work the first
5 times I tried it.
On Fri, Sep 24, 2010 at 10:15 AM, Mike Bonner bonnm...@gmail.com wrote:
Remind me, can you actually check a property of an object while a handler
that sets the property is running? It works fine
Hi Jacque,
J. Landman Gay wrote:
I think what you want is:
wait 1 millisecond with messages
Put that into the repeat loop somewhere. It forces the engine to do all
the same cleanup and checking as it does on idle, and will catch any
pending messages that have happened.
About
Jacques, et al.
The wait with messages, which I know about, is compact and cool. But that
code needs to reside within the running handler. As do, in their own way,
all the other comments from everyone. For example, BonnMike notes you can
read the state of a property while a handler is running.
Isn't there something in the 'new' externals interface that can share rev
globals, or pass a handle to a memory block? I'm talking out of my hat here.
On 24 September 2010 10:15, dunb...@aol.com wrote:
Jacques, et al.
The wait with messages, which I know about, is compact and cool. But that
On 9/24/10 12:15 PM, dunb...@aol.com wrote:
I was asking if any state of the machine can be accessed from outside a
running handler. I read from all the responses, as I thought, that it cannot.
I see now. I think until we get threading, you can't.
--
Jacqueline Landman Gay |
On 9/24/10 11:52 AM, Alejandro Tejada wrote:
About this new information on the engine's behavior,
(at least for me) i will like to know if:
a) It was written elsewhere on the dictionary/webpages or
b) Did you get it directly from Runrev or
c) it's result of personal observation and
Isn't this what your'e asking..
Put the following script in button 1
local tRunning
on mouseUp
if tRunning is empty then put false into tRunning
put not tRunning into tRunning
set the label of me to Running: tRunning
put 1 into tCount
repeat while tRunning
wait 1
One way to simulate a repeat loop would be to have something like this:
on myHandler
Do whatever the handler does
send testForStateChange in 0 milleseconds
send myHandler to me in 100 milliseconds
end if
on TestForStateChange
Do whatever needs to be done for the test
if tTest =
Oh, external process. If its on osx, possible to do an appleevent check?
Like one of these in rev.
send whatyouwanttocheck to program programname
On Fri, Sep 24, 2010 at 11:33 AM, Mike Bonner bonnm...@gmail.com wrote:
Isn't this what your'e asking..
Put the following script in button 1
Hi Jacque,
J. Landman Gay wrote:
It isn't really new, it's been there for years. It is documented in the
dictionary in the entry for wait.
Good to know! :-)
Then, it would be great to add your comment
to the dictionary: http://docs.runrev.com/Command/wait
Thanks again for your answer!
DunbarX wrote:
This all came about because someone wanted a single universal watchdog on
his stack. He had several handlers in several places, all of which could
create a condition he wanted to act upon. So the send in time handler fit that
bill. If he created yet another such handler
I think this is the right immediate solution. Jacque is always
right. And I have done this down deep in an I/O routine, but when I
can, I try to embrace the event driven nature of LiveCode and avoid
such loops.
What happens at each button click and keystroke should be fast and
neat in
On Fri, Sep 24, 2010 at 7:15 PM, dunb...@aol.com wrote:
Jacques, et al.
The wait with messages, which I know about, is compact and cool. But that
code needs to reside within the running handler. As do, in their own way,
all the other comments from everyone. For example, BonnMike notes you
I think the scenario Dunbar is describing can be handled with a combination
of an overhead watcher script that includes a send in time message to call
itself every so often, and a global variable or variables which are being
set in the sub-condition checking scripts which may contain repeat
On Fri, Sep 24, 2010 at 1:12 PM, Richard Gaskin
ambassa...@fourthworld.comwrote:
Indeed it would:
Add Threaded messaging and or execution in Transcript
http://quality.runrev.com/qacenter/show_bug.cgi?id=2832
But threading comes with an additional level of responsibility. Right now
we
Richard's approach would be my approach also. It's usually easier to make the
solution overly complex, than to make it this simple.
Phil Davis
On 9/24/10 11:12 AM, Richard Gaskin wrote:
DunbarX wrote:
This all came about because someone wanted a single universal watchdog on
his stack. He
Right, but the running handler has to contain these checking routines. I
was asking if this can be done completely from outside them.
In a message dated 9/24/10 2:37:56 PM, wdur...@gmail.com writes:
I think the scenario Dunbar is describing can be handled with a
combination
of an overhead
On Fri, Sep 24, 2010 at 8:12 PM, Richard Gaskin
ambassa...@fourthworld.com wrote:
DunbarX wrote:
This all came about because someone wanted a single universal watchdog on
his stack. He had several handlers in several places, all of which could
create a condition he wanted to act upon. So the
On Fri, Sep 24, 2010 at 8:37 PM, wayne durden wdur...@gmail.com wrote:
I think the scenario Dunbar is describing can be handled with a combination
of an overhead watcher script that includes a send in time message to call
itself every so often, and a global variable or variables which are being
Hi Zryip,
Sorry, I didn't catch the first post.
And Craig, I don't quite get the point about it all being in the same
handler? Because with the wait with messages and the send in time scenario,
all the handlers are effectively getting some time slices and all getting
to run somewhat as if each
I still have some of those BeeHive gadgets. When they went out of business,
I bought a bunch. I used them all in projects, a handful of which are still
running. There is a modern version for liveCode:
http://www.bkohg.com/serviceusbplus_e.html
As for this thread. It still seems that people are
Maybe one can sprinkle calls to checker throughout code which can
look at global variable or be passed local variables. The body of
the checker handler can be commented out in the penultimate version.
Dar
On Sep 24, 2010, at 1:18 PM, dunb...@aol.com wrote:
As for this thread. It still
Hi Craig,
Perhaps it is in the semantics when you say interrogate a running handler
somehow. A running handler can document it's status by setting a global
variable. Even if that handler has a repeat forever loop, if you have a
wait 1 millisecond with messages statement within the loop the
zryip theSlug wrote:
Threading is cool. But it depends of your needs.
During more than 10 years I'm doing development and excepted specifics
needs, the only need I have with thread is have a thread which sleep
for an amount of time and wakeup to perform an action. In one hour,
one day...
In
On Sep 24, 2010, at 1:18 PM, dunb...@aol.com wrote:
There is a modern version for liveCode:
http://www.bkohg.com/serviceusbplus_e.html
Cool!
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe,
Jeff Massung wrote:
That said, there are areas where LiveCode could - itself - benefit from
multi-threading that isn't exposed to the end user. One example of this is
in access to the internet, file, or various OS accesses. Being able to issue
a large disk read/write and get a callback when
Wayne.
Yes. I did that to actually provide a solution. This whole thing is a
theoretical question, and it seems to have been resolved, especially by Jacque,
Richard Gaskin and Jeff, that a multiThreaded liveCode would be required to
make it happen.
I don't miss it. I was just wondering...
cron can also be useful for that, at least for OS X and Linux.
What is the command-line equivalent of cron on Windows?
In a command prompt, type:
AT -- help
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to
That's to keep it handy for the Livecode Resource Center. A small button
that says Launch PDF is there.
On 24 September 2010 12:38, Richard Gaskin ambassa...@fourthworld.comwrote:
One small step in that direction, from the LiveCode 4.5 Release Notes.pdf
(which is unfortunately buried deep
On Fri, Sep 24, 2010 at 9:25 PM, Richard Gaskin
ambassa...@fourthworld.com wrote:
zryip theSlug wrote:
Threading is cool. But it depends of your needs.
During more than 10 years I'm doing development and excepted specifics
needs, the only need I have with thread is have a thread which sleep
I am sorry Craig, I apparently got lost in the thread or came late or
something I came to RunRev from RealBasic where we did have threads of
a sort and I used them primarily to allow a responsive interface while
processing over large text files.
I haven't missed them with the combination of
Wayne.
Do you mean lost in the multi-thread? I would be.
Craig
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
On Sep 24, 2010, at 1:38 PM, Richard Gaskin wrote:
Jeff Massung wrote:
That said, there are areas where LiveCode could - itself - benefit
from
multi-threading that isn't exposed to the end user. One example of
this is
in access to the internet, file, or various OS accesses. Being
able
Craig-
Friday, September 24, 2010, 12:18:41 PM, you wrote:
As for this thread. It still seems that people are thinking you can
interrogate, from the outside, a running handler somehow. You can't. At least
not
that I have seen.
You can. But it's ugly. Trust me, you *really* don't want to do
On 9/24/10 1:43 PM, Jeff Massung wrote:
LiveCode's single-threaded messaging system is actually quite good and
powerful, and I wouldn't attempt to add any multi-threading capabilities to
it without a serious inward look that was also willing to break many of the
paradigms currently in place.
On 9/24/10 2:38 PM, Richard Gaskin wrote:
One small step in that direction, from the LiveCode 4.5 Release
Notes.pdf (which is unfortunately buried deep inside the app bundle on
OS X virtually guaranteeing no Mac customer will ever see it):
They're in the Help menu now.
--
Jacqueline Landman
Richard
One small step in that direction, from the LiveCode 4.5 Release Notes.pdf
(which is unfortunately buried deep inside the app bundle on OS X virtually
guaranteeing no Mac customer will ever see it):
The release notes are easily accessible from the LiveCode IDE Menu
(help-release
On 9/24/10 1:23 PM, Dar Scott wrote:
I think this is the right immediate solution. Jacque is always right.
I'd really appreciate it if you could tell my husband that.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software |
44 matches
Mail list logo
