Sign in to follow this  
Followers 0
eEniquEe

Question on RegisterMessage

10 posts in this topic

#1 ·  Posted (edited)

Hi everyone,

I've found which concerns about formatting numbers as the user's inputing it. And to tell the truth, I find it very very interesting. One way to solve that problem is to use GUIRegisterMsg(). I really want to play around with GUIRegisterMsg a bit, so I come up with this little piece of code:

; Credit to Valik for the DllCall lines

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

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

Global $hInput = GUICtrlCreateInput ("", 10,  20, 300, 20)
Global $hInput2 = GUICtrlCreateInput ("", 10,  40, 300, 20)

GuiSetState(@SW_SHOW)

GUIRegisterMsg($WM_COMMAND, "_WM_COMMAND")
$State = 0

While 1
    If GUIGetMsg() = $GUI_EVENT_CLOSE Then Exit
    ;Sleep(100)
WEnd

Func _WM_COMMAND($hWnd, $iMsg, $wParam, $lParam)

    #forceref $hWnd, $iMsg, $lParam

    Local $iIDFrom = BitAND($wParam, 0xFFFF);LoWord
    Local $iCode = BitShift($wParam, 16)    ;HiWord
    If $iIDFrom = $hInput Then
        If $iCode = $EN_KILLFOCUS Then
            If GUICtrlRead($iIDFrom) = "" Then
                GUICtrlSetFont($iIDFrom, 8.5, 400, 2)
                GUICtrlSetData($iIDFrom, "Please enter your input here...")
                $State = 0
            Else
                $State = 1
            EndIf
        Else
            If $iCode = $EN_SETFOCUS Then
                If $State = 0 Then
                    GUICtrlSetFont($iIDFrom, 8.5, 400, 0)
                    GUICtrlSetData($iIDFrom, "")
                EndIf
            EndIf
        EndIf
    EndIf

EndFunc;==>_WM_COMMAND

The basic idea is that, if the user leave the first inputbox blank, the text will be change to 'Please enter your input here...'; and if otherwise, nothing is done.

What I want to ask is that, that piece of code runs smoothly if I commence out the Sleep(100) part. But if I don't, then when I try to close the window, it usually takes up to 5-6 seconds to do so. I wonder what has really happened? I did read the Help File and it points out that:

"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 !!!"

And I think this may be the reason, but there's no part in the code that may cause a block, except from that Sleep statement, but again, the Sleep statement is not placed inside the function. Maybe I'm missing something here. :huh2:

Thanks a lot in advance,

And have a good day, ;)

Edited by eEniquEe

Share this post


Link to post
Share on other sites



that is because GUIGetMsg() has a sleep on it.. if you use GUIGetMsg() function you dont need sleep at all.

Share this post


Link to post
Share on other sites

that is because GUIGetMsg() has a sleep on it.. if you use GUIGetMsg() function you dont need sleep at all.

But putting a Sleep(100) there slows the terminating process by 5-6 seconds. I think there must be something wrong here, a 1/10 second sleep cannot add up that much amount.

Share this post


Link to post
Share on other sites

I dont know how GUIGetMsg() works internaly but the help file says..

This function automatically idles the CPU when required so that it can be safely used in tight loops without hogging all the CPU.

so why questioning that?

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

I'm very sorry, but I'm still unsatisfied with that answer. :huh2: And btw, I'm asking about GUIRegisterMsg, not GUIGetMsg... What if my Main Loop needs some Sleep(), like pausing between Loops to do some image animation?

And yes, I don't know how GUIRegisterMsg works either, so I'm asking about that. I'm still not sure what you mean by 'why questioning that'? I don't know something, and I want to learn it, so I'm asking questions. Am I violating something here? I'm asking one thing, and you're replying another thing, and tell me to accept that answer. How come?

It seems to me that GUIRegisterMsg drives my program to continue looping for like 50-60 times before actually execute my Closing command. It's up to 60 times, don't you see that it's a little bit too much?

Edited by eEniquEe

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

i think that the problem is in the main loop, and not in GUIRegisterMsg(), as you said if you remove the sleep() the script closes well and recive the events... about the image animation i never do in that way... sorry if i´ve been a little rude that never was my intent.

Edited by monoscout999

Share this post


Link to post
Share on other sites

eEniquEe,

As monoscout999 has suggested, the delay is entirely due to the Sleep function in the While...WEnd loop - there is abolutely nothing wrong with your message handler. :huh2:

I too get a delay when trying to close the GUI when that line is uncommented - although nowhere near 5-6 seconds. As was explained, GUIGetMsg allows its own idle period when called - Jon programmed it so that if the system is busy this can be as long as 10-12 ms, if the system is idle it waits only a very short time. So the additional Sleep line merely makes the whole GUI become completely unresponsive during the Sleep delay time - no events of any kind are queued. Increase the delay to Sleep(1000) and then try and close your GUI - it will take you quite a few clicks until you happen to hit on the short moment when GUIGetMsg is active between the Sleep periods. :alien:

All clear now? Please ask again if not. ;)

M23


Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind._______My UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Share this post


Link to post
Share on other sites

eEniquEe,

As monoscout999 has suggested, the delay is entirely due to the Sleep function in the While...WEnd loop - there is abolutely nothing wrong with your message handler. :huh2:

