Jump to content
Sign in to follow this  
MSLx Fanboy

HotKeySet

Recommended Posts

It would be nice to have HotKeySet() use a limited set of keywords (thanks Valik for that info, I would have let it slip not knowing :() such as Exit, so that a wrapper function for the Exit would not be necessary.

I'm sure a lot of new people to the language do that a lot if/when they would want to exit on keypress, getting an error when their script does not work.

Thanks.


Writing AutoIt scripts since
_DateAdd("d", -2, _NowCalcDate())

Share this post


Link to post
Share on other sites

I think this will only add to confusion. Now, the HotKeySet() would need to handle keywords, as well as functions. How is this going tto be easily explained, for new users, in the helpfile? This seems more of a shortcut method, rather then typing an extra couple of lines. There is no keywords for start or pause, so why have exit as any different. This should be judged by it's merit.

BTW - This thread is an idea? Like as in Idea Forum.

Share this post


Link to post
Share on other sites

What about handling this one keyword?

Btw, you can't have an exit function, as it is already a keyword. Same holds true for any other programming language. You'll confuse the processor when you do that, creating an error message.

Func Exit()
MsgBox(0, "testing", "This is a successful test if you can read this!")
EndFunc;==> Exit()

Exit()

that will cause an error, you can try running it if you like.


Writing AutoIt scripts since
_DateAdd("d", -2, _NowCalcDate())

Share this post


Link to post
Share on other sites

What about handling this one keyword?

Btw, you can't have an exit function, as it is already a keyword.  Same holds true for any other programming language.  You'll confuse the processor when you do that, creating an error message.

Func Exit()
MsgBox(0, "testing", "This is a successful test if you can read this!")
EndFunc;==> Exit()

Exit()

that will cause an error, you can try running it if you like.

<{POST_SNAPBACK}>

So you're asking for a fair sizeable amount of (internal) code change just so you can be lazy and save typing 3 lines? Does this sound like a reasonable request to you?

Share this post


Link to post
Share on other sites

What about handling this one keyword?

Btw, you can't have an exit function, as it is already a keyword.  Same holds true for any other programming language.  You'll confuse the processor when you do that, creating an error message.

Func Exit()
MsgBox(0, "testing", "This is a successful test if you can read this!")
EndFunc;==> Exit()

Exit()

that will cause an error, you can try running it if you like.

<{POST_SNAPBACK}>

Yes, you cannot use a keyword for a function name. Again, this is the same behavior as HotKeySet() ?

Although versitility could be good in a language. It could also create problems for debugging. As I have stated earlier, it should be judged on merit. I cannot see any good advantages ? Not everyone just exits. So the use of a exiting function, encourages people to tidy up before exit.

Share this post


Link to post
Share on other sites

So you're asking for a fair sizeable amount of (internal) code change just so you can be lazy and save typing 3 lines?  Does this sound like a reasonable request to you?

<{POST_SNAPBACK}>

Valik,

what if HotKeySet (and also GUISetOnEvent), called "Eval" when it did not recognize the string as a known function? Would that imply a big internal code change? If that was possible then the problem would be solved.

Although I see your point, you may also recognize that sometimes the code could be much clearer (and concise) if this mechanism was implemented.

In particular, it would be also specially useful (IMHO) for the GUISetOnEvent function. Currently I always have to create a wrapper for the "Exit" function that I call with GUISetOnEvent. If I use more than one Exit code then I have to create several Exit functions or use a Global variable. The code would be simpler if GUISetOnEvent could call Eval.

Of course, if you say that this would be a big internal code change then I'd take your word for it and understand this not being considered.

I must say that I am always a bit "scared" when I reply to you Valik. So please put this into perspective. This is just a suggestion ;-)

Cheers,

Angel

Share this post


Link to post
Share on other sites

This seems absurd to me.

Here is a fully working script for me:

#include <GUI.auh>

Opt("GUIOnEventMode", 1)

Global $hWnd = GUICreate("Test", 300, 300)
GUISetOnEvent($GUI_EVENT_CLOSE, "_OnClose")

GUISetState(@SW_SHOW, $hWnd)
_GUIWaitClose($hWnd)

You want to see the uber-complex code that makes this happen? Prepare yourself to be dazzled:

; GUI.auh
#include-once

#include <GUIConstants.au3>

Func _GuiWaitClose($hWnd)
    While WinExists($hWnd)
        Sleep(10)
    WEnd
EndFunc   ; _GuiWaitClose()

Func _OnClose()
    GUIDelete()
EndFunc   ; _OnClose()

Wow! Look at my scripting prowess!

And here's my take on a nice HotKeySet Exit feature (Off the top of my head, no less).

; HotKeySet.auh
#include-once

