KeyDown is just a message
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Livecode Opensource Backer
- Posts: 9388
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: KeyDown is just a message
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.
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.
Re: KeyDown is just a message
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?FourthWorld wrote: ↑Thu Feb 07, 2019 6:26 pmSimilarly, to emulate typing we have the "type" command.
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: KeyDown is just a message
Bogs wrote;
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
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.sticking a simple breakpoint into the field handler prevents *actual* typing from the keyboard from showing up
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
Re: KeyDown is just a message
I'm glad you mentioned it, breakpoints and the debugger are two of my "go-to" tools, and until now, I trusted them implicitly
-
- VIP Livecode Opensource Backer
- Posts: 9842
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: KeyDown is just a message
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.dunbarx wrote: ↑Thu Feb 07, 2019 10:08 pmBogs wrote;
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.sticking a simple breakpoint into the field handler prevents *actual* typing from the keyboard from showing up
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
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: KeyDown is just a message
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?
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?
-
- VIP Livecode Opensource Backer
- Posts: 9842
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: KeyDown is just a message
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....
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
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: KeyDown is just a message
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.
Just the way things work.
Craig.
Re: KeyDown is just a message
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.FourthWorld wrote: ↑Thu Feb 07, 2019 11:37 pmSo 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?
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.