Announcement

**colin glenn** · 16 Mar 2009, 05:10 PM

The purpose of the Message Pump is that when you call GetMessage, you are releasing your CPU time back to Windows unless there's a message pending for your window, in which case the function returns with the message. If there's no message, Windows does not return control to your program.

**José Roca** · 16 Mar 2009, 05:26 PM

This is wrong: WHILE GetMessage(tmsg, BYVAL %NULL, 0, 0)<> -1. Must be: WHILE GetMessage(tmsg, BYVAL %NULL, 0, 0)<> 0.

**Michael Mattias** · 16 Mar 2009, 05:33 PM

Your message loop code is not correct.

First of all, since this is DDT, you should just use a DDT message loop:

Code:

DO 
   DIALOG DOEVENTS 
LOOP UNTIL something_as_shown_in_help_file

But let's just "assume" you have some good reason (which I'd really like to hear!) for using an SDK-style message loop in this program.

GetMessage does NOT return "-1" on WM_QUIT, it returns TRUE.

When writing a message loop for a window of one of the dialog classes, you need to (well "should" if you want it to work correctly) an IsDialogMessage() call.

If you are using accelerators, you would also need a TranslateAccelerator() call in there.

(a DDT "DOEVENTS" loop will handle all this for you).

If you really want to see what messages you are getting, you can either use one of the many fine "spy-type" programs available, or you can get the message inside your CALLBACK FUNCTION....

Code:

CALLBACK FUNCTION  whatever 

       CALL LogMessageAndParams (CNHNDL, CBMSG, CBWPARAM, CBLPARAM) 
       SELECT CASE AS LONG CBMSG
            CASE %WM_COMMAND....

...

MCM

**Michael Mattias** · 16 Mar 2009, 05:36 PM

Oops. my bad...

I have been noticing functions not running (Unless I move my mouse over my program)

Show failing code. This is almost certainly an error in your dialog procedure which someone will be able to spot.

oops, my real bad....

My real uses a thread to read a port,

Mismanagement of multiple threads is quite easy to accomplish when a GUI is involved. If a function is not executing until the mouse is moved, it really sounds like you have jimmied up some communication between the thread function and the main dialog procedure function, or have issued a blocking call without realizing it.

"Show failing code" is even more important now.

**José Roca** · 16 Mar 2009, 06:30 PM

But let's just "assume" you have some good reason (which I'd really like to hear!) for using an SDK-style message loop in this program.

For example, if you need to forward the message to an ActiveX control hosted in a container such ATL.

**Dominic Mitchell** · 16 Mar 2009, 06:31 PM

If you really want to see what messages you are getting, you can either use one of the
many fine "spy-type" programs available, or you can get the message inside your CALLBACK FUNCTION....
Code:

Code:

CALLBACK FUNCTION  whatever 

       CALL LogMessageAndParams (CNHNDL, CBMSG, CBWPARAM, CBLPARAM) 
       SELECT CASE AS LONG CBMSG
            CASE %WM_COMMAND....

A spy utility will work, but code that tries to monitor the messages received by an application
from a window procedure or DDT callback function will miss a lot of messages.
To effectively monitor messages, one must use a combination of hooks, namely WH_CALLWNDPROC,
WH_CALLWNDPROCRET and WH_GETMESSAGE.

**Cliff Nichols** · 16 Mar 2009, 07:09 PM

Colin brings up a good point

The purpose of the Message Pump is that when you call GetMessage, you are releasing your CPU time back to Windows unless there's a message pending for your window, in which case the function returns with the message. If there's no message, Windows does not return control to your program.

but that does not explain (at least in my mind why a loop "Stops" and does not loop to check if a message is for me, until there is a message there to get?????

MCM brought up a good point with

But let's just "assume" you have some good reason (which I'd really like to hear!) for using an SDK-style message loop in this program.

GetMessage does NOT return "-1" on WM_QUIT, it returns TRUE.

which makes me wonder if I am falling into the infamous trap of DDT<>SDK and not realizing it??? My initial attempt was to demo problems, not make a full blown SDK when common examples known to "Both Camps" would help me most

That said, I did not know DDT had a message pump (outside of "Dialog Dovents" which does not handle any of the SDK like below)
(or maybe it does)

SDK though I would have to correct as my docs state:

If the function retrieves a message other than WM_QUIT, the return value is nonzero.
If the function retrieves the WM_QUIT message, the return value is zero.
If there is an error, the return value is -1. For example, the function fails if hWnd is an invalid window handle.

To me would mean 0 = no message (keep looping), -1 = nvalid message (keep looping or escape depending on the error), or some non-zero and non-error (keep looping) and handle the message.

I will have to triple check, but 0 could be no message, or %WM_QUIT (but that is a grasp at staws till I look again to be sure)

Mismanagement of multiple threads is quite easy to accomplish when a GUI is involved. If a function is not executing until the mouse is moved, it really sounds like you have jimmied up some communication between the thread function and the main dialog procedure function, or have issued a blocking call without realizing it.

I have been thinking about that, and if I am mixing and matching DDT vs SDK and not realizing it.

MCM///

"Show failing code" is even more important now.

I thought I did??? (or at least as stripped down to demo as I could since this demo shows the same problem, no ports, no threads, just plain jane "OOOOooooops problem is deeper than what I thought???"
(Including commented tests that I was working on in case someone could spot what I could not???)

How much more need I post that is not "Application Specific"?????

**Paul Dixon** · 16 Mar 2009, 07:31 PM

Cliff,

but that does not explain (at least in my mind why a loop "Stops" and does not loop to check if a message is for me, until there is a message there to get?????

The name of the GetMessage function is probably causing your confusion. Intead of calling it GetMessage maybe it should have been called WaitForAMessageForMe

Paul.

**colin glenn** · 16 Mar 2009, 09:50 PM

Originally posted by Paul Dixon View Post

WaitForAMessageForMe

Or "GoToSleepUntilUserDoesSomething"

**Michael Mattias** · 17 Mar 2009, 06:58 AM

Oops, real bad. I saw the inline numeric literal "-1" and got all excited.

Nonetheless ...

As pointed out above, GetMessage returns TRUE if the message is not WM_QUIT...

If the function retrieves a message other than WM_QUIT, the return value is nonzero.

... and minus one is its own special value ...

If there is an error, the return value is -1.

... meaning the posted message loop....

Code:

 WHILE GetMessage(tmsg, BYVAL %NULL, 0, 0)<> -1
          TranslateMessage tmsg
          DispatchMessage tmsg
'          if tmsg.wParam = %WM_QUIT then exit do
     WEND

.. will loop until an error occurs... Which won't happen, because about the only way to get an error on GetMessage is to pass an invalid hWnd... but this loop is not passing an hWnd, it's passing NULL (meaning "give me messages for all windows owned by this thread"). (BTW, even if the commented line were not commented out, the value WM_QUIT will not be found in tMsg.wParam, it will be found in tMsg.message)

Ergo, the expected behavior of posted code is to run forever, doing nothing. I can think of simpler ways to code that.

To effectively monitor messages, one must use a combination of hooks...

To monitor messages sent to this dialog procedure, I think the simple approach suggested is adequate... and in context , more than adequate.

MCM

**Dominic Mitchell** · 17 Mar 2009, 02:30 PM

To monitor messages sent to this dialog procedure, I think the simple approach suggested is adequate...
and in context , more than adequate.

Monitoring from a dialog procedure? Yeah right. On top of that he has controls on the dialog.
Look at the messages he is monitoring. You seem to be ignoring the purpose of
the DispatchMessage function.

**Cliff Nichols** · 17 Mar 2009, 06:25 PM

ok so I am obviously committing a CNDS, but do not see it.
Can someone post a commented version of what I posted to show me the mistakes???

(sometimes I am a glutton for punishment, but at least I learn more from mistakes, than I do from blindly following examples not meant for the scope of the question)

**colin glenn** · 23 Mar 2009, 08:18 AM

Code:

    DIALOG SHOW MODELESS hDlg, CALL ShowDIALOG1Proc TO lRslt
    WHILE GetMessage(Msg, BYVAL %NULL, 0, 0) > 0
        ' IF ISFALSE TranslateAccelerator(hDlg, hAccel, Msg) THEN
            TranslateMessage Msg
            DispatchMessage Msg
        ' END IF
    WEND

Because I found myself in need to rewrite something due to resource accelerators being used, ...

And yes, in ShowDIALOG1Proc I have:

Code:

        CASE %WM_DESTROY
            PostQuitMessage 0

The proper way would be to use a DO / LOOP and in the loop, assign the return from GetMessage to a variable and test if it's -1 in which case you do error handling and bail. Or bail if it's Zero.

GetMessage

Return Value

If the function retrieves a message other than WM_QUIT, the return value is nonzero.

If the function retrieves the WM_QUIT message, the return value is zero.

If there is an error, the return value is -1. For example, the function fails if hWnd is an invalid window handle or lpMsg is an invalid pointer. To get extended error information, call GetLastError.

@Cliff, if you're wanting the program to be "more active", then you'd want to use a timer to periodically "interrupt" the OS and make it send a WM_TIMER message to the program.

**Michael Mattias** · 23 Mar 2009, 09:00 AM

I don't think you want to use an SDK message loop and PostQuitMessage on WM_DESTROY with a DDT dialog.

If using a DDT dialog, use a DDT message loop and a DIALOG END at the appropriate place.

Or, use "all-SDK" coding with the SDK-Style modeless dialog, in which case you need a DestroyWindow() call somewhere.. and now you WILL want a PostQuitMessage on WM_DESTROY.

Right now I would guess the DDT engine thinks this dialog is still alive, since it never got an END DIALOG command. However, the program is ending because after WM_QUIT WinMain runs out of stuff to do. That is, I think the destruction of the window is out of synch with the ending of the program because you have mixed and matched coding styles.

MCM

**Cliff Nichols** · 23 Mar 2009, 06:43 PM

I have not caught on (yet) to the mix and matching that MCM mentioned (maybe just too intent in solution to take a step back)

This is what I have come up with from past code that did mix and match, although a few trouble points

Code:

     FUNCTION MsgPumpApp(WindowToPump AS LONG, ClientWindowToPump AS LONG)AS LONG
          ON ERROR GOTO ErrorHandler
          LOCAL ErrFunc AS LONG
          ErrFunc = %FALSE
          LOCAL tMsg AS TagMsg                              ' message information
          LOCAL hAccel AS DWORD                             'Win32Api.inc shows this as DWORD rather than Long
          LOCAL ErrorBuff AS ASCIIZ * %MAX_PATH
          LOCAL MsgBoxTxt AS STRING
          LOCAL MsgBoxStyle AS LONG
          LOCAL MsgBoxTitle AS STRING
          STATIC LastMsgTime AS LONG
          LastMsgTime = TIMER
     '*** Acquire and dispatch messages until a WM_QUIT message is received.
     '     WHILE GetMessage(tmsg, BYVAL %NULL, 0, 0)<> -1
          WHILE ISTRUE GetMessage(tmsg, BYVAL %NULL, 0, 0)                                'While GetMessage exists
'               select case GetMessage(tmsg, BYVAL %NULL, 0, 0)
'                    case %INVALID_VALUE                                                   'GetMessage returns -1 (%INVALID_VALUE) if an error
'                         ErrFunc = GetLastError
'                         FormatMessage %FORMAT_MESSAGE_FROM_SYSTEM, BYVAL %NULL, ErrFunc, %NULL, ErrorBuff, SIZEOF(ErrorBuff), BYVAL %NULL
'                         MsgBoxTxt = "Error in " + FUNCNAME$ + STR$(ErrFunc) + $TAB + ErrorBuff
'                         MsgBoxStyle = %MB_SYSTEMMODAL OR %MB_ICONERROR
'                         MsgBoxTitle = $AppName
'                         MSGBOX MsgBoxTxt, MsgBoxStyle, MsgBoxTitle
'                         exit loop
'                    case else                                                             'If Non-Zero, and not an error then resume checks
'*** TranslateMDISysAccel checks
                         SELECT CASE TranslateMDISysAccel(ClientWindowToPump, tMsg)
                              CASE 0                                                                'No Mdi Accelerator Keys
'*** TranslateAccelerator checks
                                   SELECT CASE TranslateAccelerator(WindowToPump, hAccel, tMsg)
                                        CASE 0                                                      'TranslateAccelerator returned error
                                             ErrFunc = GetLastError
                                             SELECT CASE ErrFunc
                                                  CASE 0                                            'Error was due to No key to translate to a hotkey
                                                       ErrFunc = TranslateMessage(tMsg)             'Translate virtual-key messages into character messages (Return 0 if not posted to queue)
                                                       ErrFunc = DispatchMessage(tMsg)              'Dispatch Msg to proper callback or procedure window (Return value varies on Message sent)
                                                  CASE 5                                            'Error was due to No key to translate to a hotkey
                                                       ErrFunc = TranslateMessage(tMsg)             'Translate virtual-key messages into character messages since Accelerator table was not created by LoadAccelerators or CreateAcceleratorTable
                                                       ErrFunc = DispatchMessage(tMsg)              'Dispatch Msg to proper callback or procedure window (Return value varies on Message sent)
'*** <--- Add Message checking routines later if needed but docs state (The return value specifies the value returned by the window procedure. Although its meaning depends on the message being dispatched, the return value generally is ignored.)
                                                  CASE ELSE
                                                       FormatMessage %FORMAT_MESSAGE_FROM_SYSTEM, BYVAL %NULL, ErrFunc, %NULL, ErrorBuff, SIZEOF(ErrorBuff), BYVAL %NULL
                                                       MsgBoxTxt = "Error in " + FUNCNAME$ + STR$(ErrFunc) + $TAB + ErrorBuff
                                                       MsgBoxStyle = %MB_SYSTEMMODAL OR %MB_ICONERROR
                                                       MsgBoxTitle = $AppName
                                                       MSGBOX MsgBoxTxt, MsgBoxStyle, MsgBoxTitle
                                             END SELECT
                                        CASE ELSE                                                   'TranslateAccelerator Returns TRUE           '<--- (not sure if -1 or just non-zero = TRUE in this case?
                                   END SELECT
'*** End TranslateAccelerator checks
                              CASE ELSE                                                             'Mdi Accelerator keys exist and are passed on to appropriate window
                         END SELECT
'*** End TranslateMDISysAccel checks
'               end select
'*** End GetMessage Checks
'*** Following line does not work and can not close without taskmanager
'               If isfalse GetMessage(tmsg, BYVAL %NULL, 0, 0) then SetTimer WindowToPump, %UpdateTimer, 1, BYVAL %NULL         'Requires %WM_TIMER event to kill timer when handled
'*** Issuing a timer refresh (within reason) seems to clear things up and force a refresh if mouse is not over app
               SELECT CASE LastMsgTime
                    CASE < TIMER - (1/18)         '(1/100 for NT, but chose 1/18 for earlier platforms (aka PbDoc's)
                         SetTimer WindowToPump, %UpdateTimer, 1, BYVAL %NULL         'Requires %WM_TIMER event to kill timer when handled
                         LastMsgTime = TIMER
                    CASE ELSE
               END SELECT
          WEND
          IF ErrFunc <> 0 THEN ErrFunc = %FALSE                                           'Reset ErrFunc due to no real error and escaped loop
'*** End Message Pump loop
     '     FUNCTION = tmsg                                                                 'Return Msg Structure for checks if errors
          FUNCTION = ErrFunc
          EXIT FUNCTION
     ErrorHandler:
          FUNCTION = ERR
     END FUNCTION

Commented code for errors cause their own "Lockups" but adding timer (although I do not like this solution) seems to keep the pump still pumping

**colin glenn** · 23 Mar 2009, 07:31 PM

Cliff, you're making it too complex, a message pump only needs to be 4 lines, 6 if you're using an accelerator table loaded from a resource file. With dialogs, the only purpose of the pump is to keep the modeless dialog alive on the desktop, other wise if you're NOT using accelerator's, (loaded from a resource that is), and can use the desktop as the parent, the DDT engine works just fine as is.

99% of your "calls from the OS that there's a message to be handled" will be sent to the dialog's designated callback. INCLUDING TIMER MESSAGES.

DIALOG SHOW MODELESS hDlg, CALL ShowDIALOG1Proc TO lRslt

If you want to monitor what calls are being made, that's the function which the messages go to.

Notation, you do need at least the four main lines to have the message pump work, if you don't provide processing for the messages, the dialog don't work.

**Michael Mattias** · 24 Mar 2009, 07:47 AM

Cliff, you're making it too complex, a message pump only needs to be 4 lines, 6 if you're using

Four? Six?

Code:

   DIALOG SHOW MODELESS hDlg, CALL ShowDIALOG1Proc TO lRslt
1  DO
2        DIALOG DOEVENTS TO X
3  LOOP WHILE X

TranslateAccelerator handled by DDT
If TranslateSysMDIAccelerator is in there, this is not a DDT dialog application
If modeless SDK dialog above, IsDialogMessage() missing.

DDT/SDK syntax choices are radio buttons, not checkboxes.

PS

With dialogs, the only purpose of the pump is to keep the modeless dialog alive on the desktop

I think I would have phrased this the way it is phrased in the help file:

DIALOG DOEVENTS statement
Purpose Process pending window or dialog messages for MODELESS dialogs....

....

Restrictions
The DIALOG DOEVENTS loop must run for the duration of the modeless dialog(s), or they will not respond or be redrawn correctly.

Announcement

TranslateMessage DispatchMessage problems

TranslateMessage DispatchMessage problems

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment