Simulate keypress in a script

[richmond62]

One of the problems about sending an arrowKey signal from,
say, a mainStack to a subStack is that for the mainStack to pick up
the arrowKey signal it has to be the topLevel stack, which, of course,
means that a field in the substack will have lost focus
so there will be no insertion point at that moment.

[dunbarx]

There are ways to store and reset the insertion point. It is just more work, and at a point it has to be determined whether it all is worth it.

I have been so stubborn at times that I have made something work well past the point it was worth it.

Craig

[kaveh1000]

Thanks Craig. That works. I am going to rack my brain a bit more to see if it is at all possible to let the "arrows do the work". If not, I'll give up and do the coding. It's such a shame we can't simply use the functionality built in at a low level...

[kaveh1000]

Hi Craig

I am still racking my brain, until I know I can't get the native arrow keys to do the work for me!!

Here is an example of how the keys work natively, but where we have to try hard to emulate using handlers:

Suppose you have a field where text is wrapping. You have one very long para, which wraps around 10 lines. Then you have a series of short lines after that, each with an explicit line break.

To the eye the long para and the 10 short paras look the same. And when I press the up arrow, the cursor jumps to the line above, whether it is in the long para, or in the short paras.

Now to emulate that with handlers, it is not too hard to do the short paras, but with the wrapping para, we cannot say go to previous line. The only way I can think of is your selectLoc solution, which is fine but still needs work to deal with short lines, edge effects, like ensuring we don't click outside the field, etc.

Another native action of the arrow keys is when you have shift key down, and you overshoot an extended selection, you just press the opposite arrow key and it reduces the selection. And always does what you want.

Sorry to harp on, but just sharing some thoughts on the problem.

I have been trying to pass chars to a field remotely. Here is a minimal stack:

https://drive.google.com/file/d/1s-3H_s ... sp=sharing

(sorry, can't work out how to attach stacks here.)

Question is, when I send rawKeyDown to the field, why do I not see that character in the field itself?

[bogs]

(sorry, can't work out how to attach stacks here.)

Simplicity itself, zip (compress) the stack, then click on Attachments below, then "Add files"

Attach a file...

Selection_001.png (9.52 KiB) Viewed 5121 times

[kaveh1000]

Thank you sir.

[jacque]

The keydown and rawKeyDown etc messages are sent to the target as a response to a user action. They aren't the cause of the action, so calling them will only execute the commands you give them. The OS is responsible for fielding the user action and passing it to LC.

However, you can simulate the user action with the "type" command. Try:

Code: Select all

type numToChar(65362) 

Might work.

[richmond62]

The keydown and rawKeyDown etc messages are sent to the target as a response to a user action.

Really?

a send "rawKeyUp 108" message could be embedded in a whole, slew of code analysing a data set.

[kaveh1000]

Hi Jacque

What you say is what I was thinking, in that I am too far down the action chain to simulate a user typing.

But it's getting closer. Your solution works for normal ascii chars, e.g.

Code: Select all

type numToChar(65) 

giving "A", but

Code: Select all

type numToChar(65361) 

types "Q"

Please see minimal stack.

[capellan]

This topic is really interesting and after reading all answers
I wonder if LiveCode allows to send a keypress to another
application (like Open Office) from a LiveCode application
or from a stack opened in the IDE.

Al

[richmond62]

types "Q"

Ho, Ho, Ho: try this:

Code: Select all

type numToCodePoint(65361) 

[kaveh1000]

I get chars similar to q and r but not quite:

Real q an r:

Code: Select all

qr

result for 65361 and 65362:

Code: Select all

ｑｒ

[richmond62]

Probably the reason what you are trying appears NOT to be working is that you
have chosen unicode addresses for half-width lower case Latin letters.

0xFF51 / 65361 is "q" as is 0x0071 / 113

http://www.unicode.org/charts/PDF/UFF00.pdf

https://www.unicode.org/charts/PDF/U0000.pdf

"Go Gay" and try some rather more unusual unicode glyphs:

Code: Select all

on mouseUp
   send "type (numToCodePoint(0x1251) & numToCodePoint(0x12B3))" to fld "f1"
end mouseUp

And you'll get 2 lovely Ethiopic letters:
-

Ethiopic.png (9.26 KiB) Viewed 4971 times

-
If you "feel funny about Hexadecimal counting" (or, like me, you only have 10 toes) try this:

Code: Select all

on mouseUp
   send "type (numToCodePoint(4689) & numToCodePoint(4690))" to fld "f1"
end mouseUp

https://www.unicode.org/charts/PDF/U1200.pdf

Oh, and before I go:

Make this place your "online home" from now on:

https://www.unicode.org/charts/

[jacque]

@Richmond, he doesn't really want to enter characters in the field, he wants to send a simulated keypress to the OS as though the user had done it physically. That will allow LC to use the built-in behaviors for arrow keys.

The only thing that comes close, I think, is the "type" command, and I'm not sure if that goes to the OS or whether LC is just using that to generate its own messages. Since only the ascii set works, I suspect it's the latter.

Unfortunately I don't know any other way to accomplish the goal other than scripting every possible reaction.

[dunbarx]

The OP example of a large paragraph followed by short lines shows how hard it is to move the cursor from line to line and maintain the same visual hLoc. The number of chars from the start of each line is not "visually" constant in a wrapped field.

That is why the kluge, to use a property that sidesteps that issue entirely, that is, to simply use the hLoc of the selectedText, might be the most "elegant". It seems the native arrowKey action works that way. After all, if it is after the third char is one line, it will set itself after the third visual, not actual, character in another line.

Craig