Jacque, could you please clarify this? What's the difference between
happening and being acted on? If Rev loses messages, I'd like to
understand, so I don't write code that's likely to fail and that
cannot be
debugged.
-- Dick
Got a discussion on this with Mark on chatrev a fortnight ago... is
this part of the dialogue any related to your question? (see the 2
buttons situation below)
Marielle: I tried creating a stack. One button.
Marielle: Button script:
Marielle: on mouseup .... lock messages ... answer "hi" ... end
mouseup
Marielle: if I click over and over again on the button, I get to
see the dialog box
Mark: of course, because lock messages doesn't stop the running
handler
Mark: it only stops messages from being sent and thus prevents
"new" handlers from being run
Marielle: not the current one. But if I am supposed to put xtalk in
a "I don't listen" mode, then this wouldn't work the second time.
Mark: no, because messages are unlocked as soon as all handlers
have finished running
Mark: d.w.z. all handlers that are called by the currently running
handler
Marielle: okay
Marielle: so that's just temporary.
Marielle: okay, two buttons. First one, on mouseup ... answer
"hi"... end mouseup
Marielle: second one, on mouseup .... set the lockmessages to
true ... send mouseup to button 1 ... end mouseup
Marielle: I still see the dialog box
Mark: do you mean, you see the dialog box twice?
Mark: oh, two buttons
Mark: ok
Marielle: but if I send "click at the loc of button 1" then I don't
see it.
Mark: so, that's normal, because you are calling a handler from an
already running handler
Mark: right, because "click" makes the engine send the message
Mark: and lock messages prevents the engine from sending these
messages
Marielle: okay, I start to understand better
Marielle: lock messages prevent messages triggered by onscreen
events from being listened to (forwarded is probably more exact)
Marielle: flush events gets these messages created...accumulate
them.... then trash them.
Mark: more exact would be to say that lock messages prevents the
engine from sending the messages, while you can still "send" them
yourself
Marielle: yes, that's what I mean by "onscreen" events
Marielle: (messages that are the results of user actions)
Mark: flush events doesn't accumulate any messages, it just trashes
messages if they are waiting at that particular moment
Mark: "waiting" meaning that they are in the queue
Marielle: so messages get processed as they arrive. If messages
haven't been processed yet, they get trashed?
Mark: sorry, in what kind of situation?
Marielle: generic case (abstract level).... let's try to come up
with a situation.
Marielle: I have a button. On click triggers a process that takes a
few computer cycles.
Marielle: I have a user with problems who just decided to bang his
head on the keyboard. That slow process is triggered again and again.
Marielle: the engine will do its best to process all request.
Marielle: but a flushevents will just tell it "forget about it",
ignore all other requests in the queue?
Marielle: is it something like this?
I paste below the rest the dialog, relevant to these issues, below
this reveals my abysmal lack of mastery of any advanced concept.
I would be keen as well to have a good explanation on messages, when
they can be skipped or left in the queue or discarded. flushevents vs
lockmessages, when to use them, how to use them, etc.
Marielle: related question. Lock messages... what is it for exactly?
[...]
Mark: lock messages just stops all messages from being sent
Mark: all of them
Mark: but the handler that is running keeps running of course
Marielle: it's just that calls to any other handlers are not made
anymore?
Mark: no
Mark: I didn't say calls
Mark: I said messages that are being sent
Mark: you can still call handlers from another handler
Marielle: so, what are messages exactly. UI events?
Marielle: what's the difference between a user clicking on the
screen and doing "send mouseup" from within a script?
Marielle: (I mean if lockmessages is set to true)
Mark: the difference is that if the user clicks on the screen, it
is the engine that sends a new message
Marielle: but lockmessages will have the same effect on both?
Marielle: That engine part, newbies like me never had a chance to
understand how this works.
Mark: I believe that the messages invoked by "send" will run
immediately
Mark: that's just another way to call a handler
Marielle: so, though you use the word "message", it will be "sent"
despite the fact lockmessages is set to true?
Mark: yes, and yes it is logical ;-)
Marielle: sure! Logical.
Marielle: so if lockmessages doesn't prevent messages from being
sent, what does it do?
Marielle: What is a "message", by the way?
Mark: a message is what makes handlers run
Mark: but they can be sent from another handler or by the engine
Marielle: what triggers them?
Mark: and lockmessages prevents the engine from sending them
Marielle: how is message <> event?
Mark: no events in xtalk languages
Mark: we dont' call them events
Marielle: so a message is the same as what others call events?
Marielle: events -> message -> handler.
Marielle: the logic would be that you can't block events (they are
things that the user do on the screen)
Mark: I don't know, I don't know how other people define event
Marielle: but in xtalk, you can block messages.
Mark: I don't know what" things that user do" are
Mark: yes you can
Marielle: "things" = madly clicking all over the place with the mouse
Mark: eventually, messages are sent as a result of user input,
including opening the programme
Marielle: a mousedown is what I do with my mouse. xTalk cannot stop
me from doing it.
Marielle: but xtalk can choose not to listen
Mark: yes, if a user clicks with the mouse madly, there is user
input and messages are being sent, unless you lock messages
Marielle: how long does the lock messages remain active? within the
handler it is in?
Marielle: is it like itemdel, where the value is put back to the
default one when the handler exits?
[part above]
Mark: well, you'd have to flush many different messages
Mark: maybe that command should have been called flushMessages :-)
Marielle: :-D
Mark: you'd have to flush keydown, rawkeydown, commandkeydown, and
many more messages
Marielle: flushEvents("all")
Marielle: okay, so again the doc is incomplete. I can flush more
events than listed there.
Marielle: I could flush something specific like a commandkeydown?
Mark: you can flush any message
Mark: and I wouldn't expect the docs to list every single message
Marielle: Although some of the eventTypes have the same names as
built-in Transcript messages, there is a distinction. For example,
the mouseDown event type is the operating system's response to the
user clicking the mouse button. When the operating system sends
this event to the application, Revolution sends a mouseDown message
to the target object. The expression flushEvents(mouseDown)
prevents the application from responding to any mouseDown events it
has received from the operating system, but has not yet processed.
Mark: let me have a look myself
Mark: I see they give a list of events
Mark: yes :-D
Mark: so, according to the docs, only particular events can be
flushed, I didn't know that
Mark: after all, I used this only once
Marielle: that's what the doc says. But it wouldn't be the first
time that what it says is not what it does.
Mark: the docs may be right, give it a try
Mark: do a repeat loop for a few seconds, then try flushEvents
("mouseMove")
Marielle: yeah, I was gonna write that mousemove is the easiest
case to test
Mark: see if your mouseMove handler runs, if you put it in a field
and move over that field while the repeat loop is running
Mark: yup
Marielle: okay, will give it a try.
Marielle: thanks... I start to get a better idea of what I need to
do to try and understand ;-)
Mark: great
Marielle: so this is revolution genius bar?
Mark: nah
Mark: not necessarily
Best,
Marielle
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
