AutoHotkey Community

You guys are great! Thanks for discussing this.
The problem occurred when upgrading and not knowing about the change. Now that I know I just make an ini file.

I used to think adding any steps to the "install" would be a bad idea. I have changed my mind; here is why.

Steps
1. Download the zip file
2. Unzip
3. Learn the scripting language

Watch your step that last one is harder than it looks. Yep if they find installing the software difficult they are unlikely to get very far on step 3. In fact perhaps another message on install to the newbies might get their attention to read the quick start.

Chris
I agree this helped me when I started. I umm... skipped the Quick-start Tutorial

For a long time I've silently wanted more settings in the registry...for example InstallDir is set in the registry & A_InstallDir points to it, I've wanted an A_IncludesDir builtin, reading from the same place in the registry as A_InstallDir, for example a default install of AutoHotkey would write these values to the registry...


...using relative paths this would mean the actual Scripts Dir ends up being %InstallDir%\%ScriptsDir%...& the Includes Dir is added to the now-expanded Scripts Dir...


...again these would be defaults, so an arguably better default could be...


..."%MyDocuments%" being a make-believe variable pointing to the My Documents dir...for example %userprofile%\Documents...to be clear, this would result in...


...now how does any of this help the usb-drive situation?...well, you would re-purpose the ini, into actually being an ini...if AutoHotkey.exe is run without a script...it would...

1. Read AutoHotkey.ini in the current dir (or the dir AutoHotkey.exe is currently running from {ignoring the "working dir"}), if it contains a "Settings" section, it would read it instead of the registry...if there's no "Settings" section...or if it's "not a valid ini" based on some other sanity check...it would fall back & assume it's an AutoHotkey Script...& run it...
   
   
   Note: so the new purpose of AutoHotkey.ini is to override Registry settings
