The hidden AutoIt window

[pixelsearch]

Hello everybody

Each time a script is launched (compiled or not), there is a hidden AutoIt window which is immediately created, its native title is always "AutoIt v3" and its Class is also "Autoit v3"

So this is just a theorical question, for those in the know : AutoIt help file (topic AutoItWinSetTitle) stipulates the following :

The AutoIt window is usually hidden. The purpose of changing the title is to allow other programs (or other AutoIt scripts) to interact with AutoIt.

But nothing is said concerning the read-only Edit control found inside the window. Can we use it without problem and place whatever we want in it ? Or is it forbidden as it is used internally by AutoIt ?

Here is an example that I just scripted, to avoid the use of global variables when using Timers (I like Timers !) , where the Edit control is simply used to transfer data from a function to the Timer callback function :

expandcollapse popup

#include <GuiEdit.au3>
#include <MsgBoxConstants.au3>
#include <WinAPISysWin.au3>

Opt("MustDeclareVars", 1) ;0=no, 1=require pre-declaration

Example()

;==============================================
Func Example()

    Local $sRandomTitle = StringFormat("%.10f", Random(10^9, 2^31 - 1)) ; 10 digits . 10 decimals => always 21 length
    AutoItWinSetTitle($sRandomTitle)
    Local $hAutoIt = WinGetHandle($sRandomTitle) ; it would have been possible without $sRandomTitle, but a bit less accurate.
    AutoItWinSetTitle($hAutoIt) ; handle as title
    Local $hEdit = ControlGetHandle($hAutoIt, "", "Edit1")

    Local $sTitle = "MsgBox special title"
    _GUICtrlEdit_SetText($hEdit, $sTitle & @crlf & "Option 1" & @crlf & "Option 2" & @crlf & "Option 3")

    Local $iChoice = _MsgBox(BitOr($MB_CANCELTRYCONTINUE, $MB_TOPMOST), $sTitle, "MsgBox text")
EndFunc   ;==>Example

;===========================================
Func _MsgBox($iFlag, $sTitle, $sText, $iTimeOut = 0, $hWnd = 0)

    Local $hTimerProc = DllCallbackRegister('_MsgBoxTimerProc', 'none', 'hwnd;uint;uint_ptr;dword')
    Local $iTimerID = _WinAPI_SetTimer(0, 0, 10, DllCallbackGetPtr($hTimerProc))

    Local $iChoice = MsgBox($iFlag, $sTitle, $sText, $iTimeOut, $hWnd)

    _WinAPI_KillTimer(0, $iTimerID)
    DllCallbackFree($hTimerProc)

    Return $iChoice
EndFunc   ;==>_MsgBox

;===========================================
Func _MsgBoxTimerProc($hWnd, $iMsg, $iTimerID, $iTime)

    Local Static $hAutoIt = AutoItWinGetTitle(), _
        $hEdit = ControlGetHandle($hAutoIt, "", "Edit1"), _
        $aEdit = StringSplit(_GUICtrlEdit_GetText($hEdit), @CRLF, $STR_ENTIRESPLIT + $STR_NOCOUNT)

    If WinActive($aEdit[0]) Then
        _WinAPI_KillTimer(0, $iTimerID)
        Local $hMsgBox = WinGetHandle($aEdit[0])
        For $i = 1 To Ubound($aEdit) - 1
            ControlSetText($hMsgBox, "", "Button" & $i, $aEdit[$i])
        Next
        _GUICtrlEdit_SetText($hEdit, "")
    EndIf
EndFunc   ;==>_MsgBoxTimerProc

If anyone got infos about the safeness / dangerousness when using this Edit control, please be kind to share your knowledge, thanks !

[argumentum]

I'd say that "Windows is a windows that has windows". That Win32control is just that, a control. In my experience you can use it for IPC, identifiers or anything you feel like it.
There is no danger in using it. The question would be why do you wanna do that. But if you wanna, do it. I've done it in the past without any problems.

[pixelsearch]

1 hour ago, argumentum said:

The question would be why do you wanna do that

Thanks for your point of view.
I did it because I am always curious and wanted to try something I never did until now (i.e. working with AutoItWinSetTitle), also it was "to reduce the number of global variables"

I always smile when talking about "reducing the number of global variables" because it makes me think of mikell, each time. If you could read what he wrote to me on May 20, 2023 (I just re-read his long PM right now). He was a bit angry, since years, with this question of global variables that should be avoided etc...

As mikell is not with us any more (and I truly miss him, it's a pity he lefts us so soon because he was a great person) then I'll share a part of what he wrote to me concerning this point (the less vehement part) first in French (his [our] native language, at least Melba23, Nine and jchd will understand  ) then I'll use a translator to indicate it in English :

On 5/20/2023 at 10:59 AM, mikell said:

[...] Quand tu mets en tête de script des '#include', cela revient à y inscrire une branlée de variables globales (qui ne sont pas toujours des constantes) alors franchement, tu crois vraiment que tu vas gravement pénaliser les performances de ton code en en rajoutant quelques unes ?
Personnellement j'ai quelques doutes [...]

 

[...] When you add '#include' at the head of the script, it amounts to adding a bunch of global variables (which are not always constants) so frankly, you really think that you are going to seriously penalize the performance of your code by adding a few?
Personally I have some doubts [...]

imho he was right. Who cares if we add a couple of global variables to our scripts, if it makes them more readable ? We shouldn't frown when a user adds a few global variables, when #include adds dozen & hundreds of them...

When I use Global variables, I like to prefix them with g_ so they're easily recognizable when reading the script later. Unfortunately I don't do it each time, that's a big mistake.

Edited September 23 by pixelsearch
a few changes

[argumentum]

2 hours ago, pixelsearch said:

... also it was "to reduce the number of global variables" ...

If is to play around, it would be interesting to see the speed of writing and reading to a control vs. a global variable. I'd bet that the variable is faster.
There are also the goodies of Au3Stripper in AutoIt3Wrapper that removes unused variables from the merged script, making the avoidance of #includes not a thing anymore.

And yes, the $g_ thing, ... I have a hard time reading my old code because I always thought that the code is it's own comment. Wrong. I don't understand why I did this or that. Same boat here I guess. But am getting better !, by age 99 ( give or take a decade ) I'll be a mindful programmer