| View previous topic :: View next topic |
| Author |
Message |
Peepsalot
Joined: 06 Oct 2005
Posts: 24
|
 Posted: Fri Oct 07, 2005 4:35 pm Post subject: More flexible Code Blocks |
 |
|
Can blocks be changed so that it is aceptable to start one on the same line as an if or hotkey?
| Code: |
if (1<2){
MsgBox Ok1
}
if 1<2 {
MsgBox Ok2
}
F12::{
MsgBox Ok12
} |
I had a very hard time learning the syntax at first.
I now understand(I think) that if a command for a hotkey is placed on the same line as the hotkey declaration, then it will only use that as a single line command. But if the next line is used, then it is treated as a block and you have to call return?
I kept trying to do things like this and I couldn't understand why the code wouldn't execute:
| Code: |
F11:: if (1<2)
{
MsgBox Ok11
}
|
Orignally my code was more like this, but that doesn't even load becuase of the block rules:
| Code: |
F11:: if (1<2){
MsgBox Ok11
}
|
Also, I found it very strange and a bit furstrating that the documentation for the IF keyword was not under the "Flow of Control" section of the help. I could only find it by clicking Else, then the link to IF, then the link to "IF (expression)" |
|
| Back to top |
|
 |
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10716
|
| Posted: Sat Oct 08, 2005 1:39 am Post subject: Re: More flexible Code Blocks |
|
|
| Peepsalot wrote: | | Can blocks be changed so that it is aceptable to start one on the same line as an if or hotkey? |
It's already on the to-do list but I'll add your specific examples to it.
The particular line above can't be done without the risk of breaking existing scripts.
| Quote: | | if a command for a hotkey is placed on the same line as the hotkey declaration, then it will only use that as a single line command. |
Yes. This is documented in both the Tutorial and the Hotkeys page.
| Quote: | | But if the next line is used, then it is treated as a block and you have to call return? |
It's not a block but rather a new thread. Threads are ended via Return or Exit.
| Quote: | | the documentation for the IF keyword was not under the "Flow of Control" section |
That is an oversight that will be fixed in the next update.
This type of feedback really helps make things better. I hope you'll continue to post ideas as they occur to you (or e-mail them to support@autohotkey.com). Thanks. |
|
| Back to top |
|
|
Dewi Morgan
Joined: 03 Oct 2005
Posts: 186
|
| Posted: Sat Oct 08, 2005 5:35 am Post subject: |
|
|
The "breaking existing scripts" thing is a good point - it would perhaps be an idea to have an option #minversion that would allow really nice but old-script-breaking features to work if the current interpreter is a high enough version?
Though admittedly then you'd have to store a list of features that were added in each version, and test all command combinations to see if they worked for each version, and... eww. OK, maybe not.
Still, I do have to say I'd love
| Code: | key:: {
if (test) {
foo;
}
else {
bar;
}
} |
As a programmer, our coding style is something we become as attached to as our editor. Mine has formed over the years, so that the majority of code I write will work in every language I work in... except AHK.
AHK is great, but it won't be enough for me to change from K&R to OTB, and if it let me use OTB, I'd be a happy puppy.
_________________
Yet another hotkeyer. |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10716
|
| Posted: Sat Oct 08, 2005 6:53 am Post subject: |
|
|
| Dewi Morgan wrote: | | perhaps be an idea to have an option #minversion that would allow really nice but old-script-breaking features to work if the current interpreter is a high enough version? |
That's an interesting approach to an idea I was considering, which is to have something like #v1.5 put alternate rules into effect that are considered high value. One such rule is the elimination of fetching empty variables from the environment, which would eliminate a source of unreliability as someone recently pointed out. It would also allow the program to issue a warning whenever a variable is used without having been assigned a value anywhere (misspelled variable names are probably the single largest source of bugs in scripts).
| Quote: | key:: {
if (test) {
else { |
The "else" one can already be done (in fact, any command can exist on the same line as an "else"). The other two above can be added without breaking existing scripts. It's only when an old-style if-statement is used -- if x < %y% { -- that scripts get broken due to ambiguity.
Thanks for your comments. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