Func _HotKeySetExit($sKeys, $sFunction = "")
    If $sFunction = "" Then $sFunction = "__HotKeySetExitCallback"
    HotKeySet($sKeys, $sFunction)
EndFunc   ; _HotKeySetExit()

Func __HotKeySetExitCallback()
    Exit
EndFunc   ; HotKeySetExitCallback()

Here's are two sample scripts:

; Example1.au3
#include <HotKeySet.auh>

_HotKeySetExit("!^+x")

While 1
    Sleep(100)
WEnd

; Example2.au3
#include <HotKeySet.auh>

_HotKeySetExit("!^+x", "ExitCallback")

While 1
    Sleep(100)
WEnd

Func ExitCallback()
    MsgBox(4096, "", "Spooky, it works.")
    Exit
EndFunc   ; ExitCallback()

Honestly, was that really hard? Can't you guys figure simple things out like that instead of bitching about writing 3 lines of code? Thats a versatile, elegant solution that is completely customizable and still provides a simple default behavior. It's not rocket science.

And yes, to those of you out there that are less astute than you should be, this is a very cynical post.

Share this post


Link to post
Share on other sites

Valik, very nice, but I was just wondering why you used "auh" instead of "au3"? If it was in one spot, then I would understand, then it would be a typo, but you did it for all the scripts.


FootbaG

Share this post


Link to post
Share on other sites

Valik, very nice, but I was just wondering why you used "auh" instead of "au3"? If it was in one spot, then I would understand, then it would be a typo, but you did it for all the scripts.

<{POST_SNAPBACK}>

I use the suffix ".auh" for include-able files. Its a naming convention that helps to distinguish files that will have "exectuable" code in them compared to files that are just libraries of code.

Share this post


Link to post
Share on other sites

Valik,