I too get a delay when trying to close the GUI when that line is uncommented - although nowhere near 5-6 seconds. As was explained, GUIGetMsg allows its own idle period when called - Jon programmed it so that if the system is busy this can be as long as 10-12 ms, if the system is idle it waits only a very short time. So the additional Sleep line merely makes the whole GUI become completely unresponsive during the Sleep delay time - no events of any kind are queued. Increase the delay to Sleep(1000) and then try and close your GUI - it will take you quite a few clicks until you happen to hit on the short moment when GUIGetMsg is active between the Sleep periods. :)

All clear now? Please ask again if not. ;)

M23

Hi Melba,

Thanks for your explanation. I think I get it now. I'm sorry, I thought that it's my handler making some kind of extra loops, and so it delays the closing time. But well, now I got it. :mad2:

Btw, I still have some more questions regarding Message Handling Process. I hope you guys can help me out.

  • First of all, I'd like to determine if some specific Inputbox is focus, and the user hit the RETURN key. I can do this with a combination of the above process (for checking which InputBox's currently being focused) and _IsPressed function. But is there anyway that I can achieve that using MessageHandler purely?
  • Secondly, is there any way that I can catch a Message when the mouse is over some Label (like MouseOver event in Visual Basic)? For somehow I just cannot find this piece information in the Help File. :ph34r:

Thanks very much for your help, :alien:

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

for the second you have to use GuiGetcursorinfo(), for the first thing i`ve doing some test but nothing yet

; Credit to Valik for the DllCall lines

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

global $OldData, $check
Global $State
Global $hGUI = GUICreate("Test", 500, 500)

Global $hInput = GUICtrlCreateInput ("", 10,  20, 300, 20)
Global $hInput2 = GUICtrlCreateInput ("", 10,  40, 300, 20)

GuiSetState(@SW_SHOW)

GUIRegisterMsg($WM_COMMAND, "_WM_COMMAND")
GuiRegisterMsg($WM_KEYDOWN, "_WM_KEYDOWN")
$State = 0

While 1
    If GUIGetMsg() = $GUI_EVENT_CLOSE Then Exit
    $aMouse = GUIGetCursorInfo()
    If @error then continueloop
    Select
        case $aMouse[4] = $hInput
            If $check = true Then
                $OldData = GuiCtrlread($hInput2)
                GUICtrlSetData($hInput2, "Mouse Hover $hInput...")
                $check = False
            EndIf
        case else
            If $check = false Then
            GUICtrlSetData($hInput2, $OldData)
            $check = true
        EndIf
    Endselect
WEnd
Func _WM_KEYDOWN($hWnd, $iMsg, $wParam, $lParam)

    Consolewrite($hWnd&@CRLF)
    Consolewrite($iMsg&@CRLF)
    Consolewrite($wParam&@CRLF)
    Consolewrite($lParam&@CRLF)
    
EndFunc

Func _WM_COMMAND($hWnd, $iMsg, $wParam, $lParam)

    #forceref $hWnd, $iMsg, $lParam

    Local $iIDFrom = BitAND($wParam, 0xFFFF);LoWord
    Local $iCode = BitShift($wParam, 16)    ;HiWord
    If $iIDFrom = $hInput Then
        If $iCode = $EN_KILLFOCUS Then
            If GUICtrlRead($iIDFrom) = "" Then
                GUICtrlSetFont($iIDFrom, 8.5, 400, 2)
                GUICtrlSetData($iIDFrom, "Please enter your input here...")
                $State = 0
            Else
                $State = 1
            EndIf
        Else
            If $iCode = $EN_SETFOCUS Then
                If $State = 0 Then
                    GUICtrlSetFont($iIDFrom, 8.5, 400, 0)
                    GUICtrlSetData($iIDFrom, "")
                EndIf
            EndIf
        EndIf
    EndIf

EndFunc;==>_WM_COMMAND
Edited by monoscout999

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

Ah yes, thanks for your reponse. :mad2:

I didn't look in the Help File thoroughly, that's my bad. I'm sorry. :alien:

Thanks again, :blink:

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

So one problem left is, is it possible to catch the RETURN key when some InputBox is focused?

Thanks, :huh2:

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

P.S: OMG, my Internet connection today is sssssooooo sssssssllloooowwwwww.

I'm very sorry. But I have one more question. :ph34r: I'm pretty new to these Message Handler, so please bear with me. :)

I'm making some Mathematical Game, it's about fast calculation, i.e, to sharpen your calculation ability. Students in my country relies on calculators more and more heavily these recent years. And as a teacher, I think I should do something to make this situation better. So the Game basically will go like this:

  • It'll create label with random expression, and the label will fly up as time goes by.
  • The student' will have to click on the label, then supply the correct result for that expression.

My question is that, when moving labels up, they'll blink; is there any way to tell the window to stop redrawing until I tell it to do so? On searching the Help File, I come up with this: $tagWINDOWPOS, it has one flas saying that '$SWP_NOREDRAW - Does not redraw changes' but I don't know how to apply it.

Should I use DllStructCreate?

Thanks you guys very much. ;)

Edited by eEniquEe

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  
Followers 0