like pass, but without ending the handler

[Marielle Lange]

> 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