Lock Messages

[bjb007]

I was looking for a way to prevent a user
clicking on a key while the prog was making
400 clones of a small image and found "lock messages".

Worked like magic but what amazed me was
the speed increase - so much in fact that I had
to put a "wait 5" in the loop to get it to run slowly
enough.

Not sure how much time is 400 x wait 5 but got
me thinking that it's not something I've seen
mentioned in any posts, docs etc.

Anyone use it and have any tips?

[Mark]

Hi bjb,

I use lock messages and lock screen all the time, to speed up my programmes as much as possible.

What kind of tips are you looking for?

Best,

Mark

[bjb007]

Mark

As "lock messages" doesn't get many mentions
I was wondering if there are any traps for the
inexperienced - situations when "lock messages"
will cause problems.

Thanks for your interest.

[SparkOut]

This is a good topic, because I also would like some clarity on the message locking options.

The first thought is that you need to make sure that no other action that depends on messages being passed is going to be blocked. The obvious would be such as an "exit" or "cancel" button - if you have locked messages while your processing routine runs and it takes a long time, the mouseUp message when a user clicks the "cancel" button will not be passed. Also any "send <message> to <target>" actions will not be passed.

What's also interesting to me is what other structures are blocking and non-blocking. For example, a repeat loop seems to be blocking.
I can make a button

Code: Select all

on mouseUp
   global tRun
   put true into tRun
   --lock messages
   repeat with i = 1 to 10000
      if tRun is true then
         put i into field "fldResults"
      else
         exit repeat
      end if
   end repeat
   --unlock messages 
   --(should be unnecessary as messages are unlocked when the handler exits anyway)
end mouseUp

which runs about 6 times faster on my machine if I uncomment the lock and unlock messages lines.
If I have another button

Code: Select all

on mouseUp
   global tRun
   put false into tRun
   answer "Cancelled"
end mouseUp

the mouseUp message for the Cancel button is still blocked by the repeat loop, whether or not lock messages has been set. So the question is, what blocking and non-blocking options are there?

For instance, I have a stack which has a table grid, being a summary of records. On double-clicking the grid on a particular line, it will go to the detailed view card for the record of the selected grid line. That all works perfectly, except that when the detailed card opens, the mouse may be over a control in the new card which takes a mouseUp from the grid clicks - it may hit a radio group and change the value, or in some cases the "cancel and return to summary" button. What's the best way to catch this - and redesigning the detailed view card is not possible due to various other constraints. (I'd prefer to have a consistent "navigation type area" of controls which shouldn't be in any strategic places, but it's not possible to design it that way.)

PS - I've tried to lock the messages in a preOpenCard and openCard handler and then unlock them after the initialisation, and also tried to intercept the pendingMessages but that is always empty.

[SparkOut]

Well, I did a bit more fiddling and it seems related to this:

Now this is really weird:

Oddly, on my Windows XP machine, for quick clicks, the messages are:

mouseDown
mouseUp
mouseDoubleDown
mouseDoubleDown
mouseDoubleUp

when I'm clicking the button which has mouseUp and mouseDoubleUp handlers specified. I changed the handlers to mouseDown and mouseDoubleDown to see how that affected things and try to follow the messages. The results where that for 10 "rapid" (left)clicks the counter was incremented by a total of 15, and for 10 "rapid" right-clicks the counter was decremented by a total of 5 (it was possible to see the label being set down by two and then having an extra count added back).
In this case, following the messages I observed:
mouseDown
mouseUp
mouseDoubleDown
mouseDoubleDown
mouseDown
mouseUp

Which has baffled me. The messages that are triggered should be the same, regardless of what handlers have been set to catch them, isn't that correct? How can changing the handlers in a button actually change the messages that are generated by the clicking actions?

mouseDoubleUp is working OK (although it has other impact on the code) but mouseDoubleDown passes mouseDowns and Ups very strangely.

[Mark]

Bjb,

An important trap to be aware of is the situation where you want to wait with messages until another handler has finished a task. If that last handler locks messages, the first handler, which is currently waiting, will never resume.

You can solve this by using a repeat loop or another handler that sends a message to itself, until the task has finished.

Probably, the best way to learn this is to run into the problem :-)


Sparkout,

You might send a message to the target, which will run after the target catches any reduntant messages.

Code: Select all

on mouseDoubleUp
  send "goToDetailedViewCard" to me in 0 millisecs
end mouseDoubleUp

on goToDetailedViewCard
  go cd "Detailed View"
end gotoDetailedViewCard

The inconsistency in the order in which mouse messages are sent and the multiple occurrence of messages are bugs. There are a few bugs reported already, describing this or similar behaviour. You might want to check the CQQ to see whether the problems you describe here have been reported too.

Best regards,

Mark

[SparkOut]

Hi Mark,
thanks for that. As it happens, onMouseDoubleUp works OK - with a slight impact on some other code which relies on a mouseUp handler, but nothing that can't be worked around. Out of interest, I tried the "send in time" construct with a mouseDoubleDown handler, and the same problem occurred, that having double clicked in a particular place on the grid, the new card opened and received an unwanted click at that place on the new card. I read the QCC with interest at the time of that other thread but I couldn't see anything that was specific to that issue. I will have another look. I'm still baffled by the behaviour that simply having a different handler causes different messages - a bit quantum, if you ask me.

Anyway, any other hints about blocking structures and non-blocking? I see that there is some logic to have a repeat loop being blocking, but it did surprise me that the example I mentioned above wouldn't work. Any way of avoiding those sort of surprises in future?