Excess of Goto to the same label?

Get help with using AutoHotkey and its commands and hotkeys
Forum rules
Post Reply
Tulevik
Posts: 32
Joined: 03 Jul 2015, 11:56

Excess of Goto to the same label?

Post by Tulevik » 30 Nov 2020, 13:48

[Moderator's note: Topic moved from Bug Reports.]

Good evening,

Recently I posted this code on the forum, in order to get help with an issue. But I am not going to talk about it: I've found a bug (I've found a bug??) related to an excess of callings to the same label recursively (I have used Goto, but it also happens when you replace the Goto with Gosub).

The bug goes as follows: if you try to execute File -> New count more than 10 times, the File -> New count stops working and responding. There seems to be an error with the Goto, but as I mentioned before, if you replace the Goto with a Gosub, the bug will be the same after the 10th execution. Is this a bug of AutoHotkey, or just my fault?

And if it is my fault, what's wrong with the code?

Strange!

[Edited code, thanks to swagfag for pointing out my mistake]

Code: Select all

; Generated by AutoGUI 2.6.2
#SingleInstance Force
#NoEnv
SetWorkingDir %A_ScriptDir%
SetBatchLines -1

Menu FileMenu, Add, New count, NewCount
Menu MenuBar, Add, &File, :FileMenu

Gui, 1: New
Gui, 1: +hWndfirstWindow
Gui, 1: Menu, MenuBar

Gui, 1: Add, Edit, x5 y5 w120 h21 vCounter0
Gui, 1: Add, Edit, x100 y32 w120 h21 vCounter1
Gui, 1: Add, Edit, x150 y64 w120 h21 vCounter2
Gui, 1: Add, Edit, x200 y96 w120 h21 vCounter3
Gui, 1: Add, Edit, x250 y128 w120 h21 vCounter4

Gui Show, w620 h400, Window
Return

NewCount:
msgBox, 8196, Start New Count, Do you want to start new count?
IfMsgBox No
{
	return
}
else
{
    Gui, %firstWindow%: +Disabled
	Gui, %firstWindow%: Hide
    Gui, 2: New, -MinimizeBox -MaximizeBox -SysMenu -Caption +AlwaysOnTop
    Gui, 2: +Owner1
	Gui, 2: +hWndsecondWindow
	Gui, 2: Default
    Gui, Add, Edit, x240 y368 w120 h21 vfirstNumber, 1
    Gui, Add, Button, x100 y100 vButtonNewCount gStartNewCount, Start
    Gui, %secondWindow%: Show, w455 h400 x800 y100, Start a new count
}
Return

StartNewCount:
numberChosen:=0
Gui, 2: Submit, NoHide
GuiControlGet, numberChosen, 2:, firstNumber
GuiControl, 1:, Counter0, %numberChosen%
Gui, 1: -Disabled
Gui 2: Destroy
Gui, 1: Default
Gui, %firstWindow%: Show
Goto BeginCount
return

BeginCount:
GuiControlGet, number, 1:, Counter0
while (i<1000)
{
    contNumEdit:=1
    while(contNumEdit<5)
    {
        GuiControl, , Counter%contNumEdit%, %number%
        number++
        contNumEdit++
		sleep 1000
    }
}
return

GuiEscape:
GuiClose:
    ExitApp
Second Edit:

I also try this alternative code, with an aditional condition to the loop, and with both GUIs creating and destroying each other, but the bug persists if you start the countings one after another quickly, and from a lower number:

Code: Select all

; Generated by AutoGUI 2.6.2
#SingleInstance Force
#NoEnv
SetWorkingDir %A_ScriptDir%
SetBatchLines -1

Menu FileMenu, Add, New count, NewCount
Menu MenuBar, Add, &File, :FileMenu

Gui, 1: New
Gui, 1: +hWndfirstWindow
Gui, 1: Menu, MenuBar