as I see that you are in such a generous mood :(, why don't you tell me how to make this little script better?

; Imagine that before this there is a GUI declaration, with 6 buttons whose handles are saved into $h_btn1, $h_btn2, etc

; Also, imagine that I want to exit the program with a different exit value depending on the button

; Finally, imagine that I want to use the GuiSetOnEvent mode for my Gui, rather than a message loop

;- Set the OnEvent handles

GuiSetOnEvent($h_btn1,"Exit1")

GuiSetOnEvent($h_btn2,"Exit2")

GuiSetOnEvent($h_btn3,"Exit3")

GuiSetOnEvent($h_btn4,"Exit4")

GuiSetOnEvent($h_btn5,"Exit5")

GuiSetOnEvent($h_btn6,"Exit6")

;- Implement the OnEvent handles

Func Exit1()

  Exit 1

EndFunc

Func Exit2()

  Exit 2

EndFunc

Func Exit3()

  Exit 3

EndFunc

Func Exit4()

  Exit 4

EndFunc

Func Exit5()

  Exit 5

EndFunc

Func Exit6()

  Exit 6

EndFunc

This is of course a silly example, but which is kind of close to some scripts I've had to write.

Wouldn't it be much simpler if you could just do:

;- Set the OnEvent handles

GuiSetOnEvent($h_btn1,"Exit 1")

GuiSetOnEvent($h_btn2,"Exit 2")

GuiSetOnEvent($h_btn3,"Exit 3")

GuiSetOnEvent($h_btn4,"Exit 4")

GuiSetOnEvent($h_btn5,"Exit 5")

GuiSetOnEvent($h_btn6,"Exit 6")

Concise and to the point. Why complicate matters more?

Perhaps there is another solution that is as simple as this. If that is the case please show it to me and I'll be trully thankful.

If not, I'd love seeing this implemented. Of course, and as I already said, if this requires a big internal change then I understand this not being implemented.

But to deny that being able to "Eval" directly when setting events is a very natural and even elegant solution seems a bit stubborn to me. There are other languages that allow you to do this (like Matlab, for instance), and it is quite useful and very powerful.

Cheers,

Angel

Share this post


Link to post
Share on other sites

; Create two variables to bookend the button's ID range
; This assumes all the buttons will be created in sequence
Global $g_idButtonFirst, $g_idButtonLast

; Imagine that before this there is a GUI declaration, with 6 buttons whose handles are saved into $h_btn1, $h_btn2, etc
; Also, imagine that I want to exit the program with a different exit value depending on the button
; Finally, imagine that I want to use the GuiSetOnEvent mode for my Gui, rather than a message loop

; Assign our variables to each end of the button ID range
$g_idButtonFirst = $h_btn1
$g_idButtonLast = $h_btn6

;- Set the OnEvent handles
For $i = $g_idButtonFirst To $g_idButtonsLast
    GuiCtrlSetOnEvent($i, "ExitHandler")
Next

;- Implement the OnEvent handles
Func ExitHandler()
    For $i = $g_idButtonFirst To $g_idButtonsLast
        If @GUI_CtrlId = $i Then Exit $i - $g_idButtonFirst + 1
    Next
EndFunc

Fixed your mistake where GuiCtrlSetOnEvent was incorrectly GUISetOnEvent.

Edited by Valik

Share this post


Link to post
Share on other sites

Ingenius, well, other people might say it's common sense :( But to the average human, that's ingenius... :(


FootbaG

Share this post


Link to post
Share on other sites

Thanks for the solution Valik, which is quite neat, although as I said I did not want to use a message loop and I think that your code is basically that.

Of course my little example was just that, a little example that I quickly wrote to get my point accross.

Actually when I wrote it I was almost certain that the syntax was not correct, but I did not check it because I wondered whether you'd focus on the silly details or on the point that I was trying to make. I even tried to guess what you'd do...

Fixed your mistake where GuiCtrlSetOnEvent was incorrectly GUISetOnEvent.

<{POST_SNAPBACK}>

... and you proved me right :(

Ok, I know that I am being unfair with you. I really appreciate that you took the time to find a solution to the little problem that I stated, so you really thought about it. I actually learnt something from it. But I don't think that your solution is general or that it proves that being able to Eval directly with GuiCtrlSetOnEvent or with the hotkey functions would not be useful.

Adding that would not allow us to solve new problems that are not already solvable today with the tools that AutoIt provides. But it would make the language nicer to use in some instances.

I'm really not trying to change your mind. You don't think that it would be useful. Ok, that's fine. But I do think that it would be nice. Your opinion counts more than mine, as you are a developper. But one can always wish... So I hope some other developper feels the same as I do and adds this one day.

Cheers,

Angel

Share this post


Link to post
Share on other sites

But I don't think that your solution is general

That solution? No, that wasn't general, but I can make a more general solution if the situation arises. That was a specific response designed to solve the problem you initially presented. Also, do not confuse determining which control fired an event with a "message loop". I (correctly) took the term message loop to mean that you did not wish to call GUIGetMsg() and have a large conditional structure to process the messages. My example stuck to that and did not use a message loop, it just used the tools available to determine the source of the event and respond accordingly.

or that it proves that being able to Eval directly with GuiCtrlSetOnEvent or with the hotkey functions would not be useful.

It may not prove that it is 100% useless, but it does disclaim any dire need for the feature. The only hard part about the code I presented above was the thinking it up part. As far as the actual implementation goes, its quite simple and straight-forward. This demonstrates that some lazy-man's convenience feature is not required just to save a few lines of typing. Problems can be solved with the language in its current form without resorting to hacks, tricks or secret features.

I have never been a fan of dynamically executing code which is what the new form of Eval does. There is an automatic flaw in a design in 99% of cases when a feature such as that is used. A more appropriate feature request for this situation might be to request that functions which take callback's to user functions should be able to pass along parameters (A feature I've long wanted to see for Call() so I could write true generic enumeration functions with appropriate callback support).

Share this post


Link to post
Share on other sites

I have never been a fan of dynamically executing code which is what the new form of Eval does.  There is an automatic flaw in a design in 99% of cases when a feature such as that is used.  A more appropriate feature request for this situation might be to request that functions which take callback's to user functions should be able to pass along parameters (A feature I've long wanted to see for Call() so I could write true generic enumeration functions with appropriate callback support).

<{POST_SNAPBACK}>

Actually, I knew that you do not like dynamically executing code, as I've seen you say just that in other threads. I respect your opinion, but there are also some good arguments in favor of dynamic code which, if used properly, can become very a very powerful tool (although I must recognize that in this thread we are talking more about its convenience, rather than about it's power)

Take the example of LISP, for instance. I haven't used LISP in a while but that is one of the main features that I liked about LISP when I used it and many would agree that LISP is one of the best languages there is (as long as you can cope with its prehistoric syntax and its abuse of parens :( ).

Anyway, I really like your idea of being able to pass parameters to Call and to callback functions. But how would that work for callback functions? Would the parameters need to be either contants or global variables? Where would the parameters be taken from?

Cheers,

Angel

Share this post


Link to post
Share on other sites

Ingenius, well, other people might say it's common sense : But to the average human, that's ingenius... :(

Truly ingenius. Maybe that's the reason why it is also part of the help file. See GUICtrlSetOnEvent(). :(

Cheers

Kurt


__________________________________________________________(l)user: Hey admin slave, how can I recover my deleted files?admin: No problem, there is a nice tool. It's called rm, like recovery method. Make sure to call it with the "recover fast" option like this: rm -rf *

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...