AutoHotkey Community

You are right, I'll change it to StrGet(). In fact, I named it as DerefString() initially, the later I changed it to StringGet(). But StrGet() sounds better.

Is it means in AutoHotkey_L "? [ ]" can not be used in variable names and they have other special meanings? I'm sorry I haven't played with _L so it is unfamiliar for me.

Right, AutoHotkey_L now supports Object/Array and naturally [] are reserved as the delimiters as in x[y]:=z. And ? was disallowed to remove the conflict with the ternary operator as in x?y:z.

I love objects, too. I think I should merge that feature from _L when we found most bugs in Unicode version are fixed.

great! great! keep up the good work!

Hi,

I forgot we always convert the strings from UTF-16 to UTF-8 to use PCRE, so I didn't add PCRE_UTF8 flag because its has some side effects when I write the codes in Perl. (PCRE is Perl Compat... IIRC). However, in our situation it should be used since the AHK scripts are in UTF-16 view.

But what is get_compiled_pcre()? Is it the same purpose with get_compiled_regex()? Why you think you need it to take UTF-16 string as parameter?

Hi.
The get_compiled_pcre() thingy is a typo, it should be get_compiled_regex().

I made it accept TCHAR strings because of a performance thing: the RegEx string is now only converted to UTF-8 when compiling (*cough* caching).

Anyway, I'm fixing most of the UTF-8 string position <-> TCHAR string position problems and basic RegExMatch() features are working .

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

About the performance, it only converts the strings to UTF-8 when compiles the pattern and call pcre_exec(), isn't it? So I have no idea why there are performance gains?

RegExMatch() in the script was not working since I believed it calls RegExMatch function (the same name in the C++ source codes), but it doesn't.

Your version converts to UTF-8 even when the RegEx is cached.
The caching was also changed to hold native TCHAR strings.

This is how the RegEx stuff works:

• The RegExMatch() and RegExReplace() script functions make AutoHotkey call the BIF_RegEx() AHK source code function.
• BIF_RegEx() compiles the RegEx and redirects to the RegExReplace() AHK source function if the user intended to call the RegExReplace() script function, otherwise the matching is done in BIF_RegEx().
• The RegExMatch() AHK source code function is used for RegEx window title matching apparently.

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

@fincs
I examine the codes, then I found you are right. May I wait for your fixes?

RegExReplace() is the only function remaining.
EDIT: Done

Link to my forked version (precompiled .exe included):
http://www.autohotkey.net/~fincs/AutoHotkeyU.zip

EDIT2: And yes, I'm using the latest commit

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

That would be great. Currently I can't carry out comprehensive tests with AutoHotkeyU since I changed, how to say, my custom libraries at the lowest level taking advantage of the automatic release feature (__Delete) of Object.

Super excited about this unicode version.

I'm testing the Unicode versions by either fincs or original one from the first post on Garry's youtube mp4 download script. (http://www.autohotkey.com/forum/topic34932.html)

on some Chinese songs (with Chinese titles), I was hoping the unicode version would automatically save the Chinese titles. But every time, both versions are crashing.

The youtube Chinese song link: http://www.youtube.com/watch?v=BbCBPfaeg-Y

@mosaic
Something should be noted. The scripts were written for ANSI version may not work in Unicode version of AutoHotkey without changes. Since we now store the characters in UTF-16, which is the native format in current Windows systems, a character consumes (at least) two bytes in this format. So if a script calls some APIs by DllCall() that take some strings as its parameters, it should call the Unicode version of such API instead.

For example,


Some API may take more complex parameters (e.g. structures), that should be checked, too. (make sure you allocate enough bytes by VarSetCapacity or whatever)

I currently can't help by testing AutoHotkeyU, but at least I can support this project by kind words, so;

Fantastic! Keep up the great work!

This should really be Sticky topic.

yes, agree!