AutoHotkey Community

I noticed the shorthand assign operators don't seem to work for objects. Here's an example of what I mean for Concatenate:Agreed - & a solution could be to have object libraries that come with the AHK download ( or a listing of libraries & URL ). IMO however, if AHK is seeking to be noobie-friendly, a built-in array object is more important than a built-in file object.

_________________

Recommended: AutoHotkey_L
Basic Webpage Controls

nice
this WHILE thing used to be in AutoIt
thx for the update in AHK

The code for getting a path of an explorer window as shown in this post works perfectly in AutoHotkey.exe but fails to run correctly in AutoHotkey_L. It returns what looks like a garbage string rather than the folder name.

The code is basically just a bunch of DLL calls and a SendMessage. I would think this should work fine in AutoHotkey_L. Any idea what might be the issue here?

I'm on Windows XP, btw.

In that case, meta-functions would need to be extended I think.
You would need to know what operation is being performed, so there would be __Add, __Sub, __Concat, __Mult, __Div...
Why would a build in array be more user friendly?


Use Unicode version, I wonder why it is not used automatically

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

Thanks, it works.

I'm guessing the only way to get the call to work for both AutoHotkey and AutoHotkey_L then, would be to use an IF statement and examine the A_IsUnicode variable to determine which one is running?

Shell32.dll exports "SHGetPathFromIDList" in addition to "SHGetPathFromIDListA" and "SHGetPathFromIDListW".
That, or use the ANSI build of AHK_L.
Right, they currently require a variable to be on the left-hand side. obj[1] is evaluated and its return value used in the assignment (obviously that won't work).
Why? IMO, if obj[1] contains a string, obj[1] .= "Hotkey" should act like any other concatenation. Otherwise obj[1] . "Hotkey" would also need to call a meta-function for consistency, but that would be rarely useful and would complicate all of the supported operators.
No. What features should it have? FYI, Object started out as just an associative array.
While was integrated into the official AHK release over a year ago...

But obj[1] . "string" does already call meta-function __Get and that is alright.
When obj[1] .= "string" would be implemented, meta-function would need to know that you are trying to concatenate and not __Set, otherwise it would be confusing and you would get unexpected results, the same for the other operators like +=, *= ...

So are there any plans to support any other operators than :=

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

How does that support your argument?
obj[1] retrieves a value and . "string" concatenates that value with a string. This works intuitively, without obj ever being aware that a concatenation is to be performed. obj[1] .= "string" requires only one extra, independent step: pass the result back into obj[1], as in:
Allowing or requiring the object to handle each operation (concatenation, addition, subtraction, etc.) is more likely to cause confusion and unexpected results, especially if the assignment operators are allowed to behave differently to their non-assignment equivalents.
Nothing beyond what has been discussed.

I agree, sorry for any confusion

_________________
AHK_H (2alpha) AHF TT _Struct WatchDir Yaml _Input ObjTree RapidHotkey DynaRun

Just want to say: Lexikos thank you for AutoHotkey_L!

I am having an issue and I can't figure out how to make it work with AHK_L.

Say I have a function where I pass the HWND of a window as a parameter. I then want to store information for the window such that each variable name becomes the HWND + my text.

So if HWND := 0x1234

My variable would be 0x1234WinX

Example:



Now I want to be able to access these variable names i.e.



This works with AHK before _L, and I am wondering what I need to change to get it to work with _L.

Thanks

That works with AHK_L. You probably have some other kind of a problem. I use similar things in almost all my modules. If I execute your code I get in ListVars:



BTW, if you happen to obtain negative Hwnd the code will break. Such Hwnd could be get by using DllCall without specifying UINT as return value.

On related note, its better to use object for such things in AHKL:

_________________

Is these a unknown problem with Autohotkey_L? Please have a look into my post from today in this thread: http://www.autohotkey.com/forum/topic10393.html

Thanks for your great work...

A known problem, if you use ansi but should use unicode version of the functions.

_________________
http://securityvision.ch
AHK 2D GAME ENGINE

Has anything changed about ImageSearch with AHK_L? I have to use an ImageSearch command to tell when a Citrix application is ready to use; in plain vanilla AHK it works fine, but AHK_L (Unicode) never detects the image. Here's the command I use:

_________________

Try Quick Search for Autohotkey or see the tutorial for newbies.