Tooltips hitting max. number of GUI controls?

[james3mg]

I have a script that has a few child GUIs embedded within the main GUI window (so that essentially subsets of the GUI can scroll independantly). One of the child GUIs gets destroyed and rebuilt based on selections in another child GUI. My thought was that by actually destroying the child GUI each time, I wouldn't have to worry about hitting the maximum number of GUI controls in a single window...but apparently that's not the case. After about 50 times of destroying and recreating the child GUI, I start getting CtrlID returns of 0 and controls stop being created (and before that, the script starts slowing down significantly).

So my question is twofold:

-I thought the limit was per GUI, but it seems that controls in a child GUI count toward the limit in the GUI it's embedded within...am I correct in my observation?

-Is there any more thorough way than GUIDelete() of really destroying the GUI (and controls within it) and "reclaiming" those controls so I don't run into the listed 65532 controls limit?

Thanks!

Edited January 11, 2010 by james3mg

[GEOSoft]

I can't believe this question after the four and a half years that you have been on these forums.

Yes, they count towards the total

Is GUISetState(@SW_SHOW, $Child1) and GUISetState(@SW_HIDE, $Child1) missing from your copy of the help file?

[james3mg]

I can't believe this question after the four and a half years that you have been on these forums.

Yes, they count towards the total

Well, when the help file says,

65532 : Maximum number of controls in GUI box.

and I use a different GUICreate() call to create each "window", it's not exactly clear, is it? I honestly thought that each gui was ... a different GUI, therefore each having it's own independent 65532 controls limit. They do when they're actual separate windows, so I didn't see why being a child would make a difference. If that's something I should have learned by osmosis in 4.5 years, then forgive me. I don't do real C programming, so sometimes I don't understand the mechanics behind things. I don't think it's a fault that I want to keep learning, but want to learn the truth, rather than a mistaken belief based on a single observation, so I don't apologize for that. It's your prerogative to ignore me if you think I'm wasting your time. However, in this case I do thank you for going ahead and answering that part of my question.

Is GUISetState(@SW_SHOW, $Child1) and GUISetState(@SW_HIDE, $Child1) missing from your copy of the help file?

You know it's not. But how is hiding and showing a GUI going to help me reclaim the space or address or whatever the limit for the number of controls is? Clearly, deleting a GUI (which, I believe is more thorough than merely hiding it) doesn't erase the record AutoIt keeps of how many controls are "in" a window, so I'm asking if anything exists which DOES do what I want. If I show 50 controls, but then no longer need them, I'd like to purge them entirely so that the next time I show, say, 40 controls, it's a total of 40 controls for the GUI, not 90. Edited December 23, 2009 by james3mg

[Melba23]

james3mg,

To add to the confusion, I have just run a small experiment.

I repeatedly created a child GUI with a few controls in a loop which then deleted it. Throughout the experiment, the ControlIDs of the controls never varied - the new ones took exactly the same numbers as those just destroyed, which is exactly what I expected - and I got to 70000 iterations with no problem (other than boredom! ).

So I wonder if there is not something else causing your problem - perhaps one of the Devs can throw some light on the subject?

M23

[Authenticity]

Not true

#include <GUIListView.au3>
#include <WindowsConstants.au3>

$hGUI = GUICreate("")
$hChild = GUICreate("", 100, 100, 10, 10, $WS_CHILD, -1, $hGUI)

For $i = 1 To 100
    $hLV = _GUICtrlListView_Create($hGUI, "123", 10, 10)
    ConsoleWrite(Number(_WinAPI_GetDlgCtrlID($hLV)) & " ")
Next
ConsoleWrite(@CRLF)

GUIDelete($hChild)

$hChild = GUICreate("", 100, 100, 10, 10, $WS_CHILD, -1, $hGUI)

For $i = 1 To 100
    $hLV = _GUICtrlListView_Create($hGUI, "123", 10, 10)
    ConsoleWrite(Number(_WinAPI_GetDlgCtrlID($hLV)) & " ")
Next
ConsoleWrite(@CRLF)

GUIDelete($hChild)
GUIDelete($hGUI)

Seems like you must call GUICtrlDelete and/or _GUICtrl*_Destroy.

[james3mg]

I got to 70000 iterations with no problem (other than boredom! ).

OK, that's good information too, thanks. I had also noticed that the CtrlID of the controls created in each successive child GUI reused the same integer IDs, until they started returning 0, that is. The fact that you got to 70000 controls gives me pause though. I'll try an experiment of my own like yours and see if we're not using different methods or something...I'll update in a minute. Edited December 23, 2009 by james3mg

[james3mg]

Not true

[...script...]

That's interesting- but if you do a GUICtrlCreateListView instead of _GUICtrl_ListViewCreate, the numbers ARE reused.

What's the difference in those methods? Many of the controls I'm recreating are labels, so it doesn't directly apply, but it's interesting nonetheless.

Edit: I just tried inserting a GUICtrlDelete() for each control in the GUI before it's destroyed, and no luck...it still bogs down the script as I proceed, and finally hits the limit. And I don't think that Labels have a _GUICtrl_LabelDestroy() function So, no luck still

Edited December 23, 2009 by james3mg

[Authenticity]

So the controls must be re-created every time? Can't you have like the biggest foreseen child GUI window and display, hide, edit, etc.. the controls?

[james3mg]

#include <WindowsConstants.au3>

$Main=GUICreate("test",800,600)
GUISetState(@SW_SHOW,$Main)
For $i=1 To 1000
    $SelectsGUI=GUICreate("Overrides",275,300,525,300,BitOR($WS_BORDER,$WS_CHILD),-1,$Main)
    For $x=1 To 140
        If GUICtrlCreateSlider(0,0,20,20)=0 Then
            ConsoleWrite("ERROR AT "&$i*140+($x-1) & @CRLF)
            Exit
        EndIf
    Next
    GUISetState(@SW_SHOW,$SelectsGUI)
    If StringRight($i,2)="00" Then ConsoleWrite($i & " " & @CRLF)
    GUIDelete($SelectsGUI)
Next

