Problem with Edit Control (Long Time User)

[evanevery]

I have been using (and loving) AutoIT for many, many years.  So I would think this should have a simple explanation.  I've found a suitable solution (as will be explained), but I'm curious if anyone could explain why this issue is behaving the way it is...

NOTE that there are two calls to GUICtrlCreateEdit (One commented out) and two calls to GUICtrlSetData (both commented out) in my sample code.  These can easily be used to demonstrate what works and what does not.  Also note that my Edit Control is being used as a "Read Only" info window ($ES_READONLY) if it matters...

1.  If I simply create my Edit Control and specify the text (during creation), the text in the control comes up highlighted.  (This is how the example below is configured).  This does not seem appropriate.

2.  If I create an EMPTY control (comment out the first GUICtrlCreatEdit and uncomment the second) and SET the text BEFORE GUISetState is called (uncomment the first GUICtrlSetData), then I also get highlighted text.

3.  However, If I create the EMPTY control, and then SET the text AFTER GUISetState is called (comment out first GUICtrlSetData and uncomment the second GUICtrlSetData), then my text appears as I would expect.

Can anyone explain WHY this is behaving in this way?  Initially, I tried multiple variations to deselect the highlighted text (_GUICtrlEdit_SetSel($LogWindowID, -1, 0)) but none of those had ANY effect whatsoever!

I'm OK with with the solution I have found but I'ld just like to know "Why".  Clearly, I must be missing something very fundamental here...

#include <GUIConstants.au3>
#include <MsgBoxConstants.au3>
#include <FontConstants.au3>

Local $EditText = "This is Line 1" & @CRLF & "This is Line 2"

Local $GUIWidth = 800
Local $LogWindowHeight = 326

Local $hMainGUI = GUICreate("Test", $GUIWidth, 50 + $LogWindowHeight, -1, -1, $WS_SIZEBOX)

Local $LogWindowID = GUICtrlCreateEdit($EditText, 20, 25, $GUIWidth - 40, $LogWindowHeight - 20, $ES_MULTILINE + $ES_WANTRETURN + $WS_HSCROLL + $ES_READONLY)
;Local $LogWindowID = GUICtrlCreateEdit("", 20, 25, $GUIWidth - 40, $LogWindowHeight - 20, $ES_MULTILINE + $ES_WANTRETURN + $WS_HSCROLL + $ES_READONLY)

;GUICtrlSetData($LogWindowID, $EditText)
GUISetState()
;GUICtrlSetData($LogWindowID, $EditText)

Do
    $msg = GUIGetMsg()

Until $msg = $GUI_EVENT_CLOSE

GUIDelete()

 

 

Edited October 14, 2022 by evanevery
Posted code inline instead of attachment

[pixelsearch]

Hi evanevery
You presented this little displeasure very nicely

It seems to happen when you got only 1 control inside the GUI, right ?
As soon as there is another control, created before or after the Edit control, for example...

Local $idButton = GUICtrlCreateButton("Button", 20, 0, 70, 22)

...then the Edit control got its text automatically unselected (which is a good thing !)

But in your script you got only 1 control (Edit) and its text is selected, which is not what you want. Quick tests show what follows :

1) If you don't want to add a single line to your script, then try to create the Edit control just after the GUISetState() line, then nothing should be selected :

#include <GUIConstants.au3>

Local $GUIWidth = 800
Local $LogWindowHeight = 326

Local $hMainGUI = GUICreate("Test", $GUIWidth, 50 + $LogWindowHeight, -1, -1, $WS_SIZEBOX)

GUISetState()

Local $EditText = "This is Line 1" & @CRLF & "This is Line 2"
Local $LogWindowID = GUICtrlCreateEdit($EditText, 20, 25, $GUIWidth - 40, $LogWindowHeight - 20, _
    $ES_MULTILINE + $ES_WANTRETURN + $WS_HSCROLL + $ES_READONLY)

Do
Until GUIGetMsg() = $GUI_EVENT_CLOSE

GUIDelete()

2) If you absolutely want to create the Edit control before the GUISetState() line (as we're all used to), then 1 additional line worked for me, for example :

GUICtrlSetState($LogWindowID, 256) ; $GUI_FOCUS = 256

Or even this line (this time after GuiSetState) :

GUICtrlSendMsg($LogWindowID, 0xB1, -1, 0) ; $EM_SETSEL = 0xB1
; msdn : If the start is 0 and the end is -1, all the text in the edit control is selected.
;        If the start is -1, any current selection is deselected.

Let's hope someone will be able to explain why this happens as it seems to be special to AutoIt, after reading this thread where OP indicated this :

OP (E1M1) words :
"In C# or C++ I dont have select all as default for edit, it's only with autoit."

Good luck

[evanevery]

Thank you for those options!  For me, it's just easier to insert the text into the control AFTER the GUISetState (My Option #3).

For what it may be worth, I did also stumble upon the "Set Focus" approach, but I did NOT find it reliable in a dynamic environment.  (This all comes into play when the control gets updated in a "REAL" app, but I did not want to muddy the waters any further than my simple example).  This also doesn't really make any sense to me.  (Why giving focus would eliminate the highlighting...)

..and I did consider adding another control to see if it made any difference (an "Exit" button or even a hidden control just for testing), but that also wouldn't really explain "WHY" we are seeing this behavior.  (And being a minimalist, I shouldn't HAVE to provide an exit button if I already have a nice little close ("x") icon already working for me...)

I have been banging on this for a couple of days so I've tried a lot of things to quantify the behavior...  This all started out as a control in a Network Aware app that would continuously display the "tail" of its own logfile...  In an effort to troubleshoot this behavior, I thought it would be interesting (and of some value) to extract a standalone Win/GUI "tail" utility.  So now I also have that!  🙂  Once I saw this issue happening when the "tailed" file was first processed (before I even generated test updates via notepad), I reduced the code even further to a simple GUI Create script.

It would really be interesting to understand what the significance is of the highlighted text and why it is appearing.  We should also note that _GUICtrlEdit_SetSel($LogWindowID, -1, 0) won't work to clear the "selection" either (maybe because my control is read-only?)... or maybe because its not really a "selection" at all!

Seems to be fairly simple behavior to demonstrate - but not to explain!

 

[pixelsearch]

14 minutes ago, evanevery said:

We should also note that _GUICtrlEdit_SetSel($LogWindowID, -1, 0) won't work to clear the "selection"

Maybe because you placed the statement before GUISetState ?
It works for me, only when placed after GUISetState :

#include <GUIConstants.au3>
#include <GuiEdit.au3>

Local $GUIWidth = 800
Local $LogWindowHeight = 326

Local $hMainGUI = GUICreate("Test", $GUIWidth, 50 + $LogWindowHeight, -1, -1, $WS_SIZEBOX)

Local $EditText = "This is Line 1" & @CRLF & "This is Line 2"
Local $LogWindowID = GUICtrlCreateEdit($EditText, 20, 25, $GUIWidth - 40, $LogWindowHeight - 20, _
    $ES_MULTILINE + $ES_WANTRETURN + $WS_HSCROLL + $ES_READONLY)

GUISetState()

_GUICtrlEdit_SetSel($LogWindowID, -1, 0) ; ok when placed after GUISetState()

Do
Until GUIGetMsg() = $GUI_EVENT_CLOSE

GUIDelete()

 

Edited October 14, 2022 by pixelsearch
typo

[funkey]

Selection can only be set if window (control) is visible.

But this is a strange behaviour. I can not reproduce this with a Win32 C test application.

I have to investigate 😉

[funkey]

Can someone tell me what is the difference between "$WS_OVERLAPPEDWINDOW" and "0x14CF0000" ????

Resulting style is the same, but for me there is a difference in text selection.....

 

#include <GUIConstants.au3>
#include <MsgBoxConstants.au3>
#include <FontConstants.au3>
#include <GuiEdit.au3>

Local $EditText = "This is Line 1" & @CRLF & "This is Line 2"
Local $GUIWidth = 800
Local $LogWindowHeight = 326

