DDT Check Box behaviour

[John Petty]

I have a large program which in one portion tests something and if conditions are met tries to tick a check box. The code in the check box section of dialog callback then does the changes required. The short program below shows the problem. If I click on the check box then the callback responds but if I post or send a click message to it nothing happens. If I set the state of the check box then work code doesn't execute. What am I missing? Why doesn't the check box respond to a post or send message?

#PBFORMS CREATED V1.51
#COMPILE EXE
#DIM ALL

#PBFORMS BEGIN INCLUDES
#IF NOT %DEF(%WINAPI)
    #INCLUDE "WIN32API.INC"
#ENDIF
#PBFORMS END INCLUDES

#PBFORMS BEGIN CONSTANTS
%Bcheck      = 1004
%Bexit       = 1005
%Bpost       = 1003
%Bsend       = 1002
%CBtest      = 1001
%IDD_DIALOG1 =  101
#PBFORMS END CONSTANTS

DECLARE CALLBACK FUNCTION ShowDIALOG1Proc()
DECLARE FUNCTION ShowDIALOG1(BYVAL hParent AS DWORD) AS LONG
#PBFORMS DECLARATIONS

FUNCTION PBMAIN()
    ShowDIALOG1 %HWND_DESKTOP
END FUNCTION

SUB TCheck (Hdlg AS DWORD)
    CONTROL SET CHECK Hdlg, %CBtest, 1
END SUB

SUB Tpost (Hdlg AS DWORD)
    CONTROL POST Hdlg, %CBtest, %BN_CLICKED, 0, 0
END SUB
SUB Tsend (Hdlg AS DWORD)
    CONTROL SEND Hdlg, %CBtest, %BN_CLICKED, 0, 0
END SUB
CALLBACK FUNCTION ShowDIALOG1Proc()

    SELECT CASE AS LONG CBMSG
        CASE %WM_INITDIALOG

        CASE %WM_NCACTIVATE
            STATIC hWndSaveFocus AS DWORD
            IF ISFALSE CBWPARAM THEN
                hWndSaveFocus = GetFocus()
            ELSEIF hWndSaveFocus THEN
                SetFocus(hWndSaveFocus)
                hWndSaveFocus = 0
            END IF

        CASE %WM_COMMAND
            SELECT CASE AS LONG CBCTL
                CASE %CBtest
                    IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN
                        'Note the above line was not added by PBForms 5.1
                        'in fact PBForms puts in no lines
                        ? "State changed so do work"
                    END IF

                CASE %Bsend
                    IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN
                        Tsend CBHNDL
                    END IF

                CASE %Bpost
                    IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN
                        Tpost CBHNDL
                    END IF

                CASE %Bcheck
                    IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN
                        Tcheck CBHNDL
                    END IF

                CASE %Bexit
                    IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN
                        DIALOG END CBHNDL
                    END IF

            END SELECT
    END SELECT
END FUNCTION

FUNCTION ShowDIALOG1(BYVAL hParent AS DWORD) AS LONG
    LOCAL lRslt AS LONG

#PBFORMS BEGIN DIALOG %IDD_DIALOG1->->
    LOCAL hDlg  AS DWORD

    DIALOG NEW hParent, "Dialog1", 70, 70, 201, 58, TO hDlg
    CONTROL ADD CHECKBOX, hDlg, %CBtest, "Test Check Box", 55, 10, 75, 15
    CONTROL ADD BUTTON,   hDlg, %Bsend, "Send Msg", 5, 35, 45, 15
    CONTROL ADD BUTTON,   hDlg, %Bpost, "Post Msg", 53, 35, 45, 15
    CONTROL ADD BUTTON,   hDlg, %Bcheck, "Check", 101, 35, 45, 15
    CONTROL ADD BUTTON,   hDlg, %Bexit, "Exit", 149, 35, 46, 15
#PBFORMS END DIALOG

    DIALOG SHOW MODAL hDlg, CALL ShowDIALOG1Proc TO lRslt

#PBFORMS BEGIN CLEANUP %IDD_DIALOG1
#PBFORMS END CLEANUP

    FUNCTION = lRslt
END FUNCTION

[Michael Mattias]

Your lparam and wParam parameters are wrong. (CBLPARAM and CBWPARAM).

Should be as in....

MACRO PostButtonClick(hWnd,ctrlid)
 PostMessage hWnd, %WM_COMMAND, MAKDWD(ctrlid,%BN_CLICKED), GetDlgItem(hWnd,Ctrlid)
END MACRO

But with a check box why bother to send or post a message instead of using the eminently understandable 'CONTROL SET CHECK?'

[John Petty]

Thanks Micheal but as you can see in the program and description I have tried CONTROL SET CHECK but then the code in the callback does not run so what is the message I should be looking for?
And what is wrong with the two parameters as they aren't tested

