Testing the value of CB.CTL and CB.CTLMSG

[Barry Marks]

The help says:

When a Callback Function receives a %WM_COMMAND message, it should explicitly test the value of CB.CTL and CB.CTLMSG to guarantee it is responding appropriately to the notification message.

I wonder if someone can talk about this a little. I know how to do it with a button although I don't really understand why I look for CB.CTLMSG=1. I think I'm just not clear enough about what's going on here to assemble a real question.

This keeps coming up when I try to use a control that I want to try to get button clicks from that I can't find an example for. In the current case I want to get button clicks from a DDT progress bar and I haven't any idea what to check for in CB.CTLMSG or if I need to check at all.

However, I'd really rather just understand what's going on then to have someone tell me what to check for in this case. I always wonder if I've covered the situation correctly in other things I've written and if they might bite me someday. Actually that happened once some time ago but I'm healed now.

Any help will be appreciated.

Barry

[Michael Mattias]

>although I don't really understand why I look for CB.CTLMSG=1. I think I'm

That one had me stumped for a long time, too.

That's tested to check to see if you got WM_COMMAND with the same value as that of a control from a source other than the control itself... eg a BN_CLICKED notification from a button.

You can get WM_COMMAND with a "CTB.CTL" equal to a 'control id' from a keyboard accelerator in which case the "code" (CB.CTLMSG) will be 1, but you don't get a BN_CLICKED message.

You can also get WM_COMMAND from a menu, in which case "CB.CTLMSG" will be zero.. also not a BN_CLICKED message.

This can let you know HOW you came to get the WM_COMMAND from the "CB.CTL" : by click, by menu, or by accelerator.

That said, with Button controls...

%BN_CLICKED        = 0
%BN_PAINT          = 1

.. and BN_PAINT is not sent under 32-bit Windows.


>want to get button clicks from a DDT progress bar

The standard "msctls_progress32" Common Controls Progress bar does NOT return clicks as part of its standard notification message set. You could probably subclass that to pick off WM_LBUTTONDOWN.

I do not know what the PB "CONTROL ADD PROGRESSBAR" supports, but the documentation does not indicate any support for clicks.

The standard Microsoft Progress Bar control was not designed as an 'input' control... it was designed as an 'output' control, which is why it does not provide any notifications of 'user input' events such as clicks.

MCM

[Barry Marks]

Thank you. That clarifies things quite a bit.

About the progress bar, I was just writing a simple program to learn how to use the Progress bar control and I got one working fine and was thinking about adding some user control over it. I didn't realize there was no provision for input messages. I think I'll wait until I have a real need for it.

I do remember seeing an MP3 player in the source code forum a couple of years ago that did react to mouse clicks by changing the play position and I remember that that was subclassed. I guess I just assumed that the DDT version would include that capability.

Thanks for the explanations.

Barry

[Barry Marks]

I have a followup question about subclassing the progress bar to get mouse clicks. I've done a little subclassing but not a lot. Mostly graphic controls. Something I haven't done with PB is objects. I have no real experience with OOP. I was a procedural programmer for a long time. I did take a class (the kind you attend, not declare) in C++ a couple decades ago and I wrote a couple of very small OOP programs to see if I was interested and never went back to it.

I've been thinking of taking a look at OOP in PBWin and I wonder if this might be a good place to try it out. I don't really expect any problems with the subclassing. I find that confusing but not terribly. It seems like if I did make it an object it would be easier to apply it to some other program if the need arose. I don't really have enough understanding of OOP to know if this would be a likely candidate.

[edit]
Also if I did this could I do it with the DDT progress bar or should I do it with an API progress bar?
[end edit]

Does anyone have any thoughts on this?

Thanks,
Barry

[Michael Mattias]

Subclassing a window and using the Object design and OOP-syntax are totally unrelated.

Also if I did this [subclassing assumed] could I do it with the DDT progress bar or should I do it with an API progress bar

You could try it with a control created by CONTROL ADD PROGRESSBAR, as the 'hctrl' returned by CONTROL HANDLE is a standard Windows' window handle.

What you don't know and may or may not affect what happens is if the DDT engine does anything special with the control created by CONTROL ADD PROGRESSBAR which would be inconsistent with user subclassing. I doubt it because other controls seem to subclass without incident, but it is something to keep in mind.

Note that users normally would not expect anything to happen when they click on a progress bar; and if there is some action available while that progress is, well, progressing, there's usually an explicit button such as "abort" to perform that action.


MCM

[Barry Marks]

What I was thinking of was the MP3 player I saw somewhere in these forums some time ago where a progress bar indicated the play position and clicking on it could change the play position.

I don't really have a use for something like this as the moment. I thought it might be something useful to know how to do. Most of my programming anymore is just playing around and I guess I'm looking for a direction at the moment.

Thanks,
Barry

[Michael Mattias]

What I was thinking of was the MP3 player I saw somewhere in these forums some time ago where a progress bar indicated the play position and clicking on it could change the play position.

Perhaps a trackbar control would be a better choice here than would be a progress bar?

That can show 'progress' or 'position', and was designed to accept user input.......

???

MCM

[Barry Marks]

Perhaps a trackbar control would be a better choice here than would be a progress bar?

That can show 'progress' or 'position', and was designed to accept user input.......

???

MCM

Thanks. I'll look at that.

Barry

[Barry Marks]

Back to my original question, I'm still confused about these messages. Now I'm playing with a textbox, actually two of them, and the messages are again confusing me. I don't know what to test for. I have the following structure, leaving out the unessentials:

