new macro

[w0uter]

gets the current PID and stores it in the macro @PID.

dim $ai_GetCurrentProcessId = DllCall('kernel32.dll', 'int', 'GetCurrentProcessId')
Assign("@PID", $ai_GetCurrentProcessId[0], 2)
$ai_GetCurrentProcessId = ''

also i was wondering if i could DELETE the variable ($ai_GetCurrentProcessId) COMPLETELY.

Edited July 9, 2005 by w0uter

[LxP]

also i was wondering if i could DELETE the variable ($ai_GetCurrentProcessId) COMPLETELY.

You could put those lines into a function and declare the variable locally; the variable then wouldn't exist after the end of the function. This is what I do when I don't want a bunch of useless variables hanging around.

Just out of interest, why would you want to completely remove the variable? I'm guessing for memory reasons perhaps but I can't imagine that a variable would take up all that much memory.

[w0uter]

if someone would use this.

and wanted to use IsDeclared().

it would come up as 1.

i want it to come out as 0 so the only remains of my snippet are @PID.

i tried storing the array from DLL call in @PID first.

but autoIt cant handle array-macro's.

[LxP]

if someone would use this.

and wanted to use IsDeclared().

it would come up as 1.

i want it to come out as 0 so the only remains of my snippet are @PID.

I see what you mean now and understand why the idea of a function to remove variables from memory seems good; it probably would be better coding practice not to handle a variable that way though.

Functions not only offer the ability to prevent unnecessary variables from remaining in memory but they also guarantee that if the caller of the function has a variable of the same name, it won't be destroyed. In my opinion a method to remove variables in this way could be likened to the dreaded GOTO instruction -- there are other ways to achieve the same effect and they are much more intuitive.

[FuryCell]

Cool. I think you should change the macro name to somthing more descriptive like @AutoItPID though. You should put a post in the idea lab for this to be added as a built in macro as it is a very useful one because it is needed in certain DllCalls().

[Valik]

w0uter, the fact that you can use Assign() in this manner is a bug and will be fixed. I was trying to wait until I had made some other changes to Assign() before introducing the fix, but I see now that people want to try to exploit the bug so it'll be fixed within the next version or two with the rest of the changes coming later.

I do agree that the PID should be available as a macro, though.

[blindwig]

Cool.    I think you should change the macro name to somthing more descriptive like @AutoItPID though. You should put a post in the idea lab for this to be added as a built in macro as it is a very useful one because it is needed in certain DllCalls().

<{POST_SNAPBACK}>

How about @ScriptPID, to go with the convention of @ScriptName, @ScriptDir, etc

[FuryCell]

How about @ScriptPID, to go with the convention of @ScriptName, @ScriptDir, etc

<{POST_SNAPBACK}>

That sounds good too but I thought @AutoItPID is better because it goes with @AutoItEXE and if the script is not compiled it will not be the PID of the script (as it would not have one.) but actually the PID of AutoIt3.exe

[w0uter]

w0uter, the fact that you can use Assign() in this manner is a bug and will be fixed.  I was trying to wait until I had made some other changes to Assign() before introducing the fix, but I see now that people want to try to exploit the bug so it'll be fixed within the next version or two with the rest of the changes coming later.

I do agree that the PID should be available as a macro, though.

<{POST_SNAPBACK}>

aww

cant you just see this as an "unintended" functionality,

like as an array in an array ? and keep it ?

[Valik]

aww 

cant you just see this as an "unintended" functionality,

like as an array in an array ? and keep it ?

<{POST_SNAPBACK}>

No.

[layer]

Oh yea, I remeber talk of the Assign exploit, can't remeber where ...