PostMessage failure..

[Borje Hagsten]

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:
'

#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
'

[Stuart McLachlan]

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.

[Borje Hagsten]

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..

[Mike Doty]

Might instead use actual button ids
Display messagebox in %WM_USER based upon value(s) passed

%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

[Michael Mattias]

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

[Steve Hutchesson]

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.

[Borje Hagsten]

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.

[Michael Mattias]

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.

[Stuart McLachlan]

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 )

[Borje Hagsten]

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...

[Steve Hutchesson]

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.

[Michael Mattias]

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]

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!

[Stuart McLachlan]

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

[Steve Hutchesson]

[Rodney Hicks]

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.

[Michael Mattias]

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,