TextArea and Arrow keys don't appear to work as expected

chr(28) is the left arrow
chr(29) is the right arrow
chr(30) is the Up arrow
chr(31) is the Down arrow

When I have a paragraph of text in a TextArea control and my cursor is centered in the middle of this text, I can move the cursor to the left, right, up and down using the arrow keys on my keyboard.
When I send the chr codes using code in a button action event, nothing appears to happen. I would have expected the cursor to move.
Is this even possible to do?

What you want to change is the Cursor Position.

DesktopTextArea:
https://documentation.xojo.com/api/user_interface/desktop/desktoptextarea.html

Cursor start position (SelectionStart)*
https://documentation.xojo.com/api/user_interface/desktop/desktoptextcontrol.html.SelectionStart

Thanks. I was looking at that in the documentation and thought to myself, that is a lot of code just to do a simple task of moving the cursor up 1 line with a simple chr(30). Someone might ask, why do I want to do this? Here’s my answer if it makes sense to anyone.
I use a Shell class in interactive mode and execute the built in Rsync command that one finds in terminal. All that works fine and my app is totally functional. In my effects to clean up my visual output, I wanted to mimic what Rsync does when the --progress switch is used as part of the command. In terminal, Rsync overwrites the percentage of the copying process each time it is updated until the copy is done for that file. The end result is, terminal retains only the final result and the whole process repeats itself for additional files being copied.
In the Shell mode within Xojo, the copying progress ends up being a new line for each update from rsync. I currently live with this output but it does tend to create some fairly large log files.

Now, I’ll have to roll up my sleeves and figure out the logic I am going to need to do this as it sounds like control characters (except for the tab character) are not handled in the TextArea class. I’m retired now, so I have lots of time (at least I think I do, I’m 70). I’ve turned to programming to keep my mind active, there is only so much TV that I can watched before I go bonkers. LOL.

I learn by looking at examples, but I have not found anything that addresses this. Thanks again.
Joe

You can’t send any keys to the textarea that way, control keys or not. There is a SendKeys type function on each OS using declares, but in my opinion that would be more work than simply manipulating SelectionStart.

What do you mean by “send”? Are you doing such as:

mytextarea.addtext (chr(28))
mytextarea.text = mytextarea.text + chr(28)

or something else?

That’s what I was doing. I tried both methods. To do some testing I created a simple program with 5 objects.
They are 2 textarea, 1 textfield, 2 buttons. The textfield is the ascii code, so I can change it while running the app. The buttons are CheckLen and Add. The Textarea are Input and Answer. The input is preloaded with “This is a test line of text.” (no quotes) the textfield is preloaded with 65 (Capital Letter A). When I run the app and press CheckLen the answer is 23. When I click Add, the capital letter A is added to the input. When I click CheckLen the answer is now 24. When I change textfield to be 8 (backspace) and then click Add, Input doesn’t change. When I click the CheckLen it has increment by 1, so now it displays 25. I can repeat these steps multiple time, changing the textfield to something else each time and the answer always increases by 1 when I do a CheckLen. This would indicate that textarea is accepting the characters whether they can be seen or not. By the way, a 13 (return) in the textfield will show up in the input by moving the cursor down 1 line (it helps to set focus on Input). One gets some interesting characters in Input when you begin entering textfield values greater than 160. Moving on, it looks like I will have to use Methods CharacterPosition, LineNumber to mimic the action I am looking for.

Using Xojo 2021r3.1
2014 Macbook Pro Big Sur

Well, there ins your answer. You are sending CHARACTERS, Not key presses. The text area IS working as expected in this case.

Well if you add characters to the textarea by software, they get added. With typed characters, you can to examine each character, perhaps in the KeyDown event handler, as you get it and take action there. In a number of my textareas I do quite a lot of processing such as expanding nicknames the user may have typed in. You also get to return either True or False from KeyDown, which affects matters too.

Oh, you were inserting them in the text. No, that doesn’t work with control characters. It sounds like you need to strip the endofline from the string you receive and then add a line ending yourself when appropriate.

With your method, the characters are added to the field but you can’t see them directly.
However, if you then add visible text (e.g. you type something on the keyboard) after these invisible characters, you’ll be able to discover them by using the arrow keys: use the left arrow key to go where you added these invisible characters and you’ll see the insertion point will stay at the same place for the same number of times you have invisible characters; only then will the insertion point move further.
That’s one proof the characters are indeed there.

When you press the arrow key, it triggers a KeyDown event with the value chr(28). If you don’t do anything special to it, the textarea will respond by moving the insertion point and then discard the chr(28). It doesn’t get added to the text in the textarea. However, chr(28) is also a valid character, so you can add it to a string and it takes up one byte of the string. It’s not a visible character, but it is a valid byte value and has no special properties, such as causing the insertion point to move. That is handled by the keyboard alone.