KeyDown is just a message

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9285
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: KeyDown is just a message

Post by richmond62 » Thu Feb 07, 2019 8:43 pm

Yes, but . . .

While can emulate a mouseClick on a button on a stack we seem unable
to emulate a finger-press on a keyboard button . . . and because of that
we are, probably, unable to determine an end-user's keyboard layout
without having the end-user perform a finger-press or three themselves,
which is a big nuisance.

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: KeyDown is just a message

Post by bogs » Thu Feb 07, 2019 9:43 pm

FourthWorld wrote:
Thu Feb 07, 2019 6:26 pm
Similarly, to emulate typing we have the "type" command.
Agreed for the 'emulate' part, but in the case of what Craig was discussing, sticking a simple breakpoint into the field handler prevents *actual* typing from the keyboard from showing up. That shouldn't happen, right?
Image

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9578
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: KeyDown is just a message

Post by dunbarx » Thu Feb 07, 2019 10:08 pm

Bogs wrote;
sticking a simple breakpoint into the field handler prevents *actual* typing from the keyboard from showing up
Right. More is happening than simply "freezing" the process and restarting it. Something changes, which is counterintuitive. This seems sinister, and might throw a user, like me.

I know for a fact that this happens in more ordinary circumstances. A breakpoint will, intermittently, cause a failure of a handler once that handler resumes. The problem can be fixed by simply running the handler again, but with the breakpoint removed. I will try to see if I can reproduce this the next time it happens, and save the stack for examination.

Craig

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: KeyDown is just a message

Post by bogs » Thu Feb 07, 2019 10:43 pm

I'm glad you mentioned it, breakpoints and the debugger are two of my "go-to" tools, and until now, I trusted them implicitly :|
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: KeyDown is just a message

Post by FourthWorld » Thu Feb 07, 2019 10:55 pm

dunbarx wrote:
Thu Feb 07, 2019 10:08 pm
Bogs wrote;
sticking a simple breakpoint into the field handler prevents *actual* typing from the keyboard from showing up
Right. More is happening than simply "freezing" the process and restarting it. Something changes, which is counterintuitive. This seems sinister, and might throw a user, like me.
It's a difficult problem, since typing only happens when a field has focus, and in every app in just about every OS a field loses focuses when another window comes to the front and focus is shifted to one of its controls.

How should this be resolved? Since the IDE is written in LC, any one of us could patch it once we do the hard part of deciding what should happen.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: KeyDown is just a message

Post by bogs » Thu Feb 07, 2019 11:20 pm

Sorry, there is just too much I still don't know to even hazard a guess :?

Every message I think has to be stored (somewhere), is it possible to get the last message like it is the last target and then put that after the breakpoint somehow?
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: KeyDown is just a message

Post by FourthWorld » Thu Feb 07, 2019 11:37 pm

So should the IDE pause, bring the user's window to the front, restore focus to the field, type the char, then bring the debugger back into focus with each char of a "type" command?

I can't even recall the last time I saw any code using the "type" command....
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9578
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: KeyDown is just a message

Post by dunbarx » Fri Feb 08, 2019 12:02 am

Richard makes a point, in that the debugger coming to the front is a "change" in the environment, and the loss of focus in the field is a clear result of that.

Just the way things work.

Craig.

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: KeyDown is just a message

Post by bogs » Fri Feb 08, 2019 10:40 am

FourthWorld wrote:
Thu Feb 07, 2019 11:37 pm
So should the IDE pause, bring the user's window to the front, restore focus to the field, type the char, then bring the debugger back into focus with each char of a "type" command?
Actually, having thought that one out, I don't think I was that far off. In point of fact, the character should be placed in the field before the breakpoint is allowed to happen, THEN the breakpoint should fire, then statement next, next next, etc., so I am thinking it is merely an out of order problem.

If the breakpoint is occuring before the character is shown due to interception of the message, but no step after it is preventing the typed character, then absolutely the character should still go back in regardless of the state of the field.

Ultimately, it shouldn't matter if the field has the focus or not currently, the action of typing the character started before the breakpoint took the focus away, and all breakpoints are supposed to be non destructive. It doesn't matter how unlikely you find a situation, in anything that can be found the result of using the debugger and its tools should be non harmful.
Image

Post Reply

Return to “Talking LiveCode”