worked perfectly (I used sliders instead of labels- I figured that was a pretty complicated control, so if anything would blow up, it'd be that).

So now I don't know what the problem is. I'll go back to my main script and start simplifying to see if I can find what makes it break. Thanks for the assistance!

Edit: I didn't see the reply there before I replied...sorry Authenticity. The controls are really fully dynamic- the project is a lighting control board, so the child GUI is displaying an intersection of controls common to all selected fixture types (in the other window), and the fixture types are also dynamic (that is, unknown at compile-time). The maximum, if I really wanted to go that way, would be up to 512 channels, each with the potential for 255 settings and a few constant labels per channel- about 133120 controls to track, update, move, etc. For speed reasons, let alone complexity, I think I'll keep looking for a delete/recreate solution until I prove to myself it's not possible. However, my case test above gives me hope (near ceartainty) that it actually is possible- I just need to find my error.

I'll post back if/when I find it, just in case it helps someone

Edited December 24, 2009 by james3mg

[Melba23]

Hi all,

I have been playing around some more and I still get all controls within a GUI destroyed whan the GUI is destroyed - no need for GUICtrlDelete or _GUICtrl*Destroy commands in addition.

Here is a small example - the child holds 2 buttons, one created with the built-in GUICtrlCreateButton command (hence the need to get the Windows handle with GUICtrlGetHandle) and the other with the UDF _GUICtrlButton_Create (which needs the _WinAPI_GetDlgCtrlID call to get the ControlID). As you can see, both controls reuse the same ControlID each time they are created and both appear to be destroyed after the GUIDelete call.

expandcollapse popup

#include <GUIConstantsEx.au3>
#Include <GuiButton.au3>

$hGUI = GUICreate("Test", 50, 50, 100, 100)

GUISetState()

$iCount = 0

While 1

    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            Exit
    EndSwitch

    $iCount += 1
    If $iCount = 1000 Then Exit ; This takes about 90 secs to run on my machine

    $hChild = GUICreate("Child", 50, 70, 50, 50)

    $hButton_1 = GUICtrlCreateButton("Test", 10, 10, 30, 20)
    $hButt_Handle_1 = GUICtrlGetHandle($hButton_1)
    $fButtState_1 = IsHWnd($hButt_Handle_1)

    $hButt_Handle_2 = _GUICtrlButton_Create($hChild, "Test", 10, 40, 30, 20)
    $hButton_2 = Number(_WinAPI_GetDlgCtrlID($hButt_Handle_2))
    $fButtState_2 = IsHWnd($hButt_Handle_2)

    GUISetState()

    GUIDelete($hChild)

    ConsoleWrite($hButton_1 & " - " & $hButt_Handle_1 & " - " & "Before: " & $fButtState_1 & " - After: " & IsHWnd($hButt_Handle_1)  & " <======> " &  _
                 $hButton_2 & " - " & $hButt_Handle_2 & " - " & "Before: " & $fButtState_2 & " - After: " & IsHWnd($hButt_Handle_2)  & @CRLF)

WEnd

I remain convinced that james3mg has another problem than merely maxing out the ControlID table.

Happy holidays to everyone.

M23

[james3mg]

I found the answer.

The problem wasn't technically an error on my part, but I'm not positive it was really that I was "maxing out" the control ID table, either.

The problem is that every label I was dynamically creating had a tooltip associated with it- and that seems to be the problem. Maybe if ToolTips count toward the max. controls in a GUI window, and apply to the parent rather than the child (so they can appear no matter which GUI is "current"), that would explain why they don't get destroyed with the GUIDelete() call, and so it might be maxing out the table after all. But I'm just speculating there. In any rate, if I comment out the line assigning a tooltip, everything works, not only (MUCH) faster, but seemingly for as many repetitions as I care to trigger.

As an example, I submit the following script which is identical to the one I showed as "working" above- but with the addition of a ToolTip line only. On my laptop, it slows down way too much before it ever maxes out the number of controls and quits itself, but I assume it would get there eventually.

#include <WindowsConstants.au3>

$Main=GUICreate("test",800,600)
GUISetState(@SW_SHOW,$Main)
For $i=1 To 1000
    If StringRight($i,1)="0" Then ConsoleWrite($i & @CRLF)
    $SelectsGUI=GUICreate("Overrides",275,300,525,300,BitOR($WS_BORDER,$WS_CHILD),-1,$Main)
    For $x=1 To 140
        If GUICtrlCreateLabel("hi",0,0,20,20)=0 Then
            ConsoleWrite("ERROR AT "&$i*140+($x-1) & @CRLF)
            Exit
        EndIf
        GUICtrlSetTip(-1,"tooltip")
    Next
    GUISetState(@SW_SHOW,$SelectsGUI)
    If StringRight($i,2)="00" Then ConsoleWrite($i & " " & @CRLF)
    GUIDelete($SelectsGUI)
Next

So, I guess my final question is; is there any way to dispose of unneeded ToolTips? They don't return a CtrlID upon creation, so I can't GUICtrlDelete() them, nor can I find any standard UDFs that might expand on their capabilities in this way. I'd assumed that they got deleted when their controls did, but apparently not.

Thanks again, everyone...for your previous help and any ideas you have about how to solve the ToolTip issue!

[smashly]

Hi,

I' not sure about the tooltip part of what your saying, I ran your script and it doesn't error out.

It does slow down a bit.

Can't you just use the tooltip with "" to null the tooltip as needed.

eg:

$Label =  GUICtrlCreateLabel("hi",0,0,20,20)
GUICtrlSetTip(-1,"tooltip")
......
........
GUICtrlSetTip($Label,"")

[james3mg]

Hi,

I' not sure about the tooltip part of what your saying, I ran your script and it doesn't error out.

It does slow down a bit.

Can't you just use the tooltip with "" to null the tooltip as needed.

eg:

$Label =  GUICtrlCreateLabel("hi",0,0,20,20)
GUICtrlSetTip(-1,"tooltip")
......
........
GUICtrlSetTip($Label,"")

Really? I get: ERROR AT 10032 a little bit after it hits "70". (I'm at home now, on an 8-core machine ).

I thought your idea about a null tooltip call might work, but I added GUICtrlSetTip("") in the line directly following GUICtrlSetTip(-1,"tooltip") (meaning the tip is set and IMMEDIATELY un-set...the best chance of it working, IMO), and I hit the limit at the same place. Also, unsetting the tip slowed everything down nearly twice as much as it was even before.

So no dice yet.

[james3mg]

Now that the Holidays are over and everyone's probably back, I wanted to bump this topic up again- I'm still seeking an answer, though my questions have changed somewhat (you can skip to the blue text at the end if you don't want a recap of what I've found)

Where I currently stand:

I believe the answer to my original questions are:

Q: Am I correct in my observation that controls in a child GUI count toward the limit in the GUI it's embedded within, rather than each child GUI having it's own limit as a normal GUI would.

A: No, each child GUI (as far as I can tell) has it's own limit of 65532 controls.

Q: Is there any more thorough way than GUIDelete() of really destroying the GUI (and controls within it) and "reclaiming" those controls so I don't run into the listed 65532 controls limit?

A: No, GUIDelete() really does fully delete the controls.

I found the problem that led me to my mistaken impression in my first question was the tooltips I was assigning each control in the child GUI(s). Even if I delete the GUI and all it's controls, if I recreate such child GUIs containing tooltipped controls over and over, the creation of each subsequent child GUI is slowed dramatically and the controls themselves finally start returning "0" as the CtrlID. If I comment out only the tooltip-assigning line in my code, both of these symptoms disappear entirely.

However, if I just go through and "null out" the tooltips (using ToolTip($CtrlID,"")) before deleting and recreating the GUI, the original symptoms return, leading me to believe that not only does it not actually delete the tooltip, but that the tooltip (nulled or not) persists even after the control and containing GUI to which it was attached is deleted.

So it seems to me that the behavior I observe would be easiest explained by the following assumptions being true:

1) ToolTips count as a control, and therefore count against the limit of 65532 controls per GUI

2) ToolTips on controls within a Child GUI count against the control number limit of the parent GUI, NOT against the control number limit of the child GUI it is contained/created in.

