AutoHotkey Community

Sorry Lexikos, I just asked the question ... to know. I didn't seen the "Ancient history"? Appologies. Thanks for your answer.

Seeing the recent wish about #includes reminded me about environmental variables in paths ( #include %UTILS%\Scripts\script.ahk ) ? Would you consider it ? Its very useful for script portability.

_________________

While we're at it, why not an #includefolder ?

I recently posted a wish / implementation for wildcards in #include.
This allows including folders recursively as well.
I pretty much butchered a copy of the code from Line::PerformLoopFilePattern.
But i can clean it up, if there is a chance Lexikos would consider including this feature...

@Lexikos:
Do you plan to make an installer for AHK_L unicode? I would like to uninstall mainstream AHK and install your upgrade.
IMO, the time has come to abandon mainstream AHK and use AHK_L unicode.

Yes, but it's not a high priority and therefore probably won't get done soon.

It seems as though with the lack of updates to Standard AHK, your version is getting quite a bit of attention in the AHK community. Thank you for the continued efforts . Out of curiosity, do you keep a list of update priorities/planned updates? If so, do you have them posted anywhere, or would you?

_________________

Recommended: AutoHotkey_L
Basic Webpage Controls

I have some rough notes, nothing that I'd be willing to post. To be honest, anything that isn't an immediate priority has no firm priority and isn't likely to be done soon.

Hey Lexikos,

In the "How to compile.txt" text file, it says that you compile AHK_L with VC 2008, but I see that you also have a solution file in VC 2010. Is there a difference in the release build of AutoHotkeyx.sln compared to AutoHotkey.sln?

There may be minor differences in the configuration. Merely compiling with 2010 vs 2008 gives different results. AutoHotkey.sln is provided only for those still using 2008, as I've moved to 2010. I'll probably remove it as it's a bit of a hassle maintaining two sets of solution/project files.

Why don't u just include my bat installer or something similar. IMO full installer for AHK isn't all that important. Batch script is enough.

People need only to extract archive to folder of choice and run it as admin (on any computer they copy the folder afterwards)

_________________

Hi, first of all thanks for AHK_L, a great masterpiece !

Well since I started to update a few of my older scripts to work with Unicode, I stumbled upon a problem with encrypting unicode strings with characters above the ascii range. The solution was to encode the string into utf7 first and then to convert back into utf16 so ahk_l could use the string (see working example here)! That way the encryption function didnt need a rewrite. Now I expanded upon this idea and run into an odd bug (?) / behaviour:



Small description of sample code and problem:
It takes a string and encodes it with winapi calls into utf7 (and since this is an ansi string, and therefore not useable with ahk_l it has to be converted back into utf16!). The first 2 msg boxes show that the conversion into utf7 worked and that it is in fact an ansi string now, not an unicode encoded string. Then this ansi string is converted into its utf16 equivalent. The 3rd msgbox is a bit odd since I expected an empty one since the first character should be a zero-terminator (since "H" is 0x0048 in utf16), so i have no clue why it shows the "H" at all! But the 4th msgbox shows that the utf7 string was "transformed" into utf16, and the 5th msgbox is unexpectly empty (it should show the same contents as msgbox #4). The final msgbox shows as expected "111" for the second line (well since this is part of a larger piece of code, the "111" is just an example of some number calculations resultion from the string that are neede later!), but an empty 3rd line (kind of expected since msgbox #5 was empty as well)!
Here is now the oddest part: If I uncomment the 2 lines the final msgbox shows the "111" for the 3rd line (expected) but the 2nd line shows the correct utf16 string for the utf7-encoded string ??????

So how can a return statement make a variable "useable", that a previus MsgBox command could not display ??? Is it something I'm missing, or do I have some kind of missconception of how Unicode is handled ??

And Yes I do know of StrPut / StrGet, but as said it is part of a larger code, which is aimed to work on both vanilla ahk and ahk_l (meaning I'm resticted to winapi for these conversions), and the part for vanilla ahk works flawless.

As shown i can work around this by using the return method and store the calculation result in the byref variable, but this kinda defeats the purpose!

I hope someone can shed some light into this!

Your conversion is flawed to begin with - you are converting a UTF-16 string into UTF-7, then reinterpreting the data as ANSI and converting the "ANSI" string to UTF-16.
What would you use it for? There should be no issue passing a UTF-7 string around as long as it is terminated with a Unicode NULL character (for instance, "abcd\0\0" or "abc\0\0\0"; it must be aligned correctly).
"8-bit" and "ANSI" are two different things. It is not an ANSI string.
Windows uses little-endian byte order, so 0x0048 becomes 0x48,0x00.
When you write to a variable using "UInt",&Var, the variable's internal length field is not updated. Use "Str",Var or VarSetCapacity(Var,-1).
'Return' causes the variable's internal length field to be ignored, instead using the null-terminator.
I guess you didn't know of StrPut / StrGet for vanilla AHK. I've just fixed non-UTF-16 encoding... Also, I've updated the AutoHotkey_L downloads a few times since L52. See recent commits. It includes a fix for codepages which don't support the WC_NO_BEST_FIT_CHARS flag, such as UTF-7.

Is it appropriate to use GetAddress as a way to check for the existence of a key in an object? Alternatively or in addition, is there a better / recommended way to check for key existence?

(Sorry if this has been covered before -- I didn't succeed in turning up any relevant-looking forum results.)

If there is no string value associated with the key, GetAddress will fail (return ""). Enumerating keys is currently the most reliable way to determine whether an object contains a particular key.