Chicken or Egg callback?

[Bob Clarke]

Chicken or Egg

What should come first?
On a relatively average type of dialog callback function
we want to catch user actions on controls,
text boxes, comboboxes, listviews, and buttons.

I'm confused what is the 'right' structure and why
in order to keep all actions within one structure.

Message first and then ID
or
ID first and then Message

CALLBACK FUNCTION xxxCallBack()

 SELECT CASE AS LONG CB.MSG				'windows message
        CASE %WM_NOTIFY
            SELECT CASE CB.CTL  		'control ID
                CASE %LVW_SYSLISTVIEW32
					'do something

        CASE %WM_COMMAND
            SELECT CASE CB.CTL  		'control ID
                CASE %LVW_SYSLISTVIEW32
                    IF CB.MSG = %WM_NOTIFY
                    	'do somethibg

[George Bleck]

Typcially I go by msg type. I think, I got programmed into that because thats the way PBFforms lays it out so I got used to that way.

[Edwin Knoppert]

<mainmessage><ctrlid><submessage>

[Conrad Hoffman]

I also follow PBForms general structure, but it's the same as in the on-line docs about callbacks. What you're really doing is drilling down through the message structure to be absolutely positively sure that you're acting on the user input or other activity that you think you are. Thus the IF/END IF and SELECT CASE statements to filter out everything else. You could probably reverse how you sort it out, but IMO it's better that everybody do it the same way so if you post something nobody has to waste time figuring out an alternate way of doing it for no good reason. If there is a good reason, that's another story. Over the years I've found it's not good to be too clever- other people have to maintain code in a commercial environment. I do notice that people organize their programs differently. I typically have my compiler stuff, include statements and constant assignments, immediately followed by my callback functions. PBMain follows that, then all my subs, then the dialogs at the very end. Again, this is because PBForms does it that way, but it's how I was doing it even prior to getting PBForms. I'll have a separate callback for each dialog and I rarely have a separate function for a specific control anymore.

[Rodney Hicks]

If you look through the samples that come with PBWin 9.0, you'll find a Directory of DDT programs that give some good examples.
If most of the action is going to be under the %WM_COMMAND case then put it closer to the top of the callback. It's not a significant time saver usually, but it does save the amount of checking done to find the appropriate ID(this same applies to the IDs) that you ultimately want.

I find this also keeps the code that I work on most near the top of the callback to some degree. The Code Finder places you at the top of your function and there's a little less time lost in finding the line you want.

[Michael Mattias]

I go control, then message. I like to have all my code for any one control more or less in one place.

[LATER}
Wait a minute, no I don't. I go message, then control, eg, all the WM_COMMANDs are together, all the WM_NOTIFYs together.

Amazing what you forget when you are always copying something else to get you started on a new program.

[Gösta H. Lovgren-2]

Amazing what you forget when you are always copying something else to get you started on a new program.

You forget things?

You?

MCM?

I'm flummoxed. Even crushed. (idols, feet of clay, ... all that)

===================================
Between saying and doing,
many a pair of shoes are worn out.
(Italian proverb)
===================================

[Conrad Hoffman]

I've no doubt that MCM has forgotten more than I'll ever learn. I do sometimes think that I somehow wrote one simple program many years ago in PB for DOS, and every program I've written since is mostly made up of things I've copied from a previous program, the chain ultimately going back to that original PB for DOS program.

[Michael Mattias]

Sometimes I force myself to NOT 'cut and paste' just so I will actually THINK about what I am doing.

Sometimes.

MCM