When do I check that I have the right message for the right control in DDT programs?

[Barry Marks]

I'm referring here to code such as this:

IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN

which is inserted into the WM_COMMAND messages for controls by PBForms and is in the sample code. I understand that it's to avoid responding at the wrong time.

I don't understand why that happens and just when I do and don't have to check for it and just what I have to check for in which situations.

I left that out before PB9 because I didn't know when to put it in and it didn't seem to matter, but I read somewhere, and I can't remember where, or find it now, that those checks have become necessary with PB9 so I want to start using them, only I really don't know what to check for when or why. I don't know the principles involved. I haven't found anything in the help about it. Maybe I just don't know where to look.

Any explanations or any pointers to discussions or text about this would be very much appreciated.

By the way, I'm really enjoying PB9. This is nice.

Thanks,
Barry

[Rodney Hicks]

The statements within the IF block are processed on the button click.

CASE %IDC_BUTTON1
          IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN
            'MSGBOX "%IDC_BUTTON1=" + FORMAT$(%IDC_BUTTON1), %MB_TASKMODAL
            INCR var                                          'increment the variable
            CONTROL SET TEXT CBHNDL, %IDC_LABEL1,""       'Clear the print area, in this case a label
            CONTROL SET TEXT CBHNDL, %IDC_LABEL1,FORMAT$(var)   'Print the variable on the label
            CONTROL REDRAW CBHNDL, %IDC_LABEL1                'Force a redraw
          END IF

example program:

#PBFORMS CREATED V1.51
'--------------------------------------------------------------------------------------------------
' The first line in this file is a PB/Forms metastatement.
' It should ALWAYS be the first line of the file. Other
' PB/Forms metastatements are placed at the beginning and
' end of "Named Blocks" of code that should be edited
' with PBForms only. Do not manually edit or delete these
' metastatements or PB/Forms will not be able to reread
' the file correctly.  See the PB/Forms documentation for
' more information.
' Named blocks begin like this:    #PBFORMS BEGIN ...
' Named blocks end like this:      #PBFORMS END ...
' Other PB/Forms metastatements such as:
'     #PBFORMS DECLARATIONS
' are used by PB/Forms to insert additional code.
' Feel free to make changes anywhere else in the file.
'--------------------------------------------------------------------------------------------------

#COMPILE EXE
#DIM ALL

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

'--------------------------------------------------------------------------------------------------
'   ** Constants **
'--------------------------------------------------------------------------------------------------
#PBFORMS BEGIN CONSTANTS
%IDD_DIALOG1 =  101
%IDC_LABEL1  = 1001
%IDC_BUTTON1 = 1002
#PBFORMS END CONSTANTS
'--------------------------------------------------------------------------------------------------

'--------------------------------------------------------------------------------------------------
'   ** Declarations **
'--------------------------------------------------------------------------------------------------
DECLARE CALLBACK FUNCTION ShowDIALOG1Proc()
DECLARE FUNCTION ShowDIALOG1(BYVAL hParent AS DWORD) AS LONG
#PBFORMS DECLARATIONS
'--------------------------------------------------------------------------------------------------

'--------------------------------------------------------------------------------------------------
'   ** Main Application Entry Point **
'--------------------------------------------------------------------------------------------------
FUNCTION PBMAIN()
  ShowDIALOG1 %HWND_DESKTOP
END FUNCTION
'--------------------------------------------------------------------------------------------------

