Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
dunbarx
- VIP Livecode Opensource Backer
- Posts: 9660
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Post
by dunbarx » Tue Feb 05, 2019 6:14 pm
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
- VIP Livecode Opensource Backer
- Posts: 9834
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
-
Contact:
Post
by FourthWorld » Tue Feb 05, 2019 6:33 pm
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
- VIP Livecode Opensource Backer
- Posts: 9660
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Post
by dunbarx » Tue Feb 05, 2019 9:36 pm
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
- Posts: 5435
- Joined: Sat Feb 25, 2017 10:45 pm
Post
by bogs » Tue Feb 05, 2019 9:47 pm
dunbarx wrote: ↑Tue Feb 05, 2019 9:36 pm
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
- VIP Livecode Opensource Backer
- Posts: 9834
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
-
Contact:
Post
by FourthWorld » Wed Feb 06, 2019 4:26 am
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
- VIP Livecode Opensource Backer
- Posts: 9660
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Post
by dunbarx » Thu Feb 07, 2019 4:00 am
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
- Posts: 5435
- Joined: Sat Feb 25, 2017 10:45 pm
Post
by bogs » Thu Feb 07, 2019 10:36 am
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]
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Post
by [-hh] » Thu Feb 07, 2019 12:29 pm
Craig, you are a LC "extremist"...
I always read your contributions with interest.
Script a field with
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
shiftLock happens
-
dunbarx
- VIP Livecode Opensource Backer
- Posts: 9660
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Post
by dunbarx » Thu Feb 07, 2019 3:25 pm
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]
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Post
by [-hh] » Thu Feb 07, 2019 4:07 pm
Good old mechanical typewriter ... I have still one in the darkest edge of my cellar.
shiftLock happens
-
Thunder
- Posts: 20
- Joined: Thu Mar 12, 2015 1:52 pm
Post
by Thunder » Thu Feb 07, 2019 4:37 pm
dunbarx wrote: ↑Thu Feb 07, 2019 3:25 pm
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
- VIP Livecode Opensource Backer
- Posts: 9660
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Post
by dunbarx » Thu Feb 07, 2019 5:00 pm
Thunder.
Play around, but:
Code: Select all
on keydown k
answer k
get flushevents("all")
end keydown
Did not work.
Craig
-
dunbarx
- VIP Livecode Opensource Backer
- Posts: 9660
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Post
by dunbarx » Thu Feb 07, 2019 5:05 pm
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
- Posts: 5435
- Joined: Sat Feb 25, 2017 10:45 pm
Post
by bogs » Thu Feb 07, 2019 5:09 pm
dunbarx wrote: ↑Thu Feb 07, 2019 3:25 pm
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
- VIP Livecode Opensource Backer
- Posts: 9834
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
-
Contact:
Post
by FourthWorld » Thu Feb 07, 2019 6:26 pm
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.