[Chris Boss]

BN_CLICKED is not a window message so your code is incorrect.

It is a notification message which is passed through the WM_COMMAND message.

You need to be sending the WM_COMMAND message to the control, not BN_CLICKED. The BN_CLICKED notification code will be embeded in the parameters of the WM_COMMAND message.

The syntax will be:

SendMessage hDlg&, %WM_COMMAND, MAKLNG(%ControlID,%BN_CLICKED), hCtrl&

[Michael Mattias]

>I have tried CONTROL SET CHECK but then the code in the callback does not run ...

Of course it doesn't because you didn't CLICK the checkbox control. But.. why would you need to do that anyway? At the point at which you do your "CONTROL SET CHECK" you can do whatever else needs to be done right at that time.

>...so what is the message I should be looking for?

Um, the message you are already processing?

>And what is wrong with the two parameters ...
Simply put yours are value zero and should be something else.

>as they aren't tested

I think you need to re-read the doc for CBCTL and CBCTLMSG. If that does not explain it see if you can find something in the help file under CONTROL SEND or CONTROL POST... that should explain it.



MCM

[Chris Boss]

Notification messages 101:

There are two basic types of notification messages for controls.

(1) Those passed through WM_COMMAND
(2) Those passed through WM_NOTIFY

Even though they are referred to as messages, they are not the same thing as window messages, so they can't be sent using sendmessage or postmessage (as the Msg parameter).

Notification messages are embeded in the parameters of the WM_COMMAND or WM_NOTIFY window messages.

WM_COMMAND has a simple syntax:

SendMessage hParent&, %WM_COMMAND, MAKLNG(%MyControlID,%NotificationMessage), hCtrl&

WM_NOTIFY has a slightly more complex syntax, in that a pointer to a structure is passed in the lParam parameter.

The lParam value is a pointer for a unique structure for each control type (mostly common controls). You have to read the API docs to find out what the structure is and each control type may use different structures for different notification messages.

Fortunately, this unique structure always has the following substructure (type) as the first member:

TYPE NMHDR
  hwndFrom AS DWORD
  idfrom AS DWORD
  code AS LONG  
END TYPE

The .code member of this structure is what contains the actual notification message value. This can be tested to see what notification message it is and then processed accordingly.

It is important to note, that notification messages are not the same thing as window messages. They can't be sent (as the Msg parameter) via SendMessage. They are messages, which are embedded in actual window messages (WM_COMMAND or WM_NOTIFY).

It is important to get their syntax right for both processing them, as well as when attempting to generate fake messages and sending/posting them.

[John Petty]

Chris thank you but I am not using the API calls but the PB DDT commands which work fine with all other controls I have used them with, I assume PB translates them to the formats you are specifying.
Micheal there is quite a lot of code in the real program which executes if the user clicks on the check box, so for efficiency I would rather not reproduce it when I wish to programatically change the check box state. Also the help files give no specific details Wparam$ and Lparam& and examples normally show 0 and 0. If in fact they contain the check state I would like I could work that out but as the callback never receives the message as shown by running the test program there is not much point.
My reading shows that the check box only has two messages ie BN_clicked and BN_doubleclicked. So I guess my real question is why does a standard dialog callback not receive these messages like other controls when sent or posted the message ie sending or posting such mesages to a button etc works fine.

[Chris Boss]

John,

My comments are directly related to DDT as well!

Instead of SendMessage one would use CONTROL SEND or DIALOG SEND, but the syntax of the messages and the parameters for notification messages are exactly the same.

It should be noted, that DDT is not some proprietary command set, in the sense that it does things differently than the API. It is a well designed command set which calls the API and uses similiar syntaxes.

What I said definitelly effects all DDT users.

It should be noted that DDT callback functions (for controls) is simply processing the WM_COMMAND message, so to generate a DDT callback event, one must send a WM_COMMAND message to the dialog and DDT will forward it to the callback function.

DDT version of what I noted above:

DIALOG SEND hDlg&, %WM_COMMAND, MAKLNG(%MyControlID,%NotificationMessage), hCtrl&

[Dave Biggs]

John,
Try this..

SUB TCheck (Hdlg AS DWORD)
  LOCAL TOGGLE AS Long 
  CONTROL GET CHECK Hdlg, %CBtest To TOGGLE
  CONTROL SET CHECK Hdlg, %CBtest, IIF(TOGGLE, 0, 1)
  'CONTROL POST Hdlg, %CBtest, %BM_CLICK, 0, 0
END SUB
 
SUB Tpost (Hdlg AS DWORD)
    CONTROL POST Hdlg, %CBtest, %BM_CLICK, 0, 0
