ON_NOTIFY_RANGE problem!

TPN

Hi all, I design a form with about 50 combo boxes and I want to handle the notification message CBN_SELCHANGE of those combo boxes in a same routine, so I use the macro ON_NOTIFY_RANGE(CBN_SELCHANGE, IDC_COMBO1, IDC_COMBO50, MyMsgHandler). But it seems that nothing happens. Am I wrong? Pls help me to solve this. Thanks in advance.

kanduripavan

ON_CONTROL_RANGE try this. I hope it will solve the problem

Roger Stoltz

What happens if you use ON_NOTIFY for only one of the controls?

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

TPN

Thanks you for your help! I don't want to use ON_NOTIFY because there are many controls and this will cause many ON_NOTIFY macro. I try with ON_CONTROL_RANGE and it work fine. But I am still not clear the difference between ON_NOTIFY_RANGE and ON_CONTROL_RANGE... Once again, thank you.

Roger Stoltz

TPN wrote:

I don't want to use ON_NOTIFY because there are many controls and this will cause many ON_NOTIFY macro.

I know, my point was that if something doesn't work you should revert to the easiest way to test that you've got the concept down correctly. You thought there was something wrong with your use of the ON_NOTIFY_RANGE mechanism, but if you would have tried with the simpler ON_NOTIFY you would have found that it won't get called since the control sends a WM_COMMAND notification and not a WM_NOTIFY notification.

TPN wrote:

I try with ON_CONTROL_RANGE and it work fine. But I am still not clear the difference between ON_NOTIFY_RANGE and ON_CONTROL_RANGE...

The difference is that it handles two separate windows messages: WM_COMMAND and WM_NOTIFY. For actions that send WM_COMMAND notifications you have to use ON_CONROL_RANGE. WM_NOTIFY was introduced with Win32 API to send notification messages that requires more information and the message handler receives a pointer to a NMHDR struct with control specific data. WM_NOTIFY didn't exist in Win3.x API.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

James R Twine

To further clarify Roger's point - the "older" Windows controls, meaning the ones available in 16-bit Windows like Button, Edit, Static, ComboBox, ListBox, etc. all use WM_COMMAND for their notification messages. The "new" 32-bit common controls, such as the ListView, TreeView, Progress Bar, Slider, Rich Edit, etc. all use WM_NOTIFY for their notification messages. If using MFC, the easiest way to tell the difference is that the older control's wrapper classes do not end with **Ctrl** and the newer ones do. For example, the MFC class for the (older) Button is CButton and the class for an (older) Edit is CEdit, while the class for a (newer) Rich Edit is CRichEdit**Ctrl** and the class for the (newer) TreeView is CTree**Ctrl**. So if your control's wrapper class ends with **Ctrl**, use the WM_NOTIFY-based handlers. Peace!

-=- James
Please rate this message - let me know if I helped or not! * * * If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles

Roger Stoltz

James R. Twine wrote:

So if your control's wrapper class ends with Ctrl, use the WM_NOTIFY-based handlers.

Good point James. Hi 5 for that.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

James R Twine

Danka!

-=- James
Please rate this message - let me know if I helped or not! * * * If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles