Sorry @Christian, I didn’t quite understand this. Why is this a normal behavior? It should act like multiline input text. Consider I need a user to input multiline text like in the image below, how can I achieve that? I know by replacing the default button with standard button will fix this.
When the focus is on the text area, the return goes there.
If the focus is not on a text area, the return goes to the focussed control.
If no control takes the return key, it goes to the window and if that doesn’t take it too, than it triggers the default button.
Aha, I understand that concept. In here, we rarely use the term “Return” for Enter key.
I’m trying to track the focus and see what happen when i press “Enter” key. As you can see, when the focus in TextArea, I still can’t add EOL to the input although the focus is still there.
It works different from previous versions. The big enter-key shows up in KeyDown as (asc) 13, the little enter key shows up in KeyDown as (asc) 3. We have a solution, but I guess that won’t work with large texts. We catch the chr(3) in KeyDown and if it’s at the last textposition we add chr(13), if not we insert a chr(13) at SelStart.
Yes, the ‘Return’ key which is the one near the main keys (generally below backspace) is completely different from the ‘Enter’ key on the numeric keypad.
Return means ‘Carriage Return’ (including a line feed) from the typewriter days. The Enter key essentially means ‘submit/commit’.
It really disturbs me when I see a keyboard labelled with two ‘Enter’ keys
Actually, looking a 4 keyboards at my work, two PC and 2 MAC the said offending keyboards with two Enter keys are on the PCs only - the mac keyboards are labelled correctly.