END SUB
SUB Tsend (Hdlg AS DWORD)
    CONTROL SEND Hdlg, %CBtest, %BM_CLICK, 0, 0
END SUB

[Michael Mattias]

box, so for efficiency I would rather not reproduce it when I wish to programatically change the check box state

Then write a SUB or FUNCTION to do what has to be done. You can call that anytime from anywhere in your program. (I also despise replicated code).

So I guess my real question is why does a standard dialog callback not receive these messages like other controls when sent or posted the message ie sending or posting such mesages to a button etc works fine.

Asked and answered (twice) but let me simplify it a little: Your POST and SEND statements are WRONG. Had you done them correctly you'd be getting the effect you seek.

MCM

[Chris Boss]

DDT and the API 101:

To better appreciate what DDT is really doing, one really should gain an understanding of the Windows API's that DDT commands are calling to accomplish things.

DDT is far closer to the Windows API that one may realize and it uses a number of standard Dialog API's built into Windows.

The Callback function is not some proprietary engine which does its own tricks totally different than the API.

Callback functions in DDT are simply a means of forwarding API notification messages to a user defined function. Under the hood, DDT is simply processing the WM_COMMAND message for you (from the dialog procedure internally) and parsing out the parameters for the message into more readable data (the CBxxx functions). Thats all it is doing!

Experienced API programmers with experience with the Dialog API's can tell you that the DDT command set is a lean and mean command set which is a wrapper over many existing API's already in Windows.

When working with DDT, it is best not to view DDT as separate than the API, as if it were totally different. One should view DDT as simply a cleaner way of accessing the API, but with the same (or similiar) syntaxes as one would do when using the API.

Do not underestimate the value of the API docs, to better understand DDT and what it is doing.

If you understand the reasons why DDT commands work the way they do, you will be able to use them more effectively.

[Chris Boss]

Ok,

Maybe I see the confusion here!

There is a big difference between:

BN_CLICKED

and

BM_CLICK

There are two types of messages defined for each control in the API docs.

(1) Actual window messages which can sent directly to the control classes window procedure (using SendMessage API or CONTROL SEND in DDT). Such window messages have a prefix for the class which usually ends with the letter M (for message).

For the button class (includes checkboxes) some of the messages are:

BM_CLICK (simulates a mouse click)
BM_GETCHECK
BM_SETCHECK
etc.

Notice the prefix BM_

(2) Notification messages which are not window messages, but are passed through the WM_COMMAND or WM_NOTIFY messages (DDT only passes WM_COMMAND to callbacks).

Notification messages, since they are not window messages use a different prefix than the window messages for the same class. Usually they end with the letter N (for Notification). These messages are never sent using SendMessage or CONTROL SEND as the Msg parameter!

Some notification messages for the button class are:

BN_CLICKED
BN_DBLCLK
BN_SETFOCUS
etc.

Notice the prefix BN_

Can you see the problem here ?

BM_CLICK (a window message)

and

BN_CLICKED (a notification message)

I think the problem here is the confusion between a window message and a notification message, by simply not noticing the M or N at the end of the message prefix.

The Windows API has a real reason for its naming conventions of constants and the M or N are the end of a prefix means a great deal.

Actually, John was attempting to do the right thing, but he simply made the mistake of using the BN_CLICKED notification message constant instead of the BM_CLICK constant for his CONTROL SEND call.

See how easy it is to get confused and use the wrong constant.

Now I see why he couldn't grasp my discussion of BN_CLICKED and WM_COMMAND!

He was trying to send a valid message (BM_CLICK), but simply used the wrong constant which was BN_CLICKED.

My points were valid, if he was actually trying to send a notification message, but he wasn't.

The lesson in this, is that be very careful of the constants you use. They may look similiar (like BM_CLICK and BN_CLICKED), but they are not.

The letters in a prefix of an API constant have real meaning and should be learned.

For me an experienced API programmer, the first thing I saw when I looked at Johns code was BN_ and the light went off in my head, NOTIFICATION message. It never dawned on me, that he was trying to send the valid window message BM_CLICK.

An experienced API program will quickly recognize constant prefixes and they have meaning so he will come to a specific conclusion.

Moral of the story:

Those constant prefixes have real meaning and are important.

[Chris Boss]

I should give credit to Dave Biggs.

I wasn't until he posted code with the correct constant BM_CLICK that I realized the cause of confusion. I just assumed John was actually trying to use a notification message (BN_CLICKED) (which can be done to generate an event in a callback) and so no wonder my comments seemed strange.

[John Petty]

Thank you Chris and Dave, yes changing the sent message to %BM_CLICK solved the problem, I was thowen off by the fact that that the control resonded to the %BN_CLICKED message if I actually clicked on the check box