Gui, 1: Add, Edit, x5 y5 w120 h21 vCounter0
Gui, 1: Add, Edit, x100 y32 w120 h21 vCounter1
Gui, 1: Add, Edit, x150 y64 w120 h21 vCounter2
Gui, 1: Add, Edit, x200 y96 w120 h21 vCounter3
Gui, 1: Add, Edit, x250 y128 w120 h21 vCounter4

Gui Show, w620 h400, Window
Return

NewCount:
msgBox, 8196, Start New Count, Do you want to start new count?
IfMsgBox No
{
	return
}
else
{
	condition:=0
    Gui, %firstWindow%: +Disabled
	Gui, %firstWindow%: Destroy
    Gui, 2: New, -MinimizeBox -MaximizeBox -SysMenu -Caption +AlwaysOnTop
	Gui, 2: +hWndsecondWindow
	Gui, 2: Default
    Gui, Add, Edit, x240 y368 w120 h21 vfirstNumber, 1
    Gui, Add, Button, x100 y100 vButtonNewCount gStartNewCount, Start
    Gui, %secondWindow%: Show, w455 h400 x800 y100, Start a new count
}
Return

StartNewCount:
numberChosen:=0
Gui, 2: Submit, NoHide
GuiControlGet, numberChosen, 2:, firstNumber


Menu FileMenu, Add, New count, NewCount
Menu MenuBar, Add, &File, :FileMenu

Gui, 1: New
Gui, 1: +hWndfirstWindow
Gui, 1: Menu, MenuBar

Gui, 1: Add, Edit, x5 y5 w120 h21 vCounter0
Gui, 1: Add, Edit, x100 y32 w120 h21 vCounter1
Gui, 1: Add, Edit, x150 y64 w120 h21 vCounter2
Gui, 1: Add, Edit, x200 y96 w120 h21 vCounter3
Gui, 1: Add, Edit, x250 y128 w120 h21 vCounter4
GuiControl, 1:, Counter0, %numberChosen%
Gui 2: Destroy
Gui, 1: Default
Gui 1: Show, w620 h400, Window
Goto BeginCount

return

BeginCount:
condition:=1
GuiControlGet, number, 1:, Counter0
while (number<1000) and (condition=1)
{
    contNumEdit:=1
    while(contNumEdit<5)
    {
        GuiControl, , Counter%contNumEdit%, %number%
        number++
        contNumEdit++
		sleep 1000
    }
}
return

GuiEscape:
GuiClose:
    ExitApp
Last edited by Tulevik on 30 Nov 2020, 17:52, edited 2 times in total.
Top
swagfag
Posts: 4141
Joined: 11 Jan 2017, 17:59

Re: Excess of Goto to the same label?

Post by swagfag » 30 Nov 2020, 16:26

#MaxThreads wrote:If this directive is unspecified in the script, it will behave as though set to 10.
ur outer while loop doesnt have a terminating condition(the variable i is never touched). when u press the "Start" button and then confirm the MsgBox, the subroutine StartNewCount: is launched in a new pseudothread which interrupts any still-running, non-critical, lower-or-same-priority pseudothreads. the subroutine eventually goes to BeginCount:, where ur endless while loop is encountered.

goto isnt bugged
Top
Tulevik
Posts: 32
Joined: 03 Jul 2015, 11:56

Re: Excess of Goto to the same label?

Post by Tulevik » 30 Nov 2020, 16:54

Thank you, it seems that was what happened. I wanted to put (while number<1000). However, that behaviour persists even in the new code, if you start ten times the counter from lower values, and quickly start again, and never let the loop ends. Should I end then the loop right before I jump, for this not to happen?
Top
Tulevik
Posts: 32
Joined: 03 Jul 2015, 11:56

Re: Excess of Goto to the same label?

Post by Tulevik » 30 Nov 2020, 17:52

I also try this alternative code, with an aditional condition to the loop, and with both GUIs creating and destroying each other, but the bug persists if you start the countings one after another quickly, and from a lower number:

