The same variable cannot be used for more then one control

[DataLife]

A user of one of my programs is getting this error. The same variable cannot be used for more then one control

I can not reproduce this error.

If I had not seen the screenshot I would have said this is absolutely not possible due to "IfWinExist,ahk_id %MDPID%"

Code: Select all

ShowGui:
IfWinExist,ahk_id %MDPID%
 {
  WinActivate, ahk_id %MDPID%
  return
 }
;this is a sample gui
Gui 1: Add, Radio, vAssociatedVariable1, 1st Sample Radio button
Gui 1: Add, Radio, vAssociatedVariable2, 2nd Sample Radio button
Gui 1: Add, Radio, vAssociatedVariable3, 3rd Sample Radio button
Gui 1: show, autosize, Autohotkey Window
WinGet, MDPID , ID,  Autohotkey Window
return 

He chooses from the system tray icon to show the "Autohotkey Window"
When he got this error, I tried "Gui 1: destroy" instead of "IfWinExist,ahk_id %MDPID%" so that the window, if it existed, would be destroyed before trying to show it again. He still got this error.
I verified the id MDPID is correct.
The associated variable is used only 1 time in my entire script
There are no labels between the label ShowGui and the return after Gui 1: show, which would allow a goto or gosub to bypass the "IfWinExist,ahk_id %MDPID%" or "Gui 1: destroy"
There are no if statements like

Code: Select all

if Var1 = 0
 Gui 1: Add, Radio, vAssociatedVariable1, Sample Radio button
if Var1 = 1
 Gui 1: Add, Radio, vAssociatedVariable1, Another Sample Radio button

To add to the what seems impossible is that most of the time it refers to the first associated variable "AssociatedVariable1" but one time it referred to the 3rd "AssociatedVariable3". How could it bypass the 1st and 2nd associated variable and error on the 3rd?
Just completely makes no sense that the Gui 1: destroy before showing the Gui did not fix the issue. Could maybe the 1st associated variable was trying to be used before Gui 1: destroy could finish destroying the window. But that does not explain why "IfWinExist,ahk_id %MDPID%" allowed an attempt to create the 1st associated variable a second time, or it skipping the first 2 associated variables and erroring on the 3rd.

Also, this error is intermittent.

I have at least 50 people using this script. He is the only one having this issue.

I have not posted this script on the Autohotkey forum.
My script is over 5500 lines. The complete script is here https://sourceforge.net/projects/networkawareprinting/files/AutohotkeyDotCom/NetworkAwarePrinting.ahk/download
The EXE and AHK files are here https://sourceforge.net/projects/networkawareprinting/files/

The ahk can be run by itself but the "Check For Updates" will not work. The exe allows for updating the script, by downloading files from source forge.
Just want to add this information in case anyone downloads the ahk and attempts to run it.

Please give me suggestions on what is causing this.

Thanks
Datalife

[mikeyww]

Hello,

This problem occurs when the line executes when the same variable has already been declared for an existing control. In most cases, this happens when the same line executes twice, but if the line is duplicated elsewhere, or just same variable duplicated elsewhere, this could happen.

With this information in hand, the problem is typically straightforward to troubleshoot. You already know the exact line number of the problem. Chances are high that this line executes twice due to a loop or other control flow. You are able to track the lines that execute in your script through various means. Thus, you need only determine when the line executes a second time. This can usually be done by backtracking through your script, logging lines, using ListLines, informational displays, or one of the available debugging tools. If needed, shorten and simplify the script so that you can isolate the problem.

If you do not believe that your problematic line is ever reached twice, you can confirm that very quickly by preceding the line with a MsgBox command.

IfWinExist is quite an old statement at this point that has been deprecated in all of the most recent versions of AutoHotkey v1. This statement is not recommended for use in new scripts. Use the WinExist function instead. I am just reciting what the documentation already reports.

For troubleshooting, determining whether a window exists requires no If statements. You can simply display the value returned by the WinExist function. At the moment, you also have no idea what MDPID is.

You would probably never want to have code in your script such as if Var1 = 0, because it contains no parentheses, which are recommended in specifying expressions of an If statement.

When I debug a script, I do not spend a lot of time thinking about what I believe, what I think is possible, or what makes sense. Instead, I use the script itself to tell me what the script is doing. This points to the problem and the answer. It is also quite a bit faster.

I reproduced the error by adding two lines to your script.

Code: Select all

#Requires AutoHotkey v1.1.33.11

ShowGui:
If WinExist("ahk_id" MDPID) {
 WinActivate
 Return
}
Gui 1:Add, Radio, vAssociatedVariable1, 1st Sample Radio button
Gui 1:Add, Radio, vAssociatedVariable2, 2nd Sample Radio button
Gui 1:Add, Radio, vAssociatedVariable3, 3rd Sample Radio button
Gui 1:Show, AutoSize, Autohotkey Window
WinGet MDPID , ID,  Autohotkey Window
MDPID := 0
Gosub ShowGui
Return

When I use GUIs, I almost always build them in the auto-execute section. You can then show or hide the GUI without rebuilding it repeatedly. In a few cases, there is a good reason to destroy a GUI and rebuild it. The GUI might be part of a function, it might need to change in ways that would be difficult to achieve without rebuilding it, and so on. When you build your GUI only once, you typically prevent the bug that your script contains.

By default, clicking the GUI's "X" will hide the GUI. When a window is hidden, it exists but is not seen by WinExist unless you have enabled the detection of hidden windows.

Code: Select all

#Requires AutoHotkey v1.1.33.11
ShowGui:
If WinExist("ahk_id" MDPID) {
 WinActivate
 Return
}
Gui 1:Add, Radio, vAssociatedVariable1, 1st Sample Radio button
Gui 1:Add, Radio, vAssociatedVariable2, 2nd Sample Radio button
Gui 1:Add, Radio, vAssociatedVariable3, 3rd Sample Radio button
Gui 1:Show, AutoSize, Autohotkey Window
WinGet MDPID , ID,  Autohotkey Window
Return

F3::
; DetectHiddenWindows On
MsgBox % MDPID
MsgBox % WinExist("ahk_id" MDPID)
Return

Your bug very likely lies there: failing to detect the window properly when it is hidden, such as when the user has already hidden the GUI. You attempt to determine whether the window exists. Although it does exist, WinExist returns 0, so your GUI commands are executed a second time.

Interesting that this seems to work differently in AHK v2.

A way to fix the issue when needing to rebuild is via "New".

Code: Select all

#Requires AutoHotkey v1.1.33.11
Gosub F2

F2::
ShowGui:
Gui 1:New, +HwndMDPID
Gui Add, Radio, vradio, 1st Sample Radio button
Gui Add, Radio,       , 2nd Sample Radio button
Gui Add, Radio,       , 3rd Sample Radio button
Gui Show, AutoSize, Autohotkey Window
Return

F3::
MsgBox % MDPID
Gui 1:Submit
MsgBox % radio
Return

Simplified:

Code: Select all

#Requires AutoHotkey v1.1.33.11
Gui Font, s10
Gui Add, Radio , w300 vradio, 1st Sample Radio button
Gui Add, Radio , wp         , 2nd Sample Radio button
Gui Add, Radio , wp         , 3rd Sample Radio button
Gui Add, Button, wp Default , OK

F2::Gui Show,, Autohotkey Window

ButtonOK:
Gui Submit
MsgBox 64, Selected radio button, % radio
Return

[DataLife]

Thanks for the quick reply, and thanks for the troubleshooting suggestions.

I can reproduce the error, just like you did. But I can not reproduce the error the way my script is written. I have to work with a guy 2 states away that knows nothing about autohotkey to troubleshoot.

I have been coding with Autohotkey since 2008. I know there are better ways of coding.

You mentioned a loop, this Gui is not in a loop.

I have no problem using WinExist function. I wrote this script in 2017. I am not going to go back and rewrite my scripts because the documentation says something is depreciated. Unless the command that is depreciated is causing problems.

Making MDPID equal 0 gives me an idea that something is overwriting MDPID, but this would not explain Gui 1: destroy before I recreate the gui.

If I were to create, hide, update, show this gui I would need to update 2 dropdown controls first. Which I suppose would mean to delete its contents, then recreate the contents then update the controls. I am already recreating the contents of those controls before creating the gui, so it may not be to difficult.

Even if I did hide, update and show this Gui, it would not help me figure out how this error is happening.

I am destroying the Gui when the X is clicked.

Code: Select all

GuiClose:
Gui 1: destroy
return

You said ""determining whether a window exists requires no If statements

Please give me an example how to use WinExist without an if statement to determine if a certain window exists.

Here is my shot at it, but I am still using an If statement to determine if the window exist.

Code: Select all

UniqueID := WinExist("ahk_id" MDPID)
if UniqueID = 0
 MsgBox Window does not exist
else
 MsgBox Window does exist

is if Var1 = 0 using an expression?

Code: Select all

 if Var1 = 0, because it contains no parentheses, which are recommended in specifying expressions of an If statement.

I use parentheses with expressions many times in my scripts. Including this script.

I do have DetectHiddenWindows On at the top of my script.

I need to think if ways to troubleshoot with a person that has no autohotkey or programming knowledge. He says he is not trying to open the Gui when it is already open, which Gui 1: destroy would take care of that anyway.

I have added a hotkey that writes Listlines to a text file. I will ask him to use the hotkey when the error is on the screen and email me the text file.
I like your idea of Gui 1:New, +HwndMDPID, I will try that.

thanks
DataLife

[just me]

Moin @DataLife,

one 'special' AHK v1 option to solve this special problem without using a window ID/HWND:

Code: Select all

ShowGui:
Gui 1:+LastFoundExist
IfWinExist
 {
  WinActivate
  return
 }
;this is a sample gui
Gui 1: Add, Radio, vAssociatedVariable1, 1st Sample Radio button
Gui 1: Add, Radio, vAssociatedVariable2, 2nd Sample Radio button
Gui 1: Add, Radio, vAssociatedVariable3, 3rd Sample Radio button
Gui 1: show, autosize, Autohotkey Window
return 

[mikeyww]

Your subroutine can be executing twice. How could it happen? I went to your script and noticed that you inserted the following comment.

ShowGui: ;this can get called via the "Invalid Default Printers" and by selecting "Open Nework Aware Printing Menu" from the system tray.

If the user can select a menu option that calls your subroutine, then perhaps the user can do this more than once.

I have provided you with, potentially, a one-line fix for your bug. just me has done the same.

As I mentioned, a simple MsgBox before adding the controls quickly confirms whether the line executes multiple times-- the way your script is written. Your logging idea is also OK. If helpful, your script can display the HWND of the GUI, or can use just me's technique. I am not sure whether you have conducted that test.

An example of using the value returned by WinExist is below. It is not required. This just shows that you can display the value if you wish.

Code: Select all

#Requires AutoHotkey v1.1.33.11
Gui +HwndMDPID
Gui Add, Text, w230, Test
Gui Show,, Test
MsgBox % WinExist("ahk_id" MDPID)

You have mentioned the "Destroy" line. I think that you will need to do some real-world debugging in coordination with your user. This could involve sending them a test script that has a few of the debugging lines added (perhaps you have already done this). The additions to the script will require about 15 minutes. The testing can then be done at each end. Some commercial software includes similar configuration options that will create logs used for debugging.

[DataLife]

Moin @DataLife,

one 'special' AHK v1 option to solve this special problem without using a window ID/HWND:

Code: Select all

ShowGui:
Gui 1:+LastFoundExist
IfWinExist
 {
  WinActivate
  return
 }
;this is a sample gui
Gui 1: Add, Radio, vAssociatedVariable1, 1st Sample Radio button
Gui 1: Add, Radio, vAssociatedVariable2, 2nd Sample Radio button
Gui 1: Add, Radio, vAssociatedVariable3, 3rd Sample Radio button
Gui 1: show, autosize, Autohotkey Window
return 

thanks just me for the suggeston, I will try +LastFoundExist

[DataLife]

Your subroutine can be executing twice. How could it happen? I went to your script and noticed that you inserted the following comment.

ShowGui: ;this can get called via the "Invalid Default Printers" and by selecting "Open Nework Aware Printing Menu" from the system tray.

If the user can select a menu option that calls your subroutine, then perhaps the user can do this more than once.

I have provided you with, potentially, a one-line fix for your bug. just me has done the same.

As I mentioned, a simple MsgBox before adding the controls quickly confirms whether the line executes multiple times-- the way your script is written. Your logging idea is also OK. If helpful, your script can display the HWND of the GUI, or can use just me's technique. I am not sure whether you have conducted that test.

An example of using the value returned by WinExist is below. It is not required. This just shows that you can display the value if you wish.

Code: Select all

#Requires AutoHotkey v1.1.33.11
Gui +HwndMDPID
Gui Add, Text, w230, Test
Gui Show,, Test
MsgBox % WinExist("ahk_id" MDPID)

You have mentioned the "Destroy" line. I think that you will need to do some real-world debugging in coordination with your user. This could involve sending them a test script that has a few of the debugging lines added (perhaps you have already done this). The additions to the script will require about 15 minutes. The testing can then be done at each end. Some commercial software includes similar configuration options that will create logs used for debugging.

Anytime, any gui is displayed via the system tray icon, or by a control on a gui (button), the attempt is still there. That is why for 15 years with all of my scripts I have used...

Code: Select all

IfWinExist,ahk_id %MDPID% ;with the correct id for that gui
{
  WinActivate, ahk_id %MDPID%
  return
 }

This code should prevent the Gui from being shown twice. The only thing I can think of is the id MDPID is being changed, but the Gui 1: destroy should have released any associated variables before recreating the Gui.

I know hiding, updating and showing the Gui will fix the issue and I plan on doing that. But I know from experience, I probably will miss some updating the Gui while it is hidden. My script is over 5000 lines and I wrote it 7 years ago. So I will cause unexpected bugs. I think I should be able to just take the code above the gui that pulls all the information that I need for the gui and turn it into an "updating gui" and run it before unhiding the Gui.

