_Singleton() not working with v3.2.12.0 ?

[DasBo]

While migrating one of my tools to autoit version 3.2.12.0 I found that the _singleton() function doesn't work anymore. I can reproduce this even with the minimum example from the help file. The function seems to return 0 either if the application is started for the first time or if another instance is already running. With version 3.2.10.0 singleton works fine on the same machine.

Can you confirm this or am I the only one with this problem?

I'm using AutoIt on Vista SP1. The problem occurs with compiled and non-compiled scripts.

[ReaImDown]

While migrating one of my tools to autoit version 3.2.12.0 I found that the _singleton() function doesn't work anymore. I can reproduce this even with the minimum example from the help file. The function seems to return 0 either if the application is started for the first time or if another instance is already running. With version 3.2.10.0 singleton works fine on the same machine.

Can you confirm this or am I the only one with this problem?

I'm using AutoIt on Vista SP1. The problem occurs with compiled and non-compiled scripts.

your problem is solved here.... http://www.autoitscript.com/forum/index.php?showtopic=37289 ...last post.

[SadBunny]

/edit - sorry, thanks for answering question and urge me to read FAQ more often

Edited June 13, 2008 by SadBunny

[ReaImDown]

same solution work?

Edited June 13, 2008 by ReaImDown

[SadBunny]

same solution work?

Actually, no! The _Singleton("test\test",1) always returns 0 even if it is the first run (but it should say "the first occurence of test is running").

[ReaImDown]

Actually, no! The _Singleton("test\test",1) always returns 0 even if it is the first run (but it should say "the first occurence of test is running").

...try it again.... this works 4 me (remember the script needs to be compiled.)

If _MutexExists("test.exe") Then
; We know the script is already running. Let the user know.
    MsgBox(0, "Script Name", "This script is already running. Using multiple copies of this script at the same breaks the [(UltimaCoder)] License!")
    Exit
EndIf

Func _MutexExists($sOccurenceName)
    Local $ERROR_ALREADY_EXISTS = 183, $handle, $lastError
    
    $sOccurenceName = StringReplace($sOccurenceName, "\", ""); to avoid error
    $handle = DllCall("kernel32.dll", "int", "CreateMutex", "int", 0, "long", 1, "str", $sOccurenceName)

    $lastError = DllCall("kernel32.dll", "int", "GetLastError")
    Return $lastError[0] = $ERROR_ALREADY_EXISTS
    
EndFunc ;==>_MutexExists

while 1
    sleep(100)
WEnd

[SadBunny]

Yes, that works. Must be something different in what you did and what misc.au3 does... ?

Does the helpfile example work for you?

[SadBunny]

Yes, that works. Must be something different in what you did and what misc.au3 does... ?

Does the helpfile example work for you?

Figured it out (stupid I didn't see that earlier): seems that helpfile script was only tested when making, and not after placing in helpfile structure When you rename the _Singleton.au3 (which is opened when you 'open this script' from the helpfile) to test.au3 manually, then it works

[ReaImDown]

Yes, that works. Must be something different in what you did and what misc.au3 does... ?

Does the helpfile example work for you?

yes actually...just dont use test/test haha

#include "Misc.au3"
if _Singleton(@ScriptName,1) = 0 Then
    Msgbox(0,"Warning","An occurence of test is already running")
    Exit
EndIf
Msgbox(0,"OK","the first occurence of test is running")

[DasBo]

your problem is solved here.... http://www.autoitscript.com/forum/index.php?showtopic=37289 ...last post.

Thanks for the tip. _MutexExists() works.

But is there a reason, why _Singleton() doesn't work anymore with the new AutoIt version? At least not in the same way as in versions before 3.2.12.0?

[PsaltyDS]

Thanks for the tip. _MutexExists() works.

But is there a reason, why _Singleton() doesn't work anymore with the new AutoIt version? At least not in the same way as in versions before 3.2.12.0?

You haven't posted any code yet to indicate what doesn't work for you. The example in the help file is bad, as indicated earlier:

#include "Misc.au3"
if _Singleton("test\test",1) = 0 Then
    Msgbox(0,"Warning","An occurence of test is already running")
    Exit
EndIf
Msgbox(0,"OK","the first occurence of test is running")

The $sOccurenceName = "test\test" was a bad example as it attempts to use an invalid name space. If you simply replace that with "MyUniqueScriptIdString", or some such, it will work as advertised.

If your problem is not with the example script, please post a short script to demonstrate what doesn't work for you, in particular what kind of ID string you chose.

[DasBo]

The $sOccurenceName = "test\test" was a bad example as it attempts to use an invalid name space. If you simply replace that with "MyUniqueScriptIdString", or some such, it will work as advertised.

If your problem is not with the example script, please post a short script to demonstrate what doesn't work for you, in particular what kind of ID string you chose.

Yes, I tried with the unchanged help file example. I didn't notice, that this is related to name spaces. Without backslashes it works now.

BTW: Is there any complete documentation of compatibility breaking changes from version 3.2.10.x to 3.2.12.0? I have no problems with function names changing, because syntax errors can be found easily. But changing order and function/meaning of arguments is a real pain without documentation. How can I ever be sure, that my tools don't produce runtime errors with the new version?

[DaveF]

BTW: Is there any complete documentation of compatibility breaking changes from version 3.2.10.x to 3.2.12.0?

If you'll go to the AutoIt3 help file, top of the Contents, History/Changelog, and click the 'script-breaking changes' link you'll see what the developers anticipated might cause problems with existing scripts.

How can I ever be sure, that my tools don't produce runtime errors with the new version?

You can compile your scripts using versions of the AutoIt binaries that were known-good when the script was designed, and/or you can have a test environment for your scripts to try new versions of the AutoIt binaries before adopting them.

AutoIt is great in part because it's a non-invasive all-in-one tool, but it isn't exempt from the Best Practices that one would use for any other software product.

[DasBo]

If you'll go to the AutoIt3 help file, top of the Contents, History/Changelog, and click the 'script-breaking changes' link you'll see what the developers anticipated might cause problems with existing scripts.

You can compile your scripts using versions of the AutoIt binaries that were known-good when the script was designed, and/or you can have a test environment for your scripts to try new versions of the AutoIt binaries before adopting them.

AutoIt is great in part because it's a non-invasive all-in-one tool, but it isn't exempt from the Best Practices that one would use for any other software product.

Of course I read the warning on top of the change log. Scanning all my scripts for the mentioned functions and keywords was the easy part... After that I tried to compile the scripts and solved all the syntax errors for changed GUI function names. That was kind of easy too. But the real annoying part came, when I realized that the order of arguments for several functions changed and sometimes even the meaning of arguments. This was no fun at all, because after installing the new version, the old help files were gone too and I couldn't easily compare old and new syntax.

Until now, I'm not sure, if there are any "time bombs" left in my bigger scripts like the change of interpretation of the _Singleton() argument, that is documented nowhere in the change log. I hope, there will be no further of these (undocumented) compatibility breaking changes in the autoit language for the next few years...