Can anyone who knows the workings of AutoIt confirm/correct these assumptions?

If I am correct in those assumptions, I would like to find a way to actually delete a tooltip, and thus reclaim it's space in counting toward the per-gui control number limits. Does anyone know how to do that?

Edited January 7, 2010 by james3mg

[AdmiralAlkex]

1) ToolTips count as a control, and therefore count against the limit of 65532 controls per GUI

MSDN referes to them as "Tooltip Controls", so I would guess yes.

[Melba23]

james3mg,

I am still not convinced that you are correct in your assertion that child GUIs have their own 65532 control limit. Assuming that the limit is there because of the size of the AutoIt ControlID table (which seems logical), then the fact that ANY control created within the same script has the next available number makes me think that that limit is PER SCRIPT, and not PER GUI. If that were the case, then surely each GUI you created would end up with the same ControlID numbers (restarting from 1 each time) and we would have to use GUIGetMsg with the advanced parameter every time we had more than a single GUI - as it is, we only need it to distinguish between control events like $GUI_EVENT_CLOSE which could have come from any GUI in the script.

Look at this small example:

#include <GUIConstantsEx.au3>

$hGUI_1 = GUICreate("Test 1", 200, 100, 100, 100)

$hButton_1 = GUICtrlCreateButton("Test 11", 10, 10, 80, 30)
ConsoleWrite($hButton_1 & @CRLF)

GUISetState()

$hGUI_2 = GUICreate("Test 2", 200, 100, 300, 400)

