Announcement

Collapse
No announcement yet.

PostMessage failure..

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • PostMessage failure..

    Strange thing - in so many applications over the years, I have used a Button and SendMessage to %WM_HELP in order to support both Button and pressing F1 for help/Info. Never a problem. Last night I happened to type "PostMessage" instead of "SendMessage" - and it failed! Seems like PostMessage disappears along the line, while SendMessage survives. Tried some variations, like PostMessage to %WM_USER and then it works like expected. It's only when I target %WM_HELP PostMessage fails. Same with DIALOG POST/SEND, of course.

    And yes, I know that lParam can/should point to a HELPINFO structure - also tested - no difference and not really needed. Just wanted to tell, in case someone else encounter similar problem. Tiny code shows and explains better:
    '
    Code:
    #COMPILE EXE
    #DIM ALL
    #INCLUDE "WIN32API.INC"
    
    '====================================================================
    FUNCTION PBMAIN () AS LONG
      LOCAL hDlg AS DWORD
    
      DIALOG NEW 0, "Press F1 - press Buttons",,, 136, 26, %WS_CAPTION OR %WS_SYSMENU, 0 TO hDlg
    
      '------------------------------------------------------------------
      CONTROL ADD BUTTON, hDlg, %IDOK,   "SendMessage",  5, 5, 60, 14
      CONTROL ADD BUTTON, hDlg, %IDHELP, "PostMessage", 70, 5, 60, 14
    
      '------------------------------------------------------------------
      DIALOG SHOW MODAL hDlg CALL DlgProc
    
    END FUNCTION
    
    '====================================================================
    CALLBACK FUNCTION DlgProc() AS LONG
    
      SELECT CASE AS LONG CB.MSG
      CASE %WM_COMMAND
          SELECT CASE AS LONG CB.CTL
          CASE %IDOK
             IF CB.CTLMSG = %BN_CLICKED OR CB.CTLMSG = 1 THEN
                  'DIALOG SEND CB.HNDL, %WM_HELP, 0, lpHELPINFO  ' same result, of course..
                  SendMessage CB.HNDL, %WM_HELP, 0, 0  ' works
             END IF
    
          CASE %IDHELP
              IF CB.CTLMSG = %BN_CLICKED OR CB.CTLMSG = 1 THEN
                 'DIALOG POST CB.HNDL, %WM_HELP, 0, lpHELPINFO  ' same result, of course..
                 PostMessage CB.HNDL, %WM_HELP, 0, 0  ' fails
              END IF
    
          END SELECT
    
      CASE %WM_HELP  ' F1 triggers this one
          MSGBOX "F1 works" + $CR + _
                 "SendMessage from button works" + $CR + _
                 "PostMessage from button fails", _
                 %MB_ICONINFORMATION, "%WM_HELP test"
    
      END SELECT
    END FUNCTION
    '

  • #2
    As A WAG: Even though you are sending a NULL pointer (0), it's still regarded as a pointer.

    If you send a message in the range below WM_USER to the asynchronous message functions (PostMessage, SendNotifyMessage, and SendMessageCallback), its message parameters can not include pointers. Otherwise, the operation will fail.

    Comment


    • #3
      Yes. I saw that explanation too, but though the line "If you send a message " implies that SendMessage also should fail, when it don't and never has. Keyword being "asynchronous". Strange language, English..

      Comment


      • #4
        Might instead use actual button ids
        Display messagebox in %WM_USER based upon value(s) passed
        Code:
        %SEND_BTN = 1001
        %POST_BTN = 1002
        '====================================================================
        FUNCTION PBMAIN () AS LONG
          LOCAL hDlg AS DWORD
          DIALOG NEW 0, "Press F1 or Buttons",,, 136, 26, %WS_CAPTION OR %WS_SYSMENU, 0 TO hDlg
          CONTROL ADD BUTTON, hDlg, %SEND_BTN, "SendMessage",  5, 5, 60, 14
          CONTROL ADD BUTTON, hDlg, %POST_BTN, "PostMessage", 70, 5, 60, 14
          DIALOG SHOW MODAL hDlg CALL DlgProc
        END FUNCTION
        '====================================================================
        CALLBACK FUNCTION DlgProc() AS LONG
          SELECT CASE AS LONG CB.MSG
            CASE %WM_COMMAND
              SELECT CASE AS LONG CB.CTL
        
                CASE %SEND_BTN 'first button
                  IF CB.CTLMSG = %BN_CLICKED OR CB.CTLMSG = 1 THEN
                   DIALOG SEND CB.HNDL, %WM_USER + 600, 0, 0
                  END IF
        
                CASE %POST_BTN 'second button
                  IF CB.CTLMSG = %BN_CLICKED OR CB.CTLMSG = 1 THEN
                   DIALOG POST CB.HNDL, %WM_USER + 600, 1, 0
                  END IF
        
              END SELECT
        
            CASE %WM_USER + 600 'message to display
             SELECT CASE CB.WPARAM
              CASE 0:? "DIALOG SEND FROM FIRST BUTTON"
              CASE 1:? "DIALOG POST FROM SECOND BUTTON"
              CASE 2:? "DIALOG POST FROM F1 KEY"
             END SELECT
        
            CASE %WM_HELP 'F1
             DIALOG POST CB.HNDL, %WM_USER + 600, 2, 0
        
          END SELECT
        END FUNCTION
        CMD shortcut to open any location:
        %windir%\system32\cmd.exe /k " cd\ & x: & cd x:\xxxx
        Change to run as administrator
        How long is an idea? Write it down.

        Comment


        • #5
          WM_HELP doc
          Indicates that the user pressed the F1 key. If a menu is active when F1 is pressed, WM_HELP is sent to the window associated with the menu; otherwise, WM_HELP is sent to the window that has the keyboard focus. If no window has the keyboard focus, WM_HELP is sent to the currently active window.
          Maybe posting instead of sending is doing something to your keyboard focus status and/or active window/?

          Although I might suggest... coding your own help routine - which you do under control ID %IDHELP - and then process the WM_HELP message by sending (not posting) a click to the IDHELP button. (or equal).

          That will still accomplish the goal of invoking your help help regardless if the user uses your help button or presses F1.

          Having all user actions which invoke the same code work by sending a message like this is how I avoided duplicate code .. that is, I end up with ONE and ONLY ONE place where a particular routine is invoked.,

          It's a thought.

          MCM
          Last edited by Michael Mattias; 23 Nov 2020, 10:13 AM. Reason: Had forgottten word 'focus' so I added.
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            This much I have found with the shift from 32 to 64 bit Windows versions that code that worked with SendMessage() sometimes failed and the solution was to use PostMessage(). Seems to have to do with various timing issues in the OS. The obvious is to use PostMessage() when you don't want the result immediately where SendMessage() always halts your current action until it returns, just a design choice depending on what you are doing.
            hutch at movsd dot com
            The MASM Forum

            www.masm32.com

            Comment


            • #7
              Yes, going from %WM_HELP to a "help button" is a way I have done in some codes, but since going from button to %WM_HELP using SendMessage has always worked, I was surprised to see that PostMessage didn't. We learn something new (old) every day. Else I use separate help function called from both places in larger programs, but sometimes a simple MessageBox in one place is enough.

              Comment


              • #8
                It's just me... I am paranoid about duplicating code.

                For <name redacted to protect the guilty>, I took a 1400 line COBOL program, added two new features, restructured to use tables and removed duplicated and/or redundant code and ended up with ==> a program.using 400 lines of source code,

                Good thing I wasn't paid by the "loc*" huh?

                MCM
                * line of [source] code.. what IBM used internally and was trying to use to assess Microsoft's productivity when MS tailored MS-DOS for use on the original IBM PC(r). The original code was rife with duplicated code so the new code required less source code.
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                mmattias[email protected]
                http://www.talsystems.com

                Comment


                • #9
                  Originally posted by Michael Mattias View Post
                  It's just me... I am paranoid about duplicating code.

                  For <name redacted to protect the guilty>, I took a 1400 line COBOL program, added two new features, restructured to use tables and removed duplicated and/or redundant code and ended up with ==> a program.using 400 lines of source code,
                  A basic programming principle. DRY https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

                  Sadly neglected by at least one forum member (no names, no pack drill )



                  Comment


                  • #10
                    Hm, I have got a private message, but I get "You are not authorized to create this post." when I try to reply. Trouble with PostMessage there too...

                    Comment


                    • #11
                      There is duplicate code and there is duplicate code and knowing why helps to separate one from the other. When the call overhead is greater than the size saving, duplicate the code, when you need to be able to read it some years down the track, duplicate the code, when speed matters and you inline the code rather than call it from a remote location (in another SUB or FUNCTION), be careful of what you wish for or you could end up with a tangled mess that does not save you ever one 512 byte section.
                      hutch at movsd dot com
                      The MASM Forum

                      www.masm32.com

                      Comment


                      • #12
                        basic programming principle. DRY....
                        Sheesh... I never knew and would never have guessed there was an 'official' acronym and a Wikipedia article for ... common sense?
                        Michael Mattias
                        Tal Systems (retired)
                        Port Washington WI USA
                        [email protected]
                        http://www.talsystems.com

                        Comment


                        • #13
                          BTW..

                          [the DRY principle is ] Sadly neglected by at least one forum member...
                          Well.... I will deliberately repeat myself when it is obvious the prior lesson(s) have not sunk in yet!

                          And, again proving I can still hit the hanging slider right down the middle...

                          Some things are worth repeating!
                          Michael Mattias
                          Tal Systems (retired)
                          Port Washington WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            Originally posted by Michael Mattias View Post

                            Sheesh... I never knew and would never have guessed there was an 'official' acronym and a Wikipedia article for ... common sense?
                            The problem with common sense is that it is not so common

                            Comment


                            • #15
                              hutch at movsd dot com
                              The MASM Forum

                              www.masm32.com

                              Comment


                              • #16
                                There is much to be said for not committing the same offenses as in the past just as there is much to be said for throwing off the shackles of the past. Thus we are chained to protocols developed over a time period that had little excess memory or speed and efforts to throw off the shackles are ridiculed by those content with what they know.
                                There is a time for this, and a time for that, it all depends on how you wear your hat.
                                Rod
                                I want not 'not', not Knot, not Knott, not Nott, not knot, not naught, not nought, but aught.

                                Comment


                                • #17
                                  So many of the redundant code scenarios I've seen have been where originally you have two options and you can do a simple "IF,,,, ELSE" and doing that two. three, even four times in a program is not all that bad.

                                  But over time the business adds a third choice,,, and someone adapts the code the quick and easy way by (in three, four places!) changing to IF... ELSE IF ,, ELSE IF .... (in COBOL ELSE IF is two words) . Then comes a fourth option.. and a fifth... and a sixth and sure as shootin' you end up with a page and a half of IF .. ELSE IF .. in three or four different places in the program,

                                  At some point someone needs to just skip the quick and dirty way,* bite the bullet and restructure the program for future maintenance.

                                  MCM
                                  * although some managers think short-term and cannot (will not?) look beyond this quarter's P&L and actually encourage this 'quick fix' mentality,
                                  Michael Mattias
                                  Tal Systems (retired)
                                  Port Washington WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment

                                  Working...
                                  X