'--------------------------------------------------------------------------------------------------
'   ** CallBacks **
'--------------------------------------------------------------------------------------------------
CALLBACK FUNCTION ShowDIALOG1Proc()
STATIC var AS LONG
  SELECT CASE AS LONG CBMSG
    CASE %WM_INITDIALOG
      ' Initialization handler

    CASE %WM_NCACTIVATE
      STATIC hWndSaveFocus AS DWORD
      IF ISFALSE CBWPARAM THEN
        ' Save control focus
        hWndSaveFocus = GetFocus()
      ELSEIF hWndSaveFocus THEN
        ' Restore control focus
        SetFocus(hWndSaveFocus)
        hWndSaveFocus = 0
      END IF

    CASE %WM_COMMAND
      ' Process control notifications
      SELECT CASE AS LONG CBCTL
        CASE %IDC_LABEL1

        CASE %IDC_BUTTON1
          IF CBCTLMSG = %BN_CLICKED OR CBCTLMSG = 1 THEN
            'MSGBOX "%IDC_BUTTON1=" + FORMAT$(%IDC_BUTTON1), %MB_TASKMODAL
            INCR var
            CONTROL SET TEXT CBHNDL, %IDC_LABEL1,""
            CONTROL SET TEXT CBHNDL, %IDC_LABEL1,FORMAT$(var)
            CONTROL REDRAW CBHNDL, %IDC_LABEL1
          END IF

      END SELECT
  END SELECT
END FUNCTION
'--------------------------------------------------------------------------------------------------

'--------------------------------------------------------------------------------------------------
'   ** Dialogs **
'--------------------------------------------------------------------------------------------------
FUNCTION ShowDIALOG1(BYVAL hParent AS DWORD) AS LONG
  LOCAL lRslt AS LONG

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

  DIALOG NEW hParent, "Howdy!", 325, 141, 230, 254, %WS_POPUP OR %WS_BORDER OR %WS_DLGFRAME OR _
    %WS_SYSMENU OR %WS_CLIPSIBLINGS OR %WS_VISIBLE OR %DS_MODALFRAME OR %DS_3DLOOK OR _
    %DS_NOFAILCREATE OR %DS_SETFONT, %WS_EX_CONTROLPARENT OR %WS_EX_LEFT OR %WS_EX_LTRREADING OR _
    %WS_EX_RIGHTSCROLLBAR, TO hDlg
  CONTROL ADD LABEL,  hDlg, %IDC_LABEL1, "", 5, 5, 100, 10
  CONTROL SET COLOR   hDlg, %IDC_LABEL1, -1, -2
  CONTROL ADD BUTTON, hDlg, %IDC_BUTTON1, "Press me!", 20, 115, 50, 15
#PBFORMS END DIALOG

  DIALOG SHOW MODAL hDlg, CALL ShowDIALOG1Proc TO lRslt

#PBFORMS BEGIN CLEANUP %IDD_DIALOG1
#PBFORMS END CLEANUP

  FUNCTION = lRslt
END FUNCTION
'--------------------------------------------------------------------------------------------------

[Barry Marks]

The statements within the IF block are processed on the button click.

That's all? Just that one IF statement for button clicks and nothing else for other controls?

I thought there'd be more to it than that.

Thanks,
Barry

[Rodney Hicks]

There is more to it.

If you have two buttons you'll have two IF blocks generated by PBForms, one for each CASE %IDC_BUTTONx ID.

Within PBForms there is a quick program to build under EXAMPLE PROJECT.
It will get you motoring with PBWin and PBForms. Worked for me.

[Barry Marks]

I'm not really using PBForms except to learn syntax. Most of what I'm doing is partly from scratch and partly from whatever code I can steal.

I have started some things with PBForms but I find it easier to, very early on, remove all the forms stuff and do it my way, once the initial layout is done. But most of what I do is without Forms. That's why I want to learn the principles involved in this.

Maybe it is simpler than I thought.

Barry

[Rodney Hicks]