[DataLife]

One more thing that makes no sense and probably is user testing error.

This user has always used my compiled exe.

I did not know, but he also uses autohothey. He has version 1.3 installed.

I just telling what he said.

He can reliably reproduce the intermittent error by using the tray icon to show the gui, but when he "exits autohotkey", the error goes away. He can no longer reproduce the error.

I don't know what he means by "exit autohotkey". I asked him if he means he uses the task manager and end the autohotkey task, I am waiting on his reply.

I told him to keep testing or just let me know when it happens again.

I have over 50 people using this program and no one has reported this issue.

He may be the only one using Autohotkey and my program, other then me.

I could let him use the uncompliled ahk file, but the check for updates and updating the program would no longer work. And I don't know what that tells me if this issue goes away.

I am still baffled why Gui 1: destroy does not release the associated variables before attempting to recreate the gui.

[DataLife]

@mikeyww

I did try your suggestion

Code: Select all

Gui 1:New, +HwndMDPID

The user still got the same error.

I will try just me's suggestion.

thanks
Robert

[mikeyww]

I have already suggested that you display the MDPID, but I don't think you have done it yet. Or, also as mentioned, you can insert a single MsgBox line before the GUI control is added.

You need not wonder about what will happen. You can determine it by testing!

I personally would not care whether you have a million users of your script. A bug is a bug, and some occur only under specific conditions that might not be common. You can also ask your user to create a short video of their experience, so that you can visualize it yourself. You also need to see a screenshot of the error message.

[DataLife]

I have already suggested that you display the MDPID, but I don't think you have done it yet. Or, also as mentioned, you can insert a single MsgBox line before the GUI control is added.

You need not wonder about what will happen. You can determine it by testing!

I personally would not care whether you have a million users of your script. A bug is a bug, and some occur only under specific conditions that might not be common. You can also ask your user to create a short video of their experience, so that you can visualize it yourself. You also need to see a screenshot of the error message.

I do have a screenshot.
Here is the one that skipped the first two assocated variables and errored on the 3rd (vWhichChecked3). It skipped vWhichChecked1 and vWhichChecked2

I put img tags around the url to the image but it does not show in the preview.


Here is a link to the image.
https://mega.nz/file/wgE0yYzb#bUBfmU7M9gUSWOPGxV6OFIdW8AqSiyNILwJPBdwNNTc

I have no issue displaying the MDPID, what should I do with it after I display it?

I will add a msgbox. Should I ask my user to tell me if the msgbox shows up twice before the Gui shows?


thanks for your help
DataLife

[mikeyww]

Yes, I think that those are the right ideas to get started.

Can a control ever be added twice if a Destroy command always precedes the Add? The script below shows how a specific sort of timing can throw the error even in that situation. If your user simulates this timing in relation to your script, the result might be the same.

Code: Select all

#Requires AutoHotkey v1.1.33.11
#Persistent
iteration := 0
SetTimer Go, -200
Show:
Gui 1:Destroy
Sleep 900
MsgBox % ++iteration
Gui 1:Add, Text, vabc
Return

Go:
Gosub Show
Return

Error message

AutoHotkeyU64240426-1539-001.png (14.66 KiB) Viewed 475 times

Shortening and simplifying your script would help your troubleshooting and make it happen more quickly.

As already noted, building the GUI a single time instead of repeatedly is often a fast and simple solution to this issue.

[just me]

Moin @DataLife,
I agree with @mikeyww. The error will most probably occur when the ShowGui label continues with creating controls after being interrupted by a second call which already created the GUI. In this case my suggestion will also not work. You can try to add Critical at the top of the subroutine to prevent interruption. But you better prevent the attempt to interrupt it.

BTW: You should not 'call' subroutines outside of the current one using Goto.

[DataLife]

Yes, I think that those are the right ideas to get started.

Can a control ever be added twice if a Destroy command always precedes the Add? The script below shows how a specific sort of timing can throw the error even in that situation. If your user simulates this timing in relation to your script, the result might be the same.

Code: Select all

#Requires AutoHotkey v1.1.33.11
#Persistent
iteration := 0
SetTimer Go, -200
Show:
Gui 1:Destroy
Sleep 900
MsgBox % ++iteration
Gui 1:Add, Text, vabc
Return

Go:
Gosub Show
Return

AutoHotkeyU64240426-1539-001.png


Shortening and simplifying your script would help your troubleshooting and make it happen more quickly.

As already noted, building the GUI a single time instead of repeatedly is often a fast and simple solution to this issue.

I now understand. The 2nd attempt at showing the gui is happening before the 1st attempt has completed.
I am going to rewrite all my guis to show once, hide, update then unhide.

I hope they get the forum lag fixed. It is so time consuming doing anything on the forum.

thanks just me and mikeyww for your patience.