|
|
|||||||
Here is another Bug in 4.60 : Just make a script with the following two lines for example: $ffx = DelTree("HKEY_LOCAL_MACHINE\Software\Mozilla\Mozilla Firefox abc") exit @error The result: failed to find/open script ... with 4.53 and earlier all works fine. comment: As I can see 4.60 has lots of bugs. Itīs more a beta-version than a full release. |
||||||||
|
|
|||||||
I think you've got a syntax error somewhere. That error usually only happens if you mistype the name of the script, or if you are calling another script and it's path\name is incorrect. |
||||||||
|
|
|||||||
Using your example with a few changes, it appears to be working as expected. @serror is returning the correct error that the registry key does not exist (at least on my machine). Code: ? @kix $ffx = DelTree("HKEY_LOCAL_MACHINE\Software\Mozilla\Mozilla Firefox abc") ? @serror Produces Quote: 4.60 The system cannot find the file specified. 4.53 The system cannot find the file specified. |
||||||||
|
|
|||||||
1. The problem is not if the key exists or not. you can write $ffx = DelTree("HKEY_LOCAL_MACHINE\Software\Mozilla\blabla") exit @error and save it to "testbug.kix" too. When opening under 4.53 all works, in 4.60 there comes: "ERROR : failed to find/open script [testbug.kix]!" (Tested under Windows 2000) 2. You are right with your possible solution: when I change exit @error to exit @serror then it works in 4.53 and in 4.60 too. 3. The problem is, that if I want to use 4.60 I have to change the scripts, because some commands could effect some things like the described. 4. Result: Commands which have no problems in 4.53, now could have problems in 4.60. Thats a risk which it is not necessary to have. |
||||||||
|
|
|||||||
Your problem is likely to be the value being returned in @ERROR. What is happening is that the API is returning either a negative value, or a very large unsigned integer which appears to be negative when stored in a signed data type. If you pass a negative value to "Exit" it will cause the missing script error - KiXtart has done this for as long as I can remember. You can create a very simple test script with "Exit -1234" which will exhibit the same error. If you display the value of @ERROR you will probably find it is negative. The solution is to cast @ERROR to a non-negative integer if you want to use it when exiting the script. If you use Exit with a negative value internally in a script there is no problem and the value is preserved. It is only a problem when exiting KiXtart. |
||||||||
|
|
|||||||
@richard h. You are mostly right. I made some tests with the following results: 1. Script #1: ? @kix $ffxdel = deltree ("HKEY_LOCAL_MACHINE\Software\Mozilla\blabla\") ? @error exit @error result kix4.53: 4.53 2 result kix4.60: 4.60 2 ERROR : failed to find/open script [testbug1.kix]! 2. Script #2: ? @kix exit -123 result kix4.53: 4.53 ERROR : failed to find/open script [testbug2.kix]! result kix4.60: 4.60 3. Script #3: ? @kix exit 123 result kix4.53: 4.53 result kix4.60: 4.60 Script #4: ? @kix exit 2 result kix4.53: 4.53 result kix4.60: 4.60 ERROR : failed to find/open script [testbug4.kix]! 5. comment: in #1 all returns are positive, but with 4.60 there is an errormessage on exit. in #2 the value is negative, 4.53 react as you described with an errormessage, but 4.60 exit without an errormessage! in #3 the exit value is positive, 4.60 and 4.53 works fine. in #4 the value is 2, but with 4.60 there is an errormessage on exit (like in #1). The results in #1 and #2 with 4.60 and 4.53 are conversely and contradictory. There could be a problem with some values with the exit-command. |
||||||||
|
|
|||||||
I tested some more values on exit [value] It seems that the value "2" is the only one with the problem in kix4.60 |
||||||||
|
|
|||||||
Actually, I think this IS a bug.. Code: Break On @KIX ? Exit 2 exits silently with earlier versions, but with 4.60: Code: WORKSTATION - C:\temp>kix324.60 x.kix 4.60 ERROR : failed to find/open script [x.kix]! WORKSTATION - C:\temp>Echo %ERRORLEVEL% 0 WORKSTATION - C:\temp>kix324.53 x.kix 4.53 WORKSTATION - C:\temp>Echo %ERRORLEVEL% 2 As you can see, only 4.60 returns the error to the console. Oddly, it also eats the return code - the command session sees 0 as the exit code, not 2. Glenn |
||||||||
|
|
|||||||
kix32.exe 4.60 always showing errorlevel 0 for non existant scripts was documented here: http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=181759#Post181759 Maybe same cause? |
||||||||
|
|
|||||||
The point was that a simple script with the single line "exit 2" behaves differently between Kix 4.53 and 4.60. The script, as you see, is executing (displaying the Kix version) but when exiting with "Exit 2", kix 4.53 (and earlier) exit without any message, and properly set the errorlevel. Kix 4.60 does not. This has nothing to do with finding a script, or setting errorlevel if a script is present or not. It's solely related to how Kix now (and differently) processes an Exit 2 command. Glenn |
||||||||
|
|
|||||||
Good call, something's wrong here. I will investigate. Ruud |
||||||||
|
|
|||||||
Just to confirm: bug found and fixed in the next build. Ruud |
||||||||
|
|
|||||||
I can confirm that 4.61 resolves this issue - thanks! Glenn |
||||||||
|
|
|||||||
lol. had to stare the dates for a moment. talk about old thread. |
||||||||
|
|
|||||||
I tested. This bug is really fixed in 4.61b1 |