Once you understand what each part is doing it is a lot simpler, and PBForms does give you layout, in fact that's it's primary purpose, but that example shows a lot of other little things. It ties things together. A lot of the samples that come with PBForms are pretty good(PBFORMS/SAMPLES/.
Lots of example in the source code forum as well.
You can also learn a lot just by reading other's questions and the responses, even if they don't seem to apply to anything you're trying to do.

Features can run from simple to perplexing, but even the perplexing things turn simple with understanding. Patience, trial and error, and questions.

[Chris Holbrook]

Maybe I just don't know where to look.

for Windows fundamentals - which is what you are asking about here - the overviews and tutorials on MSDN are usually clear and straight to the point. Some people also swear by Charles Petzold's "Programming Windows" book.

Windows is all messages. Inter alia, some messages go to a control, some go to the control's parent. Subclassing and superclassing of controls are two techniques to isolate a control's messages by establishing a callback function just for the specific control. There are plenty of example of both in these forums. On superclassing I found Semen Matusovski's example (now ancient) very useful. For subclassing, this thread may be found useful.

I found that it helped my understanding to catch the messages and display their message ids and parameters, either one by one in the dialog caption, or sequentially into a listbox or listview. It usually helps to put a delay in there too. There is a list of windows numeric message identifiers with equivalent text strings here which you can put into a .inc file, for example.

[Conrad Hoffman]

I'm always wondering about the best ways to do this, so I'll put up my message handler for a current project. The PBWin 9 docs say (I think) that one should use the new CB message functions, so I've started doing it that way. Curious- is it better to use IF/THEN blocks, or SELECT CASE? I prefer SELECT. Hopefully the more knowledgable here will tell me what's best.

CALLBACK FUNCTION DlgProc()

    STATIC MotorFunc AS Int__DNstSquiggleCtrl                   'assign interface to object variable
    LOCAL SQresult AS DWORD                                     'will use this later for error checking

    SELECT CASE CB.MSG
        CASE %WM_INITDIALOG
            MotorFunc = AtlAxGetDispatch(GetDlgItem(CBHNDL, %ID_NST))  ' Get the IDispatch of the activex control
            IF ISFALSE ISOBJECT(MotorFunc) THEN ? "MotorFunc object not created"
        CASE %WM_SYSCOMMAND
            IF (CBWPARAM AND &HFFF0) = %SC_CLOSE THEN           'trap the "X" to exit the program and clean up
                MotorFunc = NOTHING                             'release the interface
                DIALOG END CB.HNDL, 0
                FUNCTION = 1
            END IF
        CASE %WM_COMMAND
            IF CB.CTLMSG = %BN_CLICKED THEN
                SELECT CASE CB.CTL
                    CASE %IDOK
                        DIALOG END CB.HNDL, 1
                        FUNCTION = 1
                    CASE %IDCANCEL
                        DIALOG END CB.HNDL, 0                   'canceling and closing a child dialog
                        FUNCTION = 1
                    CASE %IDC_START                             'START button
                        'OBJECT CALL dosomething                'the activex control requires use of OBJECT CALL
                        FUNCTION = 1
                    CASE %IDC_STOP
                        FUNCTION = 1
                    CASE %IDC_SINGLESTEP
                        CALL Data2ListBox(CB.HNDL, "this is test")
                        FUNCTION = 1
                    CASE %IDC_CLEARDATA
                        FUNCTION = 1
                    CASE %IDC_SAVEDATA
                        FUNCTION = 1
                    CASE %IDC_EXCEL
                        FUNCTION = 1
                    CASE %IDC_ABOUTBOX
                        OBJECT CALL MotorFunc.AboutBox TO SQresult   'bring up the AboutBox
                        IF SQresult <> 0 THEN BEEP
                        FUNCTION = 1
                END SELECT

[Richard Angell]

If all one has to deal with is a bunch of buttons, it may seem quite logical to some folks to code the WM_COMMAND cracker as Conrad has done. However, the real world cn often be a bit different. So the usual method is to determine the control firstwith "SELECT CASE AS LONG CB.CTL", then work only with that controls messages in that controls CASE. This is how PB Forms has handled the templating from day one. So if you have a List Box, Combo Box, Text Edit, etc., or even buttons where you are going to handle more than a click, so all a particular control's message code is in one spot for processing its WM_COMMAND messages.

PBWin 9 DDT has added enhanced support for separate control callbacks, although this is not specifically supported in the current PB Forms. The new additions for separate control callback enhancement still pass messages other than WM_COMMND or WM_NOTIFY messages to the parent dialog. It should be noted that in order process the other messages, when needed, one will need to subclass the control. But that's a subject for another day.

[Michael Mattias]

If all one has to deal with is a bunch of buttons, it may seem quite logical to some folks to code the WM_COMMAND cracker as Conrad has done. However, the real world cn often be a bit different. So the usual method is to determine the control first with "SELECT CASE AS LONG CB.CTL",

I'd disagree with that.

Why bother to test the control ID if the message is of no interest anyway? eg, WM_NCHITTEST, WM_NCACTIVATE.....

Unless you meant , "test message, then control, then notification code" instead of "test message, notification code, control" in which case I do agree with you.


MCM

[Richard Angell]

The quote, please note, was limited to the WM_COMMAND messages. So it was the test message in your sequence "test message, then control, then notification code"

[Gösta H. Lovgren-2]

Barry, to confuse you even more, I stopped using any forms designer. What I found was they just confused me with all the "extra code" they inserted. I say "extra" as much of what they inserted didn't have anything to do with what I was doing at the time.

At this stage (just beginning PBWin),

 CallBackFunction Main_Dialog_Processor as Long
    Select Case CbMsg        '       
        Case %WM_COMMAND  'This processes command messages
            Select Case CbCtl 'Which CONTROL is sent
               Case %ID_Control 'a button or some other control
                 Select Case CbCtlMsg ' What's happening
                     Case %Btn_Clicked
                          'Do something here

This is all you need to be concerned with to get going. Windows sends a TON of msgs and that's why CbCtlMsg needs to be filtered before acting on a Control (ie Button)

Once you get the hang of things a little better, you'll expand rapidly. These guys on here are so good and so experienced their advice often overwhelms and bewilders Newbies. Hey, I'm an Oldie (but not Goodie) and I still get bewildered (just now in the midst of such a sojourn into Font Control{grin}).

=======================================
"The great tragedy of science
the slaying of a beautiful hypothesis
by an ugly fact."
Thomas Huxley
=======================================

[Richard Angell]

I stopped using any forms designer. What I found was they just confused me with all the "extra code" they inserted. I say "extra" as much of what they inserted didn't have anything to do with what I was doing at the time.

Each to his/her own, but "extra code" is often just a place holder to keep us from remembering what still needs to be addressed. I'd still rather have a WYSIWYG designer that guess and by golly all by hand we used to use. Much, much easier to change and manipulate quickly, but as I said, each to his/her own choice here.

I think most of the time that you will find that PB Forms adds what can only be described as "do-nothing-yet place-holders", but other than that is just almost no extra bloat. In the case of clicked buttons, PB Forms implements a message box telling the user which control was clicked. That message can be taken as a gentle nudge that says ... "here's something that still needs actual program code to do something". Extra code, yes, but with a useful place holding purpose.

One would have to compare PB Forms with the other 3rd party designers to really see which approach was leaner, and easily made so. However, I, like many others, find that a forms designer is a starting point .

Unfortunately until PB Forms catches up with PBWin9, it is easier to depart from an interactive mode that loses some of the previous benefit if we use the newer PBWin constructs in some places. We really do need an updated PB Forms, one that is 100% producing the same code that is now engendered by the callback (CB.) and control DDT changes and additions to PBWin 9.

I requested, as have others, that some things (e.g. labels) have an blanket option switch in PB Forms, so they would not automatically be added to the %WM_COMMAND case. However, most of controls are possible candidates to be a %WM_COMMAND control selection.

The alternative, also suggested IIRC, as exclusive or in concert with the foregoing blanket switch, would be a simple check on/off in the controls properties (F4 in PB Forms), to exclude from being a control under the %WM_COMMAND control cracks.

[Barry Marks]

[QUOTE=Gösta H. Lovgren-2;295094]Barry, to confuse you even more, I stopped using any forms designer. What I found was they just confused me with all the "extra code" they inserted. I say "extra" as much of what they inserted didn't have anything to do with what I was doing at the time./QUOTE]

I do find the code produced by forms designers a little confusing, but they confuse me more by their organization than with the extra code. That isn't to criticize their layouts at all. It's just that before I got Forms or EZDLG Designer (the other one I bought) I began with one of the sample programs and figured out little by little just how it worked and how it was organized. The forms designers use a different organization; maybe a better one, but I find it simpler to just keep using the layout I learned first.

I do use Forms quite a bit, as well as EZDLG at times, and samples I find here in these forums, to see how they do things that I want to do. Then I usually do it myself with DDT code, possibly copied from those sources. That way the organization is still what I'm used to.

So far I've found this thread to be pretty helpful. It's been full of suggestions and ideas, some of which I've already looked into, and others that I will look into. It hasn't dealt much with my original question but I guess you can't have everything.

Or maybe it has and I just don't recognize it yet.

Barry

[Gösta H. Lovgren-2]

[So far I've found this thread to be pretty helpful. It's been full of suggestions and ideas, some of which I've already looked into, and others that I will look into. It hasn't dealt much with my original question but I guess you can't have everything.

Or maybe it has and I just don't recognize it yet.

Barry

As you get deeper into PBWin and these forums you'll find the question asked has usally been answered as your was. Just not in a format you understand at the time. This bears repeating

These guys on here are so good and so experienced their advice often overwhelms and bewilders Newbies

For several years (or long time anyway) I lobbied for a separate New User Forum, just for newcomers to PBWin to get their feet wet. An Introduction so to speak to try and cut down on original (continuing?) confusion an introduction Windows brings for a significant number (or maybe just me). I was just a voice in the bewilderness. Still am sometimes. {sigh} Perhaps I should have lobbied for a DDT Only Forum where the more sophisticated approaches (WinApi) are not demonstrated. As someone gets more comfortable he can "move up" to the PBWin and Programming forums.

When do I check that I have the right message for the right control in DDT programs?

In short, you check all the time. That's effectively the purpose of CallBack Functions where the messages wanted (button clicks for example) can be filtered out of the myriad of msgs Windows sends/uses after each action.

=========================================
"I am enclosing two tickets
to the first night of my new play,
bring a friend... if you have one."
George Bernard Shaw to Winston Churchill
"Cannot possibly attend first night,
will attend second... if there is one."
Winston Churchill, in reply.
=========================================

[Barry Marks]

For several years (or long time anyway) I lobbied for a separate New User Forum, just for newcomers to PBWin to get their feet wet. An Introduction so to speak to try and cut down on original (continuing?) confusion an introduction Windows brings for a significant number (or maybe just me). I was just a voice in the bewilderness. Still am sometimes. {sigh} Perhaps I should have lobbied for a DDT Only Forum where the more sophisticated approaches (WinApi) are not demonstrated. As someone gets more comfortable he can "move up" to the PBWin and Programming forums.

I don't mind the confusion. I think it's the love of confusion that makes people want to write programs.

There is a lot of this that's over my head at the moment but that's okay. Exposure to that is a good learning tool.

I don't personally feel a need for a new user forum and from what I've seen of new user sections on other forums I don't think that's any better aproach than this one. However, I am surprised there isn't a forum to focus on DDT.

Barry

[Rodney Hicks]

Power Basic programming for Windows is sort of like going the the grocery store.
You can go to the fresh food areas and get the makings for supper.(SDK)
Or you can go to the prepared packages and cans and get the makings for supper. (DDT)
Or you can buy the ingredient to make some bread and then have the bread with your choice of type of meal. SDK and DDT.
You just got to learn what goes good with what and how to prepare it.
Ergo, keep it all in the same store.(Forum)

[Gösta H. Lovgren-2]

Ergo, keep it all in the same store.(Forum)

Or you can go to a specialty store (butcher, produce stand, bakery, ...) where you get goods/service specifically tailored/targeted to your immediate needs.

================================
"I find that the harder I work,
the more luck I seem to have."
Thomas Jefferson (1743-1826)
================================

[Rodney Hicks]

Or you can go to a specialty store (butcher, produce stand, bakery, ...) where you get goods/service specifically tailored/targeted to your immediate needs.

Ah, Gösta

Yes, of course we can. But it sure spoils my analogy.

[Barry Marks]

You just got to learn what goes good with what and how to prepare it.
Ergo, keep it all in the same store.(Forum)

Not a bad aproach. This is a good forum.

Barry