$hButton_2 = GUICtrlCreateButton("Test 21", 10, 10, 80, 30)
ConsoleWrite($hButton_2 & @CRLF)

GUISetState()

GUISwitch($hGUI_1)

$hButton_3 = GUICtrlCreateButton("Test 12", 110, 10, 80, 30)
ConsoleWrite($hButton_3 & @CRLF)

GUISwitch($hGUI_2)

;GUICtrlDelete($hButton_1)

$hButton_4 = GUICtrlCreateButton("Test 22", 110, 10, 80, 30)
ConsoleWrite($hButton_4 & @CRLF)

While 1

    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            Exit
    EndSwitch

WEnd

Try running it with and without the GUICtrlDelete line - the ControlIDs are obviously in the same table even though they are in different GUIs.

Anyway, let us see what the Devs say!

M23

[james3mg]

james3mg,

I am still not convinced that you are correct in your assertion that child GUIs have their own 65532 control limit.

[...excellent explanation...]

OK, I understand what you're saying now; I've just been going off of what I read in the help file: Maximum number of controls in GUI box. I took that to mean in each GUI box, and hadn't stopped to question that interpertation (apparently skipping it or misreading it when you tried to tell me). Seems to me that there did used to be a much lower per-gui limit, but I may be making that up, too. I just ran a quick test of my own with two GUIs, and my computer does start rather flipping out when I exceed about 65000 controls, no matter the number of GUIs. (Odd that should affect the whole OS when I breach that limit though... ). That plus your very clear explanation above I think has finally gotten it through my head

To further embaress myself, I will divulge that, I was so convinced that was the case, that I did indeed call GUIGetMsg() with the advanced parameter in any script in which I had more than one GUI.

So that explains why the tooltip controls (thanks, Admiral) seem to count toward the "parent" GUI number of controls- they're all in the same total, lol!

So that answers that. Now I need to figure out how to destroy unneeded ToolTip controls. That MSDN article AdmiralAlkex linked me to seems to indicate a ToolTip should have a CtrlID assigned upon it's creation, maybe AutoIt just dumps that information and doesn't pass it back to me (instead passing a "1" for success or "0" for failure)? Assuming that's the case, how difficult is it to call the Windows API for ToolTips myself, as shown on that page, so that I can store the CtrlID and call the associated Destroy function? It loses me a little- do I have to calculate the positioning, monitor the mouse position and tell it to display as appropriate, all within my script if I do that?

I'll also try another little scriplet here, calling GUICtrlDelete() on the logical numerical CtrlID of a tooltip, even though it wasn't passed to me. It'll be interesting to see if the API behind GUICtrlDelete() works if I manage to find the CtrlID of the ToolTip Control.

Edit: Forget it; seems the CtrlIDs we can actually access from the AutoIt engine skips Tips, too. Creating a label in a new GUI gives me a CtrlID of 3, then if I set a tip on the label, and then create a button, the button has a CtrlID of 4, and no amount of GUICtrlDeleting() anything but 3 or 4 returns anything but a 0, and the tip persists.

Guess my questions about deleting tips or calling the Windows API myself remain my only questions about this.

GUICreate("Test",640,480)

Global $Input=GUICtrlCreateInput("",5,5,100,20)
ConsoleWrite($Input & @CRLF)
GUICtrlSetTip($Input,"tip")
Global $Button=GUICtrlCreateButton("Delete",105,5,30,20)
ConsoleWrite($Button & @CRLF)

GUISetState()

While 1
    $msg=GUIGetMsg()
    If $msg=-3 Then Exit
    If $msg=$Button Then ConsoleWrite(GUICtrlDelete(GUICtrlRead($Input))&@CRLF)
WEnd

Edited January 7, 2010 by james3mg

[Melba23]

james3mg,

You can delete tips - here is an example of how to do it:

expandcollapse popup

#include <GUIConstantsEx.au3>
#include <Array.au3>

$hGUI = GUICreate("My GUI control tip")  ; will create a dialog box that when displayed is centered

