KeyDown is just a message

[dunbarx]

Not sure whether this is even a topic of interest, or a topic at all.

In a button script:

Code: Select all

on mouseUp
   send "keyDown XYZABC" to fld 1
end mouseUp

And in the field script:

Code: Select all

on keyDown tkey
  put tkey after me --hardly simply a key
end keyDown

Is this an example of the native message "keyDown" being "intercepted" and reformulated as a custom message? The parameter can be of any length, and therefore works differently than the ordinary usage of that message. Of course, the handler in the field works as advertised.

I only ask because, unlike HC, I know it is not possible in LC to change a function by intercepting before the engine, and thought also that one could not similarly subvert a message.

Craig

[FourthWorld]

The name of built-in functions cannot be used for custom function handlers. This keeps engine lookups tidy and lean, and provides reliable support for any code expecting a given function to perform a certain way.

Message names, however, do indeed support custom handlers. How could we use them if we could not write handlers for them?

Key messages are like mouse messages and all the others: we write handlers to intercept the message to handle it how we need. In this regard LC and HC are the same, except that LC has many more messages available.

[dunbarx]

Richard.

I know. What made me write in the first place, which now seems unimportant on reflection, was that the parameter to the keyDown message could be a string of any length. I am so used to keyDown in its "ordinary" usage, that is, a char passed as the result of a keyPress, that I did not think much beyond that.

Of course, "it is just a message", as I wrote in the "KeyCaps" thread just today:
viewtopic.php?f=8&t=32111

Rereading that again, I wonder why I bothered posting at all. No answer to that.

Craig

[bogs]

What made me write in the first place, which now seems unimportant on reflection, was that the parameter to the keyDown message could be a string of any length. I am so used to keyDown in its "ordinary" usage, that is, a char passed as the result of a keyPress, that I did not think much beyond that.
<SNIP>
Rereading that again, I wonder why I bothered posting at all. No answer to that.

Well, I appreciated learning it, so I'm glad you wrote it down 'cause I'd never have thought of it myself

[FourthWorld]

Same here as Bogs. As I said in my Community Wrap Up at LiveCode Global this year, one of the things I like about Craig's posts is that he pushes and pokes around the edges of the engine, and most of the time we all learn something new from it.

I wouldn't have thought to check anything beyond a single character, but there may be cases where it can be useful to send a string.

What happens in the field if you send keyDown with a multi-char string and simply pass it?

[dunbarx]

Nothing happens.

Apparently "keydown" has to originate from the field itself for a char to appear at the insertion point:

Code: Select all

on mouseUp  --in the button
   send "keyDown C" to fld 1
end mouseUp

on keyDown tKey --in the field
   pass keyDown
end keyDown

And as for poking around the edges, I like the solitude. By the way, did you know that in a field script:

Code: Select all

 on keyDown tKey 
   breakpoint
   pass keyDown
end keyDown

If one types into the field, then lets the handler continue, no character is placed into the field. What disconnects?

Craig

[bogs]

That actually sounds like what I would expect to happen, in my mind running something like this -
you press a key..
on key down it reaches the handler
your passing the keydown

Throwing the breakpoint in doesn't change that your putting in code to pass the event (I think).

[[-hh]]

Craig, you are a LC "extremist"...
I always read your contributions with interest.

Script a field with

Code: Select all

on keydown k
    answer k
end keydown

This answers every char you pressed in a short interval defined by your keyboard system prefs (especially regarding the repeat rate), try to press several keys at the same time.
But never press too long a key in that field, and never put a brick on your keyboard when the field has focus

[dunbarx]

Bogs.

Throwing the breakpoint in doesn't change that your putting in code to pass the event (I think).

But it does. No char is written into the field. Stopping the handler, and then continuing breaks the flow somehow.

Hermann.

This is interesting. The very first answer dialog should block all subsequent events, no? Then how does holding down a key queue events at the repeat rate? Apparently, I do not understand blocking.

And yes, DO NOT hold that key down too long, unless you:

Code: Select all

on keydown k
   if the optionKey is down then exit to top
    answer k
end keydown

Craig

[[-hh]]

Good old mechanical typewriter ... I have still one in the darkest edge of my cellar.

[Thunder]

Bogs.

Throwing the breakpoint in doesn't change that your putting in code to pass the event (I think).

But it does. No char is written into the field. Stopping the handler, and then continuing breaks the flow somehow.

Hermann.

This is interesting. The very first answer dialog should block all subsequent events, no? Then how does holding down a key queue events at the repeat rate? Apparently, I do not understand blocking.

And yes, DO NOT hold that key down too long, unless you:

Code: Select all

on keydown k
   if the optionKey is down then exit to top
    answer k
end keydown

Craig

Is flushEvents usable here ?

[dunbarx]

Thunder.

Play around, but:

Code: Select all

on keydown k
   answer k
  get flushevents("all")
end keydown

Did not work.

Craig

[dunbarx]

Also made one try canceling the pendingMessages, and still no luck.

These two still might do the trick, with a little more investigation.

Craig

[bogs]

Bogs.

Throwing the breakpoint in doesn't change that your putting in code to pass the event (I think).

But it does. No char is written into the field. Stopping the handler, and then continuing breaks the flow somehow.

I tested it, and changed my previous opinion (and had a second cup of coffee)

[FourthWorld]

In a way this kinda makes sense, or is at least consistent with how the other input messages work, like those for mouse input.

When we send "mouseDown" to a control, the control gets the message but does not highlight as though it was clicked on. In this way, LC, HC, and the other xTalks all consistently and reliably do what we're asking: we're not emulating an input, but sending a message.

To emulate a mouse click we use "click at the loc of btn 1".

Similarly, to emulate typing we have the "type" command.