2. If AutoHotkey.ini don't exist or exists & has a "Settings" section...look for AutoHotkey.ahk in the current dir & run it...or if it don't exist look for & run it in the %ScriptsDir%...offer to create based on the location of %ScriptsDir% (from the Settings section of the ini or from the registry if the ini don't exist)...if no setting for %ScriptsDir% exists anywhere, offer to create in My Documents...

...I'm not sure if this is obvious from the above but new builtin vars should be created mapping to the "current" value...from the ini, falling back to the registry...or falling back to the hard coded default...("My Documents" or "My Documents\AutoHotkey")...



...I think it should have a longer explanation for when its run without a script...for example...


...I think acting like a script with just "#Persistent" in it had been run would confuse new users even more...they download a new program, run it & it "does nothing"...(they don't notice the tray icon pops up)...yes, I do use a script with just "#Persistent" in it, cuz it's useful to me, but not for a first-use experience...it should have a big bold explanation & perhaps one more registry setting...DefaultRun...so advanced users can specify a script to run if it's run without params...that script could just have the line "#Persistent". So have an explanation for new users...& a registry/ini setting so seasoned users can get rid of the explanation...(although, my example explanation isn't that annoying & has a help button, so it's useful)...

_________________
AutoHotkey-Hotstring.ahk - Helping the world spell "AutoHotkey" correctly! (btw, it's a lowercase k!)

I really like the [Settings] section and registry entry ideas .

Just a thought... When running AutoHotkey for the first time, it might be good to present the user with a GUI instead. The GUI could be simple with 2 buttons and an Edit control. The edit control could contain an explanation like the one found in the default script and the buttons could: 1) open the default script for editing and 2) open the Quick Start Tutorial in the Help file. This could show the user an actual application window, demonstrate basic GUI capability and give a shortcut to get to the Quick Start Tutorial to get them started.

Here's a suggestion for a replacement Default script to help people get started with AutoHotkey. It's not as simple as the current script but I think that something along these lines might be helpful.

This would make AutoHotkey heavily dependent on the registry, which would reduce portability (though it's possible I'm misunderstanding your idea). The current uses of the registry are nonessential and have no significant impact on portability.

In the future, there might be a standard library, which might make use of the registry in a way like this. However, the benefit/cost of any increased use of the registry seems low compared to other priorities like v2.

I'm generally against this because I think it's more complicated and less portable than it sounds. I'm a strong proponent of "Keep It Simple Stupid" (KISS), and this seems to violate it. On the other hand, if AutoHotkey were more ambitious in scope like PHP, something like this might be desirable. However, it would need its own section in the documentation, and that part of the help file is already so long than I think most readers lose interest long before reaching the bottom.

In my opinion, it's too complicated. The benefit/cost of all these ideas seems low when you consider how many users intentionally launch AutoHotkey.exe without specifying a script.

In an ideal world, a better prompt with more choices would be great. But right now, the development time seems like it would be better spent on something else. I hope this area will be improved someday, but someone else would probably have to develop it for it to get done anytime soon.

The current sample script is hard-coded into the program, so making it into a longer script might increase code size more than it's worth. Also, the script can't be made external to the program without impacting portability.

Finally, I appreciate all the ideas. My reluctance to give them a high priority comes from my belief that they are poor in cost/benefit when you consider how many users intentionally execute AutoHotkey.exe without specifying a script.

If someone would like to design and develop a better behavior for AutoHotkey version 2 (when it is launched without a script), I would be interested in that, especially if it abides by the KISS principle.

Thanks.

Thanks for the response and for considering the suggestion . I'm not suggesting that you reconsider your priorities, but I'm curious, doesn't the script currently get generated as a separate AutoHotkey script? Doesn't' that get executed as a separate script already when AutoHotkey.exe is run without params? I understand what you are saying when you say that the current script is hardcoded but couldn't the script be installed in the AutoHotkey directory during the install process then optionally get copied to the Document folder instead of being generated by AutoHotkey itself? That could possibly reduce the code size in AutoHotkey.exe...? For portability, if AutoHotkey.exe is run by itself, an ini file doesn't exist, AutoHotkey.ahk doesn't exist in the Documents directory and the script does not exist in the current directory that would be copied to the Documents directory, then would it sound logical for AutoHotkey to terminate (nothing to execute, terminate)? If someone has copied AutoHotkey.exe to a separate directory without copying the other files in the AutoHotkey directory then they likely won't need a default script to be generated to explain usage. If this is true then does the default script need to be built into AutoHotkey.exe?

That is true and it's a good alternative. The reason I didn't do it that way is that the sample script is currently only 1.3 KB, which doesn't seem like a significant impact on code size (especially when compressed via UPX). Furthermore, the current method was simpler to implement and slightly more portable (as you pointed out).

I've reconsidered one of the suggestions here: to clarify the MsgBox that appears when running AutoHotkey.exe. Maybe it should read something like the following:Refinements are welcome.

Thanks.

...it would use the registry if anything is there to read...it would...

1. Read an "AutoHotkey.ini" file in the same directory the current exe's running from...or maybe: from the "working dir", then "exe dir".
2. Failing that, it would read from the registry.
3. Failing that, it could just fail or look in the working dir/exe dir for an Includes subdir...& use that...

...it's really a multi-level fail-safe...if you (the person writing a script) don't want to use the registry, for example on a usb-stick (portable) you are expected to create an AutoHotkey.ini with the settings...but the fail-safe code could go as far as still trying to work when no settings are anywhere...by using hard coded defaults. Check this out...

Search for: Include*Dir
Display results as: Posts
Return first All available characters of posts

...I mentioned an IncludeDir setting 1st a year ago & people have been writing RegRead workarounds since a builtin don't exist...


...which is exactly why I want AutoHotkey to support these settings...I need to use A_IncludesDir for my scripts that use my Base.ahi, currently I have no method to "find the users include dir" cuz AutoHotkey don't ship with one & if I just hard code a default based on A_AHKPath, people might not want their scripts/includes under the AutoHotkey Install dir...


...I didn't say "NOW" I'm just saying I've been wanting this silently & now I'm posting it...if it's a good idea & you EVER want it, then fine...I could start writing it...


...it may be more "complicated" the one time you or someone writes the code for it, but it's helpful to new users cuz the current first-use experience of "WTF? Yes/No what? What did I do? Is this AutoHotkey? A Yes/No box?"...no I don't expect people to run AutoHotkey.exe without a script alot but EVERYONE does it to begin with...you download a new program & run it...it's how you test it/experience it...


...it might be non-KISS-able, but it's only a string of if-else's trying to find the settings...


...huh?...does that mean if AutoHotkey had more users?...like PHP?


...own section describing the settings searching algo?


...which part?


...I don't know if length is my problem with the help file, but it's the "conciseness" you've said you don't like to repeat information & the Gui section shows it...you mention at the top what the overall syntax for the Gui command is...

Gui, sub-command [, Param2, Param3, Param4]

...ok "Param2, Param3, Param4" isn't very helpful, but lets read on...

Add, ControlType [, Options, Text]
Show [, Options, Title]
...etc...
Hide / Minimize / Maximize / Restore

...by the time you get to the bottom you forget you need "Gui" in front of all those lines...I would repeat some info...like instead of the current sub-sections I would use...

Gui, Add, ControlType [, Options, Text]
Gui, Show [, Options, Title]
...etc...
Gui, [Hide | Minimize | Maximize | Restore]

...sometimes you do need to repeat...basically it's (currently) kinda like a book, rather than a quick reference...you are intended to read from top-to-bottom & not need reminded about "which sub-list are these options for? Param2? Param3? no wait sub-command?".


...every new user does, at least once...until they "figure it out"..."oh what? I have to write a script? it's not magic? damn!".


...no!...no but...a good idea is a good idea...people need ideas to know which code to help you on...I didn't write this page of ideas as a recipe for someone else to do...I intend on writing as much of it as I can figure out how...BUT...I have to read alot of your source code, so by the time I figure out WHAT to edit, you could be done with v2 & start on these ideas...you are already swimming, I haven't jumped in yet...neither have any other developers, for one there isn't a ticketed "todo" list so people that know how to code don't know what needs done...


...ok, what??? v2 is a blanket term for "your vision of a better AutoHotkey"...I can't help read your mind & apply the changes you haven't gotten to yet...I need a list to know what I could chime in on...


...I'm here to at least start trying to help, I'm a long way off from actually compiling my own AutoHotkey, but I need some pointers to get started...I can't pay for MSVC, so when I get a compiler it's going to be MinGW...if AutoHotkey doesn't compile right away, I'll have to dig into the errors, then you'll have to apply those fixes to your code, hoping they don't give MSVC errors...or just drop payware & you use MinGW too...I'll never understand why an Open Source project uses a $500 compiler, but alot do...


...make the hard-coded script be...



...ok...


...no one said "high priority"...I need to know which ones I should try to work on...


...ok where do I begin...the v1 code? what do I do about the different compiler?


...I don't know about KISS...I code to handle every possibility I can think of...if a user could ever cause my logic to fail in some way, I code for it...


...well, technically I like my example message box more...other than the "GUI" languange it explains the situation more...& I want a help button...

_________________
AutoHotkey-Hotstring.ahk - Helping the world spell "AutoHotkey" correctly! (btw, it's a lowercase k!)

I don't like the idea, maybe because I just don't see the benefit of it. In this respect, it's like the namespaces proposal because I can't see most users using it. I want to spend my time working on features that matter to 90%+ of users, not obscure features that only a few percent would use.

Yes, something along these lines could be desirable someday. But since I don't understand the implications and usages that well, I don't want this in the main branch of the code anytime soon.

It means that I want AutoHotkey to stay as simple as possible unless there's enough benefit to justify new complexity. Right now, the benefits of storing settings in the registry and/or an INI file don't seem that great to me, mostly because I think only a small percentage of users would use it.

That has been changed. Thanks.

Okay, though you might be on your own for a while because right now, it's all I can do to keep up with e-mails and the essential topics at the forum.

That probably won't happen anytime soon. If you're serious about developing, you'll probably have to shoulder the entire burden of design, coding, testing, and maybe even the documentation.

It's news to me that you want to join the project. If you're serious about it, we can talk more privately.

It probably won't compile under that, and might take many hours if not days to make it compatible.

Visual Studio is known to generate smaller and faster code than MinGW. Although it's been a long time since I've tried MinGW, I think the performance differences are substantial (>20%).

It seems too complicated to be worthwhile.

That's not what I meant by KISS.

Thanks for your interest.