AutoHotkey Community

You can use "astr", but iirc it only allocates enough buffer space for the actual length of the input string. This really should be changed; perhaps using var capacity where available would be best. Typically the var capacity wouldn't be much greater than the length, except where it's actually needed.
Did you mean "isn't feasible"? Actually, you can get around load-time validation by specifying at least a single deref (empty or otherwise):

It was almost an afterthought, meant to provoke a comment. Currently the revision number takes a small amount of time and effort to maintain, which adds up, and has to some degree discouraged me from frequent updates. Since you and probably others see benefit to keeping the revision numbers, I will see what I can do to streamline it into my release process.
I was reluctant to make that change to my main branch immediately. I will soon.
How did you get it to output UTF-8? I presumed WritePrivateProfileString (and therefore IniWrite) only supported UTF-16 ("Unicode") and ANSI.

Did you put the [Config] key on the first line? I think ERROR_FILE_NOT_FOUND could also mean it couldn't find the section in the file. It works for me, but only if [Config] is not on the first line (i.e. not on the same line as the BOM). This reaffirms my belief that Windows' ini functions do not have any direct support for UTF-8; rather, they reinterpret the UTF-8 data as ANSI.
One thing to watch out for: at least one has an "A" version, a "W" version, and an ANSI version with neither suffix - ExtractIconEx. In that case the "W" suffix must be explicit for the Unicode version to be called, even in a Unicode build.

I guess you need to update your release script. I don't know what kind of effort you talk about, but its regular practice in automatic build environments to make this...well.. automatic.


I only executed those 2 lines of code I posted above and uploaded ini file generated. File didn't exist before that. (OS was VISTA). Executing the same thing on Win7 gives Unicode and everything works correctly.


Yes.... That also explains why I was getting double Config section.

_________________

It is "automatic" in my release script; the real problem is that my release script isn't integrated with git. Eliminating the revision numbering would've meant one less thing to worry about when I redesign the script. Never mind though; I know what needs to be done.
On my XP Pro SP3 32-bit VM, Vista Business 32-bit VM and Windows 7 Pro 64-bit (all "English (Australia)"), it creates the file with UTF-16, which displays correctly when opened in Notepad.

Yes, in my release scripts with SVN I first query the server via command line about last release number. I also have another technique - I don't have postbuild action but script (on the build computer) that constantly query svn for the logs. Depending on log metadata it checksout that revision, pack it, make necessary changes and ftp it.

_________________

I've updated the release script, and pre-built ANSI binaries are once again available.
I found that `git describe` will indicate what the last revision was (if it was tagged correctly) and how many commits I've done since then (whether or not I've pushed them to github). My script now uses this instead of a simple counter (IniWrite), and uses it in combinaton with `git log` to grab a rough list of changes since the last revision. I intend to commit more often, running the script only occasionally - to increment the revision number (and commit this change), tag, build, zip, update the version history.html and sync with autohotkey.net.


Anyway, to the real purpose of my post: obj.() vs %obj%(). It suddenly occurred to me (at 2:30am, incidentally) that the latter form would be possible and would probably be clearer/more intuitive. After a bit of searching, I found that I'd already figured it out months ago and written this comment in L31:
Which do you think is more appropriate: func.() or %func%()?

I personally hate % % syntax. One of the features I was looking forward in mainstream ahk was $var (it was mentioned couple of time even by Chris iirc). Anyway, I care about functionality, so altho I prefer obj.() syntax I am ok with alternative. Obj.() is clearer to me because it clearly makes the difference between "default method call of an object" and "dynamic function call".

About your new release script, that was exactly I was talking about. I just recently switched to previously mentioned method of metasymbols in commit log. Its kinda cool, because you don't even have to launch build script. When I commit, if the log starts with *** version ... *** , my constantly looping build script sees it, it checkout it, then launches release procedure.

_________________

I think that with values which represent functions, no distinction should be made between objects and names. This could be important; for instance, I've used code like f:=x.y, %f%(x) to ensure x is passed as a parameter to f - even if y is defined directly rather than through x.base. Currently it only works if y is a simple function name.

On the other hand, I can see that a distinction might be helpful in some cases, so I'll consider implementing both.

Some things about x._SetCapacity(y,z) that I haven't mentioned in the documentation:

• It will always attempt to resize the field, even if z is less than the current capacity.
• Data is preserved where possible, but shrinking the field will truncate data.
• The actual capacity in Unicode builds is always a multiple of two bytes.
• One character is always reserved for a null-terminator; this is excluded from the capacity passed to _SetCapacity and returned from _SetCapacity and _GetCapacity.

obj.() and %obj%() were more complicated than I was expecting. Instead of removing a validation check for obj.(), I had to add an exception for '('. Invalid syntax like obj.-1 or obj. spaced is still disallowed. %obj%() would've required some nasty hacks since it would need to insert a parameter between the object and parameter list; I've deferred it for a future revision, where I'll probably implement it as a separate built-in pseudo-function (like ObjCall).
As you can see, I've added it in this revision. Unfortunately I had lost the original source code for the test build I had given you. It was quite difficult to reproduce the fix at first; somehow the Unicode builds exhibited strange behaviour, only after applying the fix. Eventually I realized it was because your test case was calling CallWindowProcA, then the rest was easy.

Thx for updates. Lolzor @ CallWindowProcA (I appreciate the underscore too)

_________________

Hi,

Just downloaded the latest build from your site Revision 45.
placed autohotkey.exe in his place and placed the AutoHotkeySC.bin
Under the compiler folder.

When trying to compile to exe i get an error from the compiler:


Am i doing something wrong?

Thanks,
Twhyman

_________________
(\__/) This is Bunny.
(='.'=) Cut, copy, and paste bunny onto your sig.
(")_(") Help Bunny gain World Domination.

Yes. Close the already running compiled program first.

_________________
Greetings
Rog

I understand now the AHK_U is merged into AHK_L and there is a limited set of Unicode characters supported. Is there a plan to support Asian characters? Let me know what help is needed. I'm good in Chinese characters, if testing is needed, I may be able to help.

_________________
TypingAid autocompletion program made with AHK.

Hi,

This is not the problem... I have tried many scripts to compile, Two computers, And when reverting to the the old AutoHotkeySC.bin the script is being compiled just fine.

Can someone try to compile using the latest version?

Any more ideas?

Thanks,
Twhyman

_________________
(\__/) This is Bunny.
(='.'=) Cut, copy, and paste bunny onto your sig.
(")_(") Help Bunny gain World Domination.

No. Did you save the script as UTF-8 (or UTF-16) with BOM (Byte Order Mark)? If not, your script file is loaded according to the active code page, not Unicode.
Hmm, something's gone seriously wrong - those bin files are much larger than they should be. My latest build is half the size, which is still larger than I'd expect. I'll look into it.

Edit: Try downloading the files again. My post-build script had broken when I switched my main AutoHotkey.exe with a Unicode build. Specifically, FileRead was automatically converting the bin files from ANSI to UTF-16 (interpreting them as text). The last batch must've had the post-build script run twice without the bin being rebuilt in-between, thus quadrupling the size. Serves me right for neither using the new file I/O functionality nor being patient enough to do clean rebuilds.

Hi,

I re-downloaded the bin files, And its working now I was wondering too why the SC bin file was 2Mb

P.S
How can i change the ahk_class of the GUI window from AutoHotkeyGUI to a string I like, In the regular AHK I did that by Hex editing the SC bin file, Now I cannot find that string anymore.

Thanks and keep up the very good and impressive work you do,
Twhyman

_________________
(\__/) This is Bunny.
(='.'=) Cut, copy, and paste bunny onto your sig.
(")_(") Help Bunny gain World Domination.