LiveCode Forums

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.

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?

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

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

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.

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?

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 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.

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.