$hLabel = GUICtrlCreateLabel("my label", 10, 20)
$hLabel_Handle = GUICtrlGetHandle($hLabel)

GUISetState()

; Windows existing after our GUI
$aList1 = WinList()

GUICtrlSetTip($hLabel, "tip of my label")

Sleep(1000)

; Windows existing after our tootip
$aList2 = WinList()

; Remove all List1 windows from List2
For $i = 1 To UBound($aList1) - 1
    $iIndex = _ArraySearch($aList2, $aList1[$i][1], 0, 0, 0, 0, 1, 1)
    _ArrayDelete($aList2, $iIndex)
Next

; And the top one left is our tool tip!!!!!!!!!!!
_ArrayDisplay($aList2)

; Check here and the tooltip exists <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

; Delete tootltip window
WinKill($aList2[1][1])

; Check window has been deleted
ConsoleWrite(WinExists($aList2[1][1]) & @CRLF)

; Check here and the tooltip has gone <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

; Run the GUI until the dialog is closed
While 1
    $msg = GUIGetMsg()
    If $msg = $GUI_EVENT_CLOSE Then ExitLoop
WEnd

However, this is a cumbersome method. And I had to make sure the tooltip was displayed during the Sleep to make sure that the [1][1] window was indeed the tooltip - it gives the text in the [1][0] element if it is displayed while the second list is created. Unfortunately it does not if it not visible, because that would make WinGetHandle an easy solution.

There must be a better way - but that is for tomorrow....

M23

[AdmiralAlkex]

The devs aren't very active in the support forums, it could take some time until they see this thread.... Try sending a PM one of them

Edited January 8, 2010 by AdmiralAlkex

[Melba23]

james3mg,

This is as good as I can get it. It is pretty fast as I have limited the WinList search to tooltips_class32 windows and reduced the _Array* functions to a minimum.

expandcollapse popup

#include <GUIConstantsEx.au3>
#include <Array.au3>

; List tooltips now
$aList1 = WinList("[CLASS:tooltips_class32]")
;_ArrayDisplay($aList1, "Before")

$hGUI = GUICreate("My GUI control tip")  ; will create a dialog box that when displayed is centered

$hLabel_1 = GUICtrlCreateLabel("my label", 10, 20)
GUICtrlSetTip($hLabel_1, "tip of my label_1")

$hLabel_2 = GUICtrlCreateLabel("my label", 10, 120)
GUICtrlSetTip($hLabel_2, "tip of my label_2")

GUISetState()

; List tooltips now
$aList2 = WinList("[CLASS:tooltips_class32]")
;_ArrayDisplay($aList2, "After")

; This puts the additional tooltip handles into another array
Global $aList3[$aList2[0][0] - $aList1[0][0] + 1] = [0]
For $i = 1 To $aList2[0][0]
    If _ArraySearch($aList1, $aList2[$i][1], 0, 0, 0, 0, 1, 1) = -1 Then
        $aList3[0] += 1
        $aList3[$aList3[0]] = $aList2[$i][1]
    EndIf
Next

; Destroy the before and after arrays
$aList1 = 0
$alist2 = 0

; And those left are our tool tips!!!!!!!!!!!
_ArrayDisplay($aList3, "ToolTips!")

; Check here and the tooltips are there <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

; Delete tootltips
For $i = 1 To $aList3[0]
    WinKill($aList3[$i])
Next

; Destroy the tooltip array - from what you have said it could be quite large!
$aList3 = 0

; Check here and the tooltips have gone <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

; Run the GUI until the dialog is closed
While 1
    $msg = GUIGetMsg()
    If $msg = $GUI_EVENT_CLOSE Then ExitLoop
WEnd

So it looks as if you will have to list tooltips_class32 windows before and after you create each of your child GUIs and then determine the handles of the newly created tooltips which are associated with your GUI. When you destroy the child GUI, you can also destroy the associated tooltips as well - and your problem is solved.

M23

Edit: Clarity

Edited January 8, 2010 by Melba23