581 replies to this topic

[entropic]

DeWild1 - The first problem I see is that IronAHK does not yet support GUIs, it is a planned feature for the 0.7 release.

[DeWild1]

DeWild1 - The first problem I see is that IronAHK does not yet support GUIs, it is a planned feature for the 0.7 release.

And YES, I am as DUMB as I LOOK!
I missed that... :oops:
The one with decript.ahk does not have any GUI or msgbox though. :shock:

[polyethene]

I would appreciate if it is going to be configurable.

The StdLib search path is as follows:
[*:u5dmgsun]Environment variable AHKLIBPATH, multiple paths can be specified e.g. /opt/ahk:/root/scripts or C:\scripts;D:\AutoHotkey
[*:u5dmgsun]path-to-currently-running-ironahk.exe\lib
[*:u5dmgsun]On Windows:
[*:u5dmgsun]My Documents\AutoHotkey\lib[*:u5dmgsun]On Unix:
[*:u5dmgsun]/usr/lib/ahk
[*:u5dmgsun]/usr/local/lib/ahk
[*:u5dmgsun]~/lib/ahk[/list]This is roughly similar to PHP's include search path.

So this <!-- m -->http://www.autohotke...ic.php?p=241769<!-- m --> should be a thing of the past because it makes AHK 64 bit so the registry will get written to without complication or having to do this or that.. Right?

Yes.

And with the bytecode compile, I should be able to digitally sign my apps without them getting corrupted... Right??

Yes.

And now this <!-- m -->http://www.autohotke...pic.php?t=27146<!-- m --> was a sad waist of super Micha's time... Right???

I haven't studied the difference with Michas version but IA will run seamlessly on Windows Mobile, xbox etc.

[polyethene]

Version 0.5.5 released with 70% AutoHotkey compatibility, hotkeys and hotsrings on Windows and 126 various improvements over 14390 lines of code.

A Windows installer is now available in 32bit and 64bit flavours. The default file association is created for .ia.

Threads are launched as real processor threads which for now affects SetTimer, Hotkey and hotstrings. While variables have been synchronised for thread safety there are potential race conditions with hotstrings in rare circumstances. This will be checked more closely for v0.9.

The target for the next version v0.7 is GUIs which I suspect is essential for most people. By then hotkeys and hostrings should be completed for Linux and OSX (X11).

[Tuncay]

great! I`ll test that. Thx.

[Tuncay]

FileRead(f, "test.ia")
MsgBox %f%

is not working. FileReadLine does work.

[polyethene]

Thanks for testing, I just noticed a silly mistake in FileRead which causes an infinite loop or index out of bounds exception when it tries to parse *c/*t/*m options. This will be fixed in the next version.

The NUnit automated tests for the syntax parser checks with over 11,000 lines of ahk code which has been very useful for detecting regression bugs and error handling. On the contrary the command library has virtually no test cases. This affirms the need for what I've known all along but have been too lazy to do: write more tests for commands. This will be a priority for post-v0.9 releases.

FileReadLine works for me but with one undocumented exception:

src = C:\Program Files (x86)\AutoHotkey\license.txt
FileReadLine(f, src, 11)
FileReadLine, [color=red]%[/color]f2[color=red]%[/color], %src%, 12 ; untranslated commands with OutputVar have to be used this way for now
MsgBox %f%`n`n%f2%

[Tuncay]

About the compatibility. This does not interest me. I would never use complicated scripts with IA. And about the file extension, I would suggest to use .ihk instead of .ia. That would look more natural and ahk like. That is my persanal taste. This would be consistent with other versions, like .uhk or .lhk for AHK_U or AHK_L . That assumes one letter is reseverd for exactly one version of AHK.

[polyethene]

About the compatibility. This does not interest me.

It does for me The aim for version 1.0 is 99% compatibility with AutoHotkey on Windows and 95% on Unix (OSX and Linux).

I would suggest to use .ihk instead of .ia ... like .uhk or .lhk for AHK_U or AHK_L

The abbreviation IA came up in IRC a while ago and I couldn't find any other application which used this file extension. To me it looks better than .ihk, but I understand everyone has different tastes. In future the plan is to keep .ahk and have the setup detect an AutoHotkey installation and provide alternative context menu run and compile options. Out of curiosity where are those other extensions mentioned? I looked around briefly but couldn't find any mention of them - or are they names you just came up with?

[Tuncay]

I looked around briefly but couldn't find any mention of them - or are they names you just came up with?

Sorry for confusion. They are just on the fly thoughts I had at begin of writing that posting. I wanted just mention what it looks like ideally to me.

I find your idea bad letting the user making the decision. Most user would use default extension you suggest with the installer. That would be the official used one. And .ahk is used with standard AutoHotkey. Confusion is pre programmed!

Advanced users with experience can easily change file association. I think this is not needed with your installer. Another problem could be files from others. Do we need then rename all the time?

Keep the current .ia extension, that is fine. I was just suggesting what I want to see. But I can understand that you want to make .ahk as default extension if you really aim 99% compatibility. I do not see any need for that.

Edit: To clarify what i wrote earlier:

I would never use complicated scripts with IA.

I would use complicated scripts with IA, but I mean only those wrote especially for IA.

[DeWild1]

Titan in a month or two, I should have some money. I would love to donate to you and Chris.
This will be amazing. Nnaaaaaaaaa this IS amazing!

Also, I to make a program for 64 bit, I will have to have my installer detect 64 or 32, then install the correct version, right?
And to make a 64 bit version, I will have to compile it from a 64 bit system, right?
Or does .net got both ways from the same EXE?

[entropic]

You can compile for 64 bit systems from a 32 bit system. You will just have to install the 64 bit compiler if it isn't already installed, I don't believe it is installed by default.

[DeWild1]

You can compile for 64 bit systems from a 32 bit system. You will just have to install the 64 bit compiler if it isn't already installed, I don't believe it is installed by default.

Thank you!
Also, will signing of the programs work?
<!-- m -->http://www.autohotke... ... 928#262928<!-- m -->
Sadly, I bought my cert and then found out I could not digitally sign my hard word! :cry:

[polyethene]

Or does .net got both ways from the same EXE?

Yes, it doesn't matter which version of IronAHK you have installed, any compiled binaries will work everywhere on all operating systems and processor architectures. This is one of the benefits I like to emphasise

You may be wondering why two different versions of the installer exist in that case, it's because from what I know WiX does not have the ability to create dual 32bit and 64bit installers at this time.

Also, will signing of the programs work?

Yes, sign the assembly as you normally would.