AutoHotkey Homepage AutoHotkey Community
Let's help each other out
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

mising "A_decade" and maybe "A_century"
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    AutoHotkey Community Forum Index -> Wish List
View previous topic :: View next topic  
Author Message
jonny



Joined: 13 Nov 2004
Posts: 3004
Location: Minnesota

PostPosted: Fri Nov 19, 2004 9:37 pm    Post subject: Reply with quote

Another note: AutoHotkey can make separate scripts, even whole programs that require no outside influence to work properly. Should a default script or global settings be made, it may confuse newcomers and experienced users alike, especially with compiling. A compiled script should be runnable on a system without AHK. If it's default is to look for some external settings, how will this affect compiling? Aside from that, newbies may come after this is implemented and start to depend on it. That would really mess up some of the core ideas, I think.
Back to top
View user's profile Send private message
Chris
Site Admin


Joined: 02 Mar 2004
Posts: 10467

PostPosted: Sat Nov 20, 2004 12:13 am    Post subject: Reply with quote

Quote:
Maybe making AutoHotkey.ini into a global settings file (not a script) wouldn't be so bad
In light of what you've said, I'm not to keen on that either because scripts would become less portable that way. Still, if there are particular settings someone would want saved that are relatively harmless -- such as the position of the script's main window when opened -- I'd be more receptive to that.

Quote:
Whoa, whoa, whoa. I just saw this thread now, and I for one don't like this idea. ... It's trivial to simply make your own default.ahk and then put #Include default.ahk in the scripts you want affected. That's one line of code, 21 characters. Taking the step to have to include something to not include this default script would deter more people than it would help, I think.
Yes, I didn't consider this a high priority before, and I'm even less enthusiastic based on what you've said.

Quote:
If it's default is to look for some external settings, how will this affect compiling?
That's a good point. The correct thing to do would be to include all dependent files inside the compiled script so that it is truly stand-alone.

Quote:
newbies may come after this is implemented and start to depend on it. That would really mess up some of the core ideas, I think.
What kind of core ideas?

Thanks for your insight.
Back to top
View user's profile Send private message Send e-mail
Chris
Site Admin


Joined: 02 Mar 2004
Posts: 10467

PostPosted: Sat Nov 20, 2004 12:30 am    Post subject: Reply with quote

Quote:
[quote="Anonymous"]so maybe Autoexec.ahk (or .ini)...or use AutoHotkey.ahk to do what AutoHotkey.ini does now & re-purpose AutoHotkey.ini to do the global thing. I have definitely wanted this, things that affect all scripts.
Can you give examples of global INI settings you would want?

Quote:
You might as well re-purpose AutoHotkey.ini cuz I'm sure no one uses it for its current purpose (if they do they can rename it to .ahk & add the icon to their start menu)
I'm pretty sure many people do use it. It's intended to be a basic way to get some hotkeys up and running without actually needing to know much about scripting.

Quote:
...no, the global default should be in the ahk dir, another default could be in the script dir tho, currently my testing script is in the ahk dir, but I wouldn't want to be limited to leaving it there.
One drawback to that is that sometimes users do not back up their Program Files folder (with the possible exception of ini files). Thus, anything in there would be lost when moving to a new system, hard disk crash, etc.

Quote:
I like the name Autoexec.ahk (or .ini) for the global one & Autoexec.ahk for the script dir one, default.ahk just has a bad ring to it, kinda like the M$ default.htm or .asp. If you look for both the global & the script dir one, make a check to see they're not the same dir or you'll end up execing the same script twice.
Great comments, thanks.

Quote:
...well, here's one option, it sounds excessive to me to, but it's an option...use the Apache .htaccess method
Yes that seems like way overkill, but thanks for describing it.

Quote:
You could even use Autoexec.ini to be the settings file that determines what is looked for & run. Then people could set it to use Autoexec.ahk in the program dir for the global default & Autoexec.ahk in the script dir...one, the other, neither, both...even configure a different name for those who WANT it called default.ahk (why?)? You could also include an Autoexec.ini in the script dir, that can override loading the global default, this might eliminate the craziness...
This kind of complexity is what I don't like because it really hurts the portability of scripts (moving them to a different machine and expecting them to run with the same AutoHotkey version). I think Jonny feels this way too.

Quote:
but if the AHK Scripts dir says no higher, it would stop, if not it would never stop, because there aren't more than 5 dirs from AHK Scripts to root...
Thanks for describing all of that. It may yet prove useful.

Edit: Fixed typo.


Last edited by Chris on Sun Nov 21, 2004 12:30 am; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail
jonny