Code: Select all

; Generated by AutoGUI 2.6.2
#SingleInstance Force
#NoEnv
SetWorkingDir %A_ScriptDir%
SetBatchLines -1

Menu FileMenu, Add, New count, NewCount
Menu MenuBar, Add, &File, :FileMenu

Gui, 1: New
Gui, 1: +hWndfirstWindow
Gui, 1: Menu, MenuBar

Gui, 1: Add, Edit, x5 y5 w120 h21 vCounter0
Gui, 1: Add, Edit, x100 y32 w120 h21 vCounter1
Gui, 1: Add, Edit, x150 y64 w120 h21 vCounter2
Gui, 1: Add, Edit, x200 y96 w120 h21 vCounter3
Gui, 1: Add, Edit, x250 y128 w120 h21 vCounter4

Gui Show, w620 h400, Window
Return

NewCount:
msgBox, 8196, Start New Count, Do you want to start new count?
IfMsgBox No
{
	return
}
else
{
	condition:=0
    Gui, %firstWindow%: +Disabled
	Gui, %firstWindow%: Destroy
    Gui, 2: New, -MinimizeBox -MaximizeBox -SysMenu -Caption +AlwaysOnTop
	Gui, 2: +hWndsecondWindow
	Gui, 2: Default
    Gui, Add, Edit, x240 y368 w120 h21 vfirstNumber, 1
    Gui, Add, Button, x100 y100 vButtonNewCount gStartNewCount, Start
    Gui, %secondWindow%: Show, w455 h400 x800 y100, Start a new count
}
Return

StartNewCount:
numberChosen:=0
Gui, 2: Submit, NoHide
GuiControlGet, numberChosen, 2:, firstNumber


Menu FileMenu, Add, New count, NewCount
Menu MenuBar, Add, &File, :FileMenu

Gui, 1: New
Gui, 1: +hWndfirstWindow
Gui, 1: Menu, MenuBar

Gui, 1: Add, Edit, x5 y5 w120 h21 vCounter0
Gui, 1: Add, Edit, x100 y32 w120 h21 vCounter1
Gui, 1: Add, Edit, x150 y64 w120 h21 vCounter2
Gui, 1: Add, Edit, x200 y96 w120 h21 vCounter3
Gui, 1: Add, Edit, x250 y128 w120 h21 vCounter4
GuiControl, 1:, Counter0, %numberChosen%
Gui 2: Destroy
Gui, 1: Default
Gui 1: Show, w620 h400, Window
Goto BeginCount

return

BeginCount:
condition:=1
GuiControlGet, number, 1:, Counter0
while (number<1000) and (condition=1)
{
    contNumEdit:=1
    while(contNumEdit<5)
    {
        GuiControl, , Counter%contNumEdit%, %number%
        number++
        contNumEdit++
		sleep 1000
    }
}
return

GuiEscape:
GuiClose:
    ExitApp
Top
swagfag
Posts: 4141
Joined: 11 Jan 2017, 17:59

Re: Excess of Goto to the same label?

Post by swagfag » 30 Nov 2020, 18:41

ive explained the nature of the error already: firing up too many pseudothreads without allowing them to finish.
u have a menu action button that clears a flag(condition) and a MsgBox confirmation button that sets it. the flag is evaluated at the very beginning of each outer while loop iteration(not when the flag is set, ie the instant u confirm the MsgBox), therefore it is still possible(due to the long sleeps u have coded into ur loop bodies) when u queue up a sufficient number of pseudothreads(by quickly opening new GUIs) to enter an "infinite"(lower bound 1000s, 16min) loop.
Top
Tulevik
Posts: 32
Joined: 03 Jul 2015, 11:56

Re: Excess of Goto to the same label?

Post by Tulevik » 30 Nov 2020, 23:18

Thanks for the explanation, I understand better now. I've just thought the destructions of the GUIs would kill the pseudothreatds.
Top
Post Reply

Return to “Ask For Help”