SELECT CASE AS LONG CB.MSG
   CASE %WM_COMMAND

        CASE %TXT_INPUT
              IF CB.CTLMSG = %BN_CLICKED THEN
                 CONTROL GET TEXT CB.HNDL, %TXT_INPUT TO textstring$
                 CONTROL SET TEXT CB.HNDL, %TXT_OUTPUT, textstring$
              END IF

        CASE %TXT_OUTPUT
             IF CB.CTLMSG = %BN_CLICKED THEN
                 CONTROL GET TEXT CB.HNDL, %TXT_OUTPUT TO textstring$
                 CONTROL SET TEXT CB.HNDL, %TXT_INPUT, textstring$
             END IF

    END SELECT
END SELECT

It seems to me that entering text into one textbox should see it copied into the other. If I comment out the conditionals then it does. But with them there nothing happens.

I've been looking for information on which message(s) to check for and I don't seem to find it, or recognize it.

I'm trying to make a little unit converter so eventually it won't be a straight copy.

Again thanks for any help.

Confused Barry

[Michael Mattias]

Buttons send notifications with "BN_xxx" prefixes.

Edit ("textbox") controls send notification messages with "EN_" prefixes.

Each control has its own discrete set of notification messages it will send. Fortunately the symbolic names pretty much use unique prefixes so they are pretty easy to find in your Windows' API reference.

(Doesn't Gary Beene's site have some kind of "what notifications are sent by what controls" quick reference? Maybe, maybe not, but you should check out his site anyway if you are just getting started. Let me see if I have it bookmarked...nah, but I think it's just something like "garybeene.com". Google should find it).


MCM

[Barry Marks]

I went to Gary Beene's site and found %EN_CHANGE and that did it.

Thanks again,
Barry

[Walt Thompson]

Hi Barry;

If you're interested in using trackbars this may be of some help.

http://www.powerbasic.com/support/pb...ad.php?t=39084

[Michael Mattias]

> went to Gary Beene's site and found %EN_CHANGE and that did it.

Now isn't that better? Instead of changing the text on every CLICK*, you only change it when the text ACTUALLY CHANGES!

You'll find the notification messages sent by controls are really well thought-out.. when you get a message is tied quite nicely to "things the user can do."

Back to your progress bar thing... while you don't get 'input mesages' from the progress bar, Mr. Thompson's link shows you you DO get 'input messages' from the trackbar.

MCM
*BTW, you COULD detect every click but I was not going to send you down that road even though that's what you asked for. Moral of the story: careful what you ask for, you may get it!!!

[Barry Marks]

Hi Barry;

If you're interested in using trackbars this may be of some help.

http://www.powerbasic.com/support/pb...ad.php?t=39084

Thanks! I didn't know about those. I don't need them at the moment. I'm just trying to play around with some controls and messages and see how they work. I'll put this on the list of controls to learn about.

This windows stuff is all really pretty silly.

Barry

[Michael Mattias]

>This windows stuff is all really pretty silly

You are kidding, right?

Maybe it stinks for gaming, or scientific stuff, or some other things, but Windows provides a terrific environment and outstanding API for business applications.

MCM
(makes living creating business applications in case you had not guessed)

[Barry Marks]

> went to Gary Beene's site and found %EN_CHANGE and that did it.

Now isn't that better? Instead of changing the text on every CLICK*, you only change it when the text ACTUALLY CHANGES!

You'll find the notification messages sent by controls are really well thought-out.. when you get a message is tied quite nicely to "things the user can do."

*BTW, you COULD detect every click but I was not going to send you down that road even though that's what you asked for. Moral of the story: careful what you ask for, you may get it!!!

Now I'm confused again. I'm getting messages with every keypress, not click. Is that what you mean? I had expected that I'd get the text when the enter key was pressed or it lost focus or something.

Barry

[Barry Marks]

>This windows stuff is all really pretty silly

You are kidding, right?

Maybe it stinks for gaming, or scientific stuff, or some other things, but Windows provides a terrific environment and outstanding API for business applications.

MCM
(makes living creating business applications in case you had not guessed)

I'm kidding and I'm not kidding. I realize it has value. I'm just not used to dealing so much with user interfaces. I've been using Windows for years and I like it but I've done very little GUI programming. Nearly all my experience was with a command line interface.

Truth to tell, I doubt I'd have been a particularly good GUI programmer in my prime and starting this late is more than a bit confusing. That's okay. As a programmer I learned to enjoy confusion. It just wears me out easier these days.

Barry

[John R. Heathcote]

This windows stuff is all really pretty silly.

IMO, Windows is not so much silly as it is frustrating, inconsistent, and confusing. The many different and separate Windows messages and notifications for each control which essentially perform the same functionality leads to a certain amount of confusion for the user to comprehend, especially newbies.

[Michael Mattias]

>I'm getting messages with every keypress, not click

Yes, you are ( not really but we'll get to that later). That's what the edit control does.

My point was, you originally wanted to know when the user CLICKed on the control.. at least that was what you asked for. But that was not what you really wanted... because if the user had not changed the text, you did not want to waste valuable computer time performing a useless update. What you wanted to know was, did the user CHANGE the text, necessitating an update of the companion control?

On the 'not really'.... you only get EN_UPDATE notification messages when the user has pressed a key which has resulted in a change of the text. Eg, you don't get that notification when the user presses the left or right arrow keys or F1, because those keystrokes do not change the text.

MCM

[Michael Mattias]

IMO, Windows is not so much silly as it is frustrating, inconsistent, and confusing. The many different and separate Windows messages and notifications for each control

That's the classic 'designer's tradeoff': Easy of use versus flexibility.

You want easy to use with fewer options, and can settle for fewer options? Use Microsoft Visual Anything and you got it.

You want all the options at the cost of some complexity? Use PowerBASIC products.

In either event, the operating system provides all you need to go either way. You just have to decide if you want to use the big boy tools or the kiddie tools.



MCM