AutoHotkey Community

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...
The one with decript.ahk does not have any GUI or msgbox though.

_________________
CPULOCK.com
virusSWAT.com
Computer Repair Computer Service.com
911PCFIX.com

should be awesome to try it when theres GUI support

The StdLib search path is as follows:

• Environment variable AHKLIBPATH, multiple paths can be specified e.g. /opt/ahk:/root/scripts or C:\scripts;D:\AutoHotkey
• path-to-currently-running-ironahk.exe\lib
• On Windows:
  
  • My Documents\AutoHotkey\lib
• On Unix:
  
  • /usr/lib/ahk
  • /usr/local/lib/ahk
  • ~/lib/ahk

This is roughly similar to PHP's include search path.

Yes.

Yes.

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

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

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).

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

great! I`ll test that. Thx.

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

is not working. FileReadLine does work.

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

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:

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

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.

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

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

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?

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

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 use complicated scripts with IA, but I mean only those wrote especially for IA.

_________________
{1:"ahkstdlib", 2:"my libs", 3:"my apps", 4:"my license"}
--> Don't feed the troll! <--

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?

_________________
CPULOCK.com
virusSWAT.com
Computer Repair Computer Service.com
911PCFIX.com

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?
http://www.autohotkey.com/forum/viewtop ... 928#262928
Sadly, I bought my cert and then found out I could not digitally sign my hard word!

_________________
CPULOCK.com
virusSWAT.com
Computer Repair Computer Service.com
911PCFIX.com

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.

Yes, sign the assembly as you normally would.

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.