AutoHotkey Community

Posted: **30 Aug 2017, 23:35**

Hi everyone,
here is the problem i'm confronted with :

with latest version of AHK (not meaning previous ones didn't have the issue) at the moment of the tests,
and intervening on notepad2-mod (on its Scintilla1 control) in order to modify selected string using :
Code: Select all
```
      SetTimer, WatchActiveWindow, 200
        return
      WatchActiveWindow:
          ControlGet, tSel, Selected,, Scintilla1, A
          ToolTip, %tSel%
        return
```
with encoding set to ansi... no problem : tSel does contain the text i select (dynamically)
with encoding set to UTF-8 (my default) : then tSel contains a forward offset of the actual selection
that is : a part of the edited text of same length as actual selection but shifted forward of
a certain number of positions (not always the same accross sessions, but constant during current session)
ex. of edited text: "A B C D E F G H I J K L M N O P Q R S T U V W X Y Z"
actual selection : "A B C D E F "
possible content of tSel : " H I J K L M"
without reloading the (persistent) script but
1. switching from UTF-8 to ansi
2. editing some
3. switching back to UTF-8
at this point tSel does contain the expected string : the actual selection... on the same Scitilla1 ctrl.
similarily, from 3. (while in UTF-8 and not changing),
1. pausing script
2. editing
3. un-pause script
at this point tSel does contain the expected string : the actual selection... on the same Scitilla1 ctrl.
but, from 4. and 5., script running, switching to another UTF-8 shows again same issue for that Scintilla1 ctrl.
Switching back to 1st Scintilla1 doesn't show the issue on that one.

I'm guessing this should occur with any app using Scintilla1 control, probably even any other UTF-8 ctrl :
only unconfirmed speculations

So? any idea(s)?

is it an AHK bug/feature?
let's put the blame on the controls?
windows shouldn't survive in the 1st place?
why even do selections?

...
well, if none of the above questions gets answered :

5. how about a way to get around the issue?

for more info on the tests , the versions :

Code: Select all

    Windows 7 64bits Pro 6.1.7600
    AutoHotKeys 1.1.26.01
    Notepad2-mod 4.2.25 r935

Thank you for reading my post and for any help you my provide.
Also, thank you for this great automation/scripting tool.
I'd just love to see it on more platforms (let me dream of such a day).

patienly waiting,
Clu
2017083140543

BTW : an anticipated refutal of my use of selections ...
I'm ABSOLUTELY avoiding the use of the clipboard for many reasons (security, speed, side effects...).
so, no need to try to convince me to rely on it (i do for many other things, just no here)
and, anyway... not the issue here.
thank you for your understanding.

Format : ouch ... did my editing offline, lost indentations and more. Life is a *$£ù% some times!

Posted: **31 Aug 2017, 02:02**

ControlGet wrote:Selected: Sets OutputVar to be the selected text in an Edit control. If no text is selected, OutputVar will be made blank and ErrorLevel will be set to 0 (i.e. no error). Certain types of controls, such as RichEdit20A, might not produce the correct text in some cases (e.g. Metapad).

... and apparently the Scintilla control belongs to this 'certain control types'.

ControlGet, ..., Selected is designed to be used with common Edit controls which don't provide a way to get the selection directly. AHK is sending EM_GETSEL and WM_GETTEXT messages to the control and has to use what it gets. So it's defenitely not an AHK bug. The Scintilla control provides an own message SCI_GETSELTEXT to retrieve the current selection which might work reliable. I never used it and any qestions about how to use it (especially for another application) would be a topic for "Ask For Help".

AutoHotkey Community

ControlGet Selected on Scintilla1/UTF-8

ControlGet Selected on Scintilla1/UTF-8

Re: ControlGet Selected on Scintilla1/UTF-8