Joined: 13 Nov 2004
Posts: 3004
Location: Minnesota

PostPosted: Sat Nov 20, 2004 6:25 pm    Post subject: Reply with quote

Quote:
I think Jonny feels this way too.


Thank you for valuing my opinion. Yes, I do believe that AutoHotkey should remain versatile, something you can use to create not only dependent hotkey systems that are very specialized to your system, (Those should be easy to create for beginners, a la global settings and premade example scritps) but also fully independent scripts and programs that others can and will use, with or without AHK. (Those should not depend on ANYTHING else, except the files and resources the author specifically made for it)
Back to top
View user's profile Send private message
Stefan



Joined: 30 Jul 2004
Posts: 72
Location: Deutschland (sorry for my english)

PostPosted: Mon Nov 22, 2004 7:28 pm    Post subject: Reply with quote

Thanks for all the cogitations you all make for "my" idea about "default.ahk". Laughing

------------------------------------------------------------------

- AKH scripts should be portable, of course, right.

But If i copy some script to a another PC,
i have to copy the "default.ahk" or a part of it too.
Or i copy the the relevant information into my script.
No matter.
I have to do this right now: i copy INIs, TSA_Names.ora, export registry settings ,... and so on with the apps i copy, too.

User who want to be portable didn´t must use this "default.ahk" (They work as the do bevor.)

For others may it be helpful <?> (They wrote there script moduls only ones)

And / or this "default.ahk" s could be shared from AHK web side <?>
Or come with the installation packed <?>
So Chris can put all this "tricks scripts" into it, not only into the help.


------------------------------------------------------------------


- That statment about compilling issue is important too, thanks for bring it up.

Of course i can use "#Include default.ahk,
but then i have to think about to inlude this in my compilation on my own too, isn´t it?
(but i to recognize it better, because i see the #include line, OK OK Wink )


------------------------------------------------------------------


- "Autoexec" is not the right name for what this *.ahk file should do, IMHO.

It shoult not "auto execute" smtg,
but contain "default" things.

I am think about "default.ahk"
for all that little scripts like that for %A_YWeek.

So Chris didn´t have to include always new vars into AHK,
but we (they who want this) can put this "default scripts"
in one central file, no matter what name this file will have.
And from now on we can use this new var in all our scripts.


------------------------------------------------------------------


So atleast the possibility to use a "what_ever_name.ahk"
for such default things / scripts would be handy ?

Maybe AHK.exe should first search in script_dir,
is there non than in AHK_install_dir for such a file.





Is this to many senseless work
or to less intresting for others
i will use #include xxx,
thanks
Stefan
Back to top
View user's profile Send private message
BoBo
Guest





PostPosted: Mon Nov 22, 2004 7:37 pm    Post subject: Reply with quote

@ Stefan
Hast du einen dreizeiler für mich, ich schnalle nicht wirklich worum es (dir) hier geht ??? Mit verwirrtem Gruß. BoBo
Back to top
Stefan



Joined: 30 Jul 2004
Posts: 72
Location: Deutschland (sorry for my english)

PostPosted: Mon Nov 22, 2004 7:51 pm    Post subject: Reply with quote

BoBo wrote:
@ Stefan
Hast du einen dreizeiler für mich, ich schnalle nicht wirklich worum es (dir) hier geht ??? Mit verwirrtem Gruß. BoBo


Ja, ich muss mich im englischen noch etwas üben,
manchmal weiß ich nicht wie ich mich ausdrücken soll,
und schreibe dann wahrscheinlich alles dreifach <?> Very Happy


Es geht zB um neue Variablen, die vielleicht nur ein
paar Usern nützen.

zB wurde die variable %A_YWeek (oder so ähnlich) gewünscht, (oder auch %A_YCentury or %A_YDecade)
welche man mittels ein paar Zeilen Script auch leicht selbst herstellen kann.

Damit der User diese "paar Zeilen" nicht immer wieder in jedes Script
einfügen, bzw. damit Chris nicht jede Variable in AHK integrieren muss,
habe ich eine "default.ahk" vorgeschlagen.

In dieser "default.ahk" könnte man dann solche code snipplets ablegen
und von jedem Script aus darauf verweisen.


So kann man sich auch Module zusammen stellen,
die in dieser "default.ahk" schlummern, und diese
bei Bedarf abrufen.
(Vorteil: nur einmal schreiben und dann darauf verweisen)


So oder so ähnlich hab´ich mir das vorgestellt.
Vielleicht bin ich damit auch auf dem Holzweg????

Alles klar ???? Rolling Eyes Very Happy
kind regards
stefan
_________________
Stefan

This post was created with the kindly help of http://dict.leo.org/ and remember: “Allways look on the bright side of Life”
Back to top
View user's profile Send private message
jonny



Joined: 13 Nov 2004
Posts: 3004
Location: Minnesota

PostPosted: Mon Nov 22, 2004 9:06 pm    Post subject: Reply with quote

Quote:
I have to do this right now: i copy INIs, TSA_Names.ora, export registry settings ,... and so on with the apps i copy, too.


Um... You don't have to actually have those. Scripts can create INIs and reg keys by themselves, so technically you don't have to include anything else with the program except the resources it uses (icons, graphics). But having a whole new script just to store the settings of others, I personally think that's far more confusing than having INIs (I rarely use reg keys), as for them their meaning is clearly defined, but even so I don't use them that often. It's sometimes just as easy to edit variables in a script as values in an ini.

Quote:
So Chris can put all this "tricks scripts" into it, not only into the help.


I for one wouldn't like having my scripts being messed with before I even started writing them. Yes, the fixes included in various places on this forum are helpful, but they aren't always relevant. (Much like Windows security updates)

Quote:
So atleast the possibility to use a "what_ever_name.ahk"
for such default things / scripts would be handy ?


OK, this I'll agree with, but only as an option of course. Very Happy
Back to top
View user's profile Send private message
BoBo
Guest





PostPosted: Mon Nov 22, 2004 11:42 pm    Post subject: Reply with quote

I definitely will repeat what has been already said. Sorry.

What I've understand so far:

1) A function/command isn't currently unavailable in AHK e.g. A_YWeek
2) a workaround/function for A_YWeek is available e.g. provided by Chris&friends
3) it looks like it make sense to collect those workarounds/functions within an external file/script and to be able to "call" them if necessary from within an AHK script. (CSS style)