;~ Local $hMainGUI = GUICreate("Test", $GUIWidth, 50 + $LogWindowHeight, -1, -1, $WS_OVERLAPPEDWINDOW)
Local $hMainGUI = GUICreate("Test", $GUIWidth, 50 + $LogWindowHeight, -1, -1, 0x14CF0000)
Local $LogWindowID = GUICtrlCreateEdit($EditText, 20, 25, $GUIWidth - 40, $LogWindowHeight - 20, BitOR($ES_WANTRETURN, $WS_HSCROLL, $ES_READONLY, $ES_MULTILINE))

GUISetState()

Do
    $msg = GUIGetMsg()

Until $msg = $GUI_EVENT_CLOSE

GUIDelete()

 

[funkey]

Aaah.

The difference is that $WS_VISIBLE is set when creating the GUI or afterwards with GuiSetState().

So create your GUI visible and your problem should be solved.

[pixelsearch]

48 minutes ago, funkey said:

Can someone tell me what is the difference between "$WS_OVERLAPPEDWINDOW" and "0x14CF0000" ????

I always liked this "funky fun key" pseudo 

The difference should be :
 

[0x10000000, 'WS_VISIBLE']
[0x04000000, 'WS_CLIPSIBLINGS']

 

expandcollapse popup

#include-once

Global Const $Style_Gui[32][2] = _
   [[0x80000000, 'WS_POPUP'], _
    [0x40000000, 'WS_CHILD'], _
    [0x20000000, 'WS_MINIMIZE'], _
    [0x10000000, 'WS_VISIBLE'], _
    [0x08000000, 'WS_DISABLED'], _
    [0x04000000, 'WS_CLIPSIBLINGS'], _
    [0x02000000, 'WS_CLIPCHILDREN'], _
    [0x01000000, 'WS_MAXIMIZE'], _
    [0x00CF0000, 'WS_OVERLAPPEDWINDOW'], _ ; (WS_CAPTION | WS_SYSMENU | WS_SIZEBOX | WS_MINIMIZEBOX | WS_MAXIMIZEBOX) aka 'WS_TILEDWINDOW'
    [0x00C00000, 'WS_CAPTION'], _          ; (WS_BORDER | WS_DLGFRAME)
    [0x00800000, 'WS_BORDER'], _
    [0x00400000, 'WS_DLGFRAME'], _
    [0x00200000, 'WS_VSCROLL'], _
    [0x00100000, 'WS_HSCROLL'], _
    [0x00080000, 'WS_SYSMENU'], _
    [0x00040000, 'WS_SIZEBOX'], _
    [0x00020000, '! WS_MINIMIZEBOX ! WS_GROUP'], _   ; ! GUI ! Control
    [0x00010000, '! WS_MAXIMIZEBOX ! WS_TABSTOP'], _ ; ! GUI ! Control
    [0x00002000, 'DS_CONTEXTHELP'], _
    [0x00001000, 'DS_CENTERMOUSE'], _
    [0x00000800, 'DS_CENTER'], _
    [0x00000400, 'DS_CONTROL'], _
    [0x00000200, 'DS_SETFOREGROUND'], _
    [0x00000100, 'DS_NOIDLEMSG'], _
    [0x00000080, 'DS_MODALFRAME'], _
    [0x00000040, 'DS_SETFONT'], _
    [0x00000020, 'DS_LOCALEDIT'], _
    [0x00000010, 'DS_NOFAILCREATE'], _
    [0x00000008, 'DS_FIXEDSYS'], _
    [0x00000004, 'DS_3DLOOK'], _
    [0x00000002, 'DS_SYSMODAL'], _
    [0x00000001, 'DS_ABSALIGN']]
    ;
    ; [0x80880000, 'WS_POPUPWINDOW']
    ; [0x20000000, 'WS_ICONIC']
    ; [0x00040000, 'WS_THICKFRAME']
    ;
    ; [0x00000000, 'WS_OVERLAPPED'] ; also named 'WS_TILED'


Global Const $Style_GuiExtended[21][2] = _

 

[evanevery]

Although I had some issues when trying to "fix" the selection issue, it shouldn't be required in ANY case.

* Why does the edit control come up with all text selected if the data is set BEFORE GUISetState is called (and NOT if defined after)?

(It should also be noted that the selection is maintained as new data is added - except the new data is not highlighted/selected (...likely cause it was added AFTER GUISetState...))

Unless someone can explain this behavior, it certainly appears to be a bug!