A control's variable must be global or static Topic is solved

[afe]

Hello,
When I put "Gui, Add, ActiveX" into the function, I get an "A control's variable must be global or static" error. Why need to declare the "WB" variable as global or static?

Code: Select all

Error:  A control's variable must be global or static.

Specifically: vWB

	Line#
	001: F()  
	004: {
--->	005: Gui,Add,ActiveX,w980 h640 vWB,Shell.Explorer
	006: WB.Navigate("https://autohotkey.com/")  
	007: Gui,Show
	009: Return
	010: }
	011: Exit
	012: Exit
	012: Exit

The current thread will exit.

Code: Select all

F()
return
F()
{
	Gui, Add, ActiveX, w980 h640 vWB, Shell.Explorer
	WB.Navigate("https://autohotkey.com/")
	Gui, Show

	return
}

[Osprey]

Local variables are automatically freed when functions return. Perhaps AutoHotkey can't free a variable that's in use by a GUI or it's just trying to help users avoid errors when trying to use those GUI controls outside of the function. Just add "global" to the top of the function and you'll be able to do this later, for example:

Code: Select all

F()
WB.Navigate("https://google.com/")
return

[afe]

I found that not only ActiveX controls, all Gui variables need to be declared as global or static variables.
Why?

Code: Select all

f()
return

f()
{
    Gui, Add, Button, w80 vButton, OK
    Gui, Show, h100 w200
    return
}

[Osprey]

They don't. You're putting your Gui inside of a function, and variables inside functions are local by default. It has nothing to do with it being a Gui or a certain type of Gui control.

[nnnik]

You are assigning a local variable as a name to a GUI Control.
The Control stays around but all local variables are cleaned after the function exits.
The GUI Control however requires the variable to stay around.

[afe]

Ok, it seems that I can only declare it.

[A_AhkUser]

Ok, it seems that I can only declare it.

Actually, at least for Active X control, GuiControlGet retrieve a new wrapper object for the control's ActiveX component (GuiControlGet - Sub-commands) so, for example, it is quite conceivable to do this:

Code: Select all

MsgBox, 64,, % f()
f() {
	Gui, Add, ActiveX, w980 h640 hwndAXID, Shell.Explorer
	GuiControlGet, var,, % AXID
	var.silent := true
	var.Navigate("https://autohotkey.com/")
	while (var.busy || var.ReadyState <> 4)
		sleep, 100
	out := var.document.title
	Gui, Destroy
return out
}

[SOTE]

Hello,
When I put "Gui, Add, ActiveX" into the function, I get an "A control's variable must be global or static" error. Why need to declare the "WB" variable as global or static?

I would argue that one might want to be careful about stuffing GUIs into functions. One reason is mixing the GUI and a task that you want the function to do or result that you want to get from the function, can be bad practice. That is, you have the function doing so many things, creating confusion about what might have gone wrong. Calling functions from a GUI is fine, but arguably the GUI being inside of the function might be much less beneficial, unless you are creating customized GUIs or the GUI is narrowly focused to do one thing. Also GUIs in functions tend to be less transportable and less useful as a library that can be used in other applications, as they tend to be very customized for a particular application.

[afe]

I would argue that one might want to be careful about stuffing GUIs into functions. .

But sometimes it seems impossible to avoid. Such as the following example,

Code: Select all

Gui, Add, Button,, Run
Gui, Show, h300 w400
return

ButtonRun:
f()
return

f()
{
    ...
    if ( x = 1 )
    {
        ; Need to create another GUI here
        ...
    }
    return
}

Edit:
Thank you very much! Your suggestion is very inspiring!
I modified the code. Will this be better?

Code: Select all

Gui, Add, Button,, Run
Gui, Show, h300 w400
return

ButtonRun:
x := f()
if ( x = -1 )
{
        ; Create another GUI here
}
return

f()
{
    ...
    if ( x = 1 )
        return, -1
    ...
    return
}

[SOTE]

I modified the code. Will this be better?

Yeah, something like that. Each part is doing a specific task, so it's easier to troubleshoot. It arguably creates a bad habit, when you have your functions, subroutines, or GUIs loaded down doing all kinds of different tasks with different purposes. Avoid creating a spaghetti mess. The bigger and more complex your scripts get, the harder it can be to troubleshoot, so better to have the habit of building scripts in "blocks". Trust me, I learned this from hard experience. Detangling mixed up spaghetti code isn't fun.

Also, AHK v1 has g-labels (https://www.autohotkey.com/docs/commands/Gui.htm). It can be a little hard to spot this feature in the help documents, so some might miss it. You can specify which labels or functions your buttons will run, from your GUI, by prefixing and attaching a "g" in front of the label`s or function`s name.

Code: Select all

MainGui:
Gui, Main: Add, Button, gRunGui2, Gui2
Gui, Main: Show, h300 w400
return

SecondGui:
Gui, 2: Add, Button, gf, Exit
Gui, 2: Show, h150 w200, Second GUI
return

RunGui2()
{
	Gosub, SecondGui	
}

f()
{
	Msgbox, Execute This Function
	ExitApp
}

[afe]

Yeah, something like that. Each part is doing a specific task, so it's easier to troubleshoot. It arguably creates a bad habit, when you have

Thank you so much, your suggestions have benefited me a lot.