A.ahk
Quote:
var1=2004
var2=Hello
AHKScriptRun, ReturnVar, B.ahk, param1[, param2, ...]
StringSplit, Field, ReturnVar, `|
IfNotExist, C:\%Field1%
MsgBox, %Field2%
ExitApp


B.ahk
Quote:
var1 = %1%
var1 ++
var2 = %2% World
AHKScriptReturn [, var1|var2]


Hope that make sense Wink

@ Stefan
Danke nochmal für die Erklärung. Smile
Back to top
Chris
Site Admin


Joined: 02 Mar 2004
Posts: 10467

PostPosted: Tue Nov 23, 2004 12:54 am    Post subject: Reply with quote

Stefan wrote:
But If i copy some script to a another PC,
i have to copy the "default.ahk" or a part of it too.
Or i copy the the relevant information into my script.
No matter.
That's a good point. But there are disadvantages:
1) Performance: Every script launch would have to check for the default.ahk file. If the file system isn't currently cached, this might delay the launch of each script by 10 or 20 ms. This hasn't been tested so might be a false alarm.

2) Putting the default script in the AutoHotkey folder doesn't seem like a very good place because it might not get backed up there. And it might often be forgotten when migrating to a new hard disk since many users figure they can simply reinstall their software to get back the contents of their Program Files folder.

Stefan wrote:
And / or this "default.ahk" s could be shared from AHK web side <?>
Or come with the installation packed <?>
So Chris can put all this "tricks scripts" into it, not only into the help.
That's interesting but it doesn't seem overall to be that useful, since most scripts would not need or want the other scripts included unconditionally. Someday when there is support for parameter-passing and return-values there can be some standard include-files inside the installer. These can be #include'd at the script author's discretion.

BoBo wrote:
3) it looks like it make sense to collect those workarounds/functions within an external file/script and to be able to "call" them if necessary from within an AHK script. (CSS style)
AHKScriptRun, ReturnVar, B.ahk, param1[, param2, ...
You could do something very similar by using RunWait and checking ErrorLevel afterward (scripts can set ErrorLevel via "ExitApp, nnnn").
Stefan wrote:
Is this to many senseless work
or to less intresting for others
i will use #include xxx,
I don't think the default include file is a bad idea. It's just one that has quite a few disadvantages to offset the advantages, which reduces enthusiasm for it.

Thanks everyone for your ideas. I'll read this topic again when the time comes to work on this feature, though it might be a while for the reason stated above.
Back to top
View user's profile Send private message Send e-mail
jack



Joined: 04 Sep 2004
Posts: 77
Location: UK

PostPosted: Tue Nov 23, 2004 7:58 am    Post subject: Reply with quote

if you decide to implement something, please can you make it an installation-wide default that the include file is off? further, can you also add some option so that a script can say 'do not use any system include file'?

i can forsee problems when i give a script to somebody else who uses an automatically-included file that breaks something in my script.


jack
i don't believe in the no-win scenario
Back to top
View user's profile Send private message
BoBo
Guest





PostPosted: Tue Nov 23, 2004 8:34 am    Post subject: Reply with quote

Quote:
You could do something very similar by using RunWait and checking ErrorLevel afterward (scripts can set ErrorLevel via "ExitApp, nnnn").


Thx for sharing that. Unfortunately the Errorlevel delivers only a single value ...
Quote:
An integer (i.e. negative, positive, or zero) ...
... (which - confirmed - can be 0=success 1=sunday 2=2004 3=MyDirectoryName 4=something else etc.)

That's why I've used two variables in my above sample. But you're correct. In 98% of all cases a (single value) Errorlevel will make it. Thx.

Just another sample to clarify my statement Wink

Quote:
Macro>file_name [/variable=value|variable [/variable=value|variable] ... ]

Executes another script file. file_name must be a filename of a macro file. ... . To pass values to the macro specify each one after a / character. The variable name given should exist in the script to be run. The value to assign to that variable is specified after the = character.

Data can be returned to the calling macro by setting the MACRO_RESULT variable in the called script. After the script has been run MACRO_RESULT is available to the calling script.

If the calling macro has a log file the script being called with the Macro command will log to the same log file. You can override this using the /LOGFILE parameter to set a log file for the sub macro.

Abbreviation : Mac

Examples

Macro>Defragment Disk.scp

Macro>MyMoveFile.scp /source=c:\temp\myfile.bat /destination=c:\temp\myfile.bak


This way I'll be able to trigger a bunch of "modules".
Btw. I don't think that this topic should get a high priority @ the moment. Workarounds based on a "limited" set of commands, are (in most cases) good to train the brain Laughing

Period.
Cool
Back to top
Stefan



Joined: 30 Jul 2004
Posts: 72
Location: Deutschland (sorry for my english)

PostPosted: Tue Nov 23, 2004 9:13 am    Post subject: Reply with quote

To understand my suggestions better, again a part of my earlier post:
(not to push Chris, pls understand me right)

iam play with AHK and just wanna use this command


#z:: create new download folder with current date (in Salamander, if its from interest)
Send, {F7}
Send, Download_%A_mon%%A_century%


but i don´t want to always insert

StringLeft, Century, A_YYYY, 2

in this script, because iam don´t remember it when i needed it.
So i ask for an "default.ahk" to put this "StringLeft, Century, A_YYYY, 2" thing in, forget it, and just rever to it (and Chris don´t have to intecreate it in AHK).

Thats only a short script, but i can imaging that there are larger things.
The one of you, they are more familiar with AHK
or programming perhaps don´t need such "default.ahk",
but is AHK for programmers only?


Because see, i wanna use AHK, i don´t wanna become a programmer.
Like i don´t wanna build a car, when i just wanna drive with it.


But i see a many other suggestions to help myself in this issue,
thanks you all for your kindly support !
_________________
Stefan

This post was created with the kindly help of http://dict.leo.org/ and remember: “Allways look on the bright side of Life”
Back to top
View user's profile Send private message
BoBo
Guest





PostPosted: Tue Nov 23, 2004 9:27 am    Post subject: Reply with quote

Quote:
A.ahk
#z:: create new download folder with current date
{
RunWait, b.ahk A_Century,,Hide
A_Century = %Errorlevel%
Send, {F7}
Send, Download_%A_Mon%%A_Century%
Return
}


Quote:
B.ahk
Goto, %1%

A_YWeek:
.
.
ExitApp, xxx

A_Century:
StringLeft, Century, A_YYYY, 2
ExitApp, %Century%


Untested Rolling Eyes
Uncommeted Confused
Motivated Cool
Back to top
BoBo
Guest





PostPosted: Tue Nov 23, 2004 10:19 am    Post subject: Reply with quote

Quote:
i don´t wanna become a programmer

Once you've coded "Hello World" you're trapped. Exclamation
Yep, you're sued to become fat/supersized and bleached like a [Proteus_anguinus]

Sorry pal Wink
Back to top
Display posts from previous:   
Post new topic   Reply to topic    AutoHotkey Community Forum Index -> Wish List All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You can post new topics in this forum
You can reply to topics in this forum


Powered by phpBB © 2001, 2005 phpBB Group