Can I Set An Event Click on an Input (Textbox)?

[eEniquEe]

Hi,

My problem is that I cannot set an event click on InputBox. I can do it with Buttons, as well as Label, but not InputBoxes. What have I done wrong.. >_< (

Maybe I'm missing something here, but is there a way to go about this problem?

And, I'm also wondering, is there a way to set some other events like MouseOver, or MouseMove, or Changed like it's in VBS?

Here is a short script to demonstrate my problem, I'd like it to display a MessageBox when I click on the Input. But it just never shows up.

#include <ButtonConstants.au3>
#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>
Opt("GUIOnEventMode", 1)
$Form1 = GUICreate("Test Test", 551, 171, 222, 236)
GUISetOnEvent($GUI_EVENT_CLOSE, "Quit")
$Input1 = GUICtrlCreateInput("Click on this zone, and have a MessageBox shown up..", 8, 33, 209, 21)
GUICtrlSetOnEvent($Input1, "Test")
GUISetState(@SW_SHOW)
While 1
    Sleep(500)
WEnd

Func Quit()
    Exit 0
EndFunc

Func Test()
    MsgBox(0, "Test", "You've clicked on an Input")
EndFunc

Thanks very much in advance.

Edited July 26, 2009 by eEniquEe

[Melba23]

eEniquEe,

Here is a way to detect the focus passing to an input - should be pretty easy to modify it to do what you want:

expandcollapse popup

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <EditConstants.au3>

$hGUI = GUICreate("Test", 500, 500)

$hInput = GUICtrlCreateInput("", 10, 10, 200, 20)
$hLabel = GUICtrlCreateLabel("", 10, 50, 200, 20)
$hButton = GUICtrlCreateButton("Press", 10, 80, 80, 30)

GUISetState()

; Catch focus passing to $InputLDescrition
GUIRegisterMsg($WM_COMMAND, "ED_WM_COMMAND")

While 1

    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            Exit
    EndSwitch

WEnd

Func ED_WM_COMMAND($hWnd, $iMsg, $wParam, $lParam)
    #forceref $hWnd, $iMsg
    Local $iCode = BitShift($wParam, 16)
    Switch $lParam
        Case GUICtrlGetHandle($hInput)
            Switch $iCode
                Case $EN_SETFOCUS
                    GUICtrlSetData($hLabel, "Edit has focus")
                Case $EN_KILLFOCUS
                    GUICtrlSetData($hLabel, "Edit does not have focus")
            EndSwitch
    EndSwitch

    Return $GUI_RUNDEFMSG
EndFunc  ;==>ED_WM_COMMAND

M23

[gruntydatsun]

Would a tooltip be good enough if it's only a message?

[eEniquEe]

eEniquEe,

Here is a way to detect the focus passing to an input - should be pretty easy to modify it to do what you want:

expandcollapse popup

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <EditConstants.au3>

$hGUI = GUICreate("Test", 500, 500)

$hInput = GUICtrlCreateInput("", 10, 10, 200, 20)
$hLabel = GUICtrlCreateLabel("", 10, 50, 200, 20)
$hButton = GUICtrlCreateButton("Press", 10, 80, 80, 30)

GUISetState()

; Catch focus passing to $InputLDescrition
GUIRegisterMsg($WM_COMMAND, "ED_WM_COMMAND")

While 1

    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            Exit
    EndSwitch

WEnd

Func ED_WM_COMMAND($hWnd, $iMsg, $wParam, $lParam)
    #forceref $hWnd, $iMsg
    Local $iCode = BitShift($wParam, 16)
    Switch $lParam
        Case GUICtrlGetHandle($hInput)
            Switch $iCode
                Case $EN_SETFOCUS
                    GUICtrlSetData($hLabel, "Edit has focus")
                Case $EN_KILLFOCUS
                    GUICtrlSetData($hLabel, "Edit does not have focus")
            EndSwitch
    EndSwitch

    Return $GUI_RUNDEFMSG
EndFunc  ;==>ED_WM_COMMAND

M23

Hi,

Thanks very much for the reply. I've read the Help file, but I find it to be a little bit complicated. I'll be very appreciated if you can help me out with it. The final part, it reads:

GUIRegisterMsg()

...

Up to 256 user functions can be registered for message ID's.

By default after finishing the user function the AutoIt internal message handler will be proceed.

That won't be if your Return a value (See WM_COMMAND in example) or if you use the keyword 'Return' without any value.

By using 'Return' without any return value the AutoIt internal message handler (if there is one for this message) will NOT be proceed!

!!! If you want AutoIt to run it's internal handler for a message, return the variable $GUI_RUNDEFMSG (in GUIConstantsEx.au3) from the function (see also examples) !!!

I.e. if you want to return earlier than the user function ends and also proceed the AutoIt internal message handler.

Warning: blocking of running user functions which executes window messages with commands such as "Msgbox()" can lead to unexpected behavior, the return to the system should be as fast as possible !!!

'By default after finishing the user function the AutoIt internal message handler will be proceed'. What's an 'internal message handler'? Does it means that, after finishing the function (which in your example is ED_WM_COMMAND), then it'll return to where it left before jumping to the function ED_WM_COMMAND, and continues? Just like what it does in HotKeySet?

'Warning: blocking of running user functions which executes window messages with commands such as "Msgbox()" can lead to unexpected behavior, the return to the system should be as fast as possible': The return to the system should be as fast as possible.. :-ss Does that means I must make my function as 'short' as possible, and if my function is 'long' enough, it'll do something harmful? @.@ Is it that serious?.. :-ss :-ss

I'm also concern about the 2 parameters $wParam, and $lParam. As I understand it, the $lParam will tell you the Handle of the Control, which has currently got focus? And how about $wParam? From your piece of code, I can know that, if you right-shifted $wParam 16, then it'll tell you the state of focus of the Control, whose Handler is $lParam. Am I right there? But if you don't right-shift it, then what information does $wParam contain?

And also this line '#forceref $hWnd, $iMsg'. I'm guessing that you don't use those two parameters, so, you're freeing them. So #forceref Var1, Var2, blah blah blah.. is used to free the memory of unused variables inside the function, right? >_<

Sorry for many questions, I just want to make sure that I really grab the concept.

Once again thanks for your help, Melba.

Would a tooltip be good enough if it's only a message?

Well, it's just a test piece of code. Right? =.=" Edited July 27, 2009 by eEniquEe

[Melba23]

eEniquEe,

I will try and answer your questions as best I can, but as I am only a hobbyist coder, I apologise in advance if my explanations are less than satisfactory!

1. Return $GUI_RUNDEFMSG. As I understand it, AutoIt processes Windows messages like all ather Windows applications. After all, that is the function of the messages - to let all apps know what is going on. So if you do not return the $GUI_RUNDEFMSG constant, AutoIt does not process the message itself and it is as if the message was never sent as far as Autoit is concerned. I have checked my scripts and I have always returned it - probably because that is how I saw my first GUIRegisterMsg function and I never thought to change it! As to returning to the same place, my understanding is that a registered Message behaves exactly like a HotKey - the script is suspended while the message is processed and then resumes. All this is completely transparent to the user and to your code.

2. The return to the system should be as fast as possible. This is a serious warning - your script can and will hang if you do not make a swift return. I try never to have more than a few lines of code within the registered function. I have also found that many AutoIt commands do not work within the function (ConsoleWrite, for example). What I often do is to set a Global flag variable within the function, check within my GUIGetMsg loop to see if the flag is set, and then run the complicated stuff as a normal function.

3. The parameters. You must have the 4 parameters in your GUIRegisterMsg call - what gets into them depends on the call, it is different for each one and you need to check MSDN to confirm the actual values. I freely admit that most of my message functions are lifted from other code on the forums and I just copy the necessary BitShifts, etc to get the required results! >_<

4. #forceref. This directive is from Tyler's Au3Check syntax checker and it prevents warnings about parameters being "declared but not used" in functions. I do not believe it has any effect on the actual memory used by AutoIt, it merely prevents Au3Check from posting a warning. So I always add it to cover those parameteres which are not used by that particular message. Certainly it has no effect on your code - you can omit it without problem. I just prefer to have no warnings when I test run my code in SciTE - then if I change something and an error occurs, it is immediately obvious rather then hidden within a plethora of unimportant warnings.

I hope that the above is useful. One of the real gurus might come across this post and further illuminate us - but if you want more detail, I would suggest opening a new topic and asking directly. Certainly I have been able to use the GUIRegisterMsg function perfectly satisfactorily with just the knowledge above.

M23

[eEniquEe]

I will try and answer your questions as best I can, but as I am only a hobbyist coder, I apologise in advance if my explanations are less than satisfactory!

Oh, me too. I just code for fun, and just to kill some time. My major is Maths, btw. It's summer here. So, I've plenty of free time. And, don't worry, your reply is more than what I need. Thanks a lot for your help. I'll do some further testing to make sure that I fully understand it.

2. The return to the system should be as fast as possible. This is a serious warning - your script can and will hang if you do not make a swift return. I try never to have more than a few lines of code within the registered function. I have also found that many AutoIt commands do not work within the function (ConsoleWrite, for example). What I often do is to set a Global flag variable within the function, check within my GUIGetMsg loop to see if the flag is set, and then run the complicated stuff as a normal function.

Oh, this is brilliant. I know sometimes I should really think outside of the box. >.<

Thanks for your help, Melba. >_<