Quote:
Originally posted by Enmeduranki
Why not? It may not be clean, but it works. The message is handled by the object it originated from.
I didn't say it was wrong to do that. Just that it is STILL the parent that is getting it.
Quote:
Originally posted by Enmeduranki
We appear to be going round in circles here. If a class is designed that has the responsibility to send messages to its parent even though they may not be relevent to the parent then it's been poorly designed.
If having to re-explain the basics to you is going around in circles then so be it. The job of creating a generalized control involves supporting features that the parent may or may not want to use. It is not poor design to support more features.
Quote:
Originally posted by Enmeduranki
Thereby allowing the message to be handled by the class in which it originated. Which will keep the functionality of a class where it belongs.
You should lose the assumption that it "belongs" there. It is a generalized control. If you handle the message inside the control itself you have un-generalized it to a point. It only "belongs" there if you don't want it to be generalized.
Quote:
Originally posted by Enmeduranki
But it may not. It seems flawed to make it have to.
Flawed? nah. There are lots of windows messages that you get that you don't have to handle. This being one of them. If you don't want to do anything with this message, don't set up a message handler for it.
Quote:
Originally posted by Enmeduranki
It depends on what you want the control to do. You may want to customise a static control to always paint it's background with a certain brush. Why should the parent class need to handle this?
That's why you're not really talking about a plug-in, generalized control here. Thus you need to get used to the idea that you aren't actually plugging in a listbox control. You are changing the way a listbox works.
I don't know if you are familiar with COM or not but basically it is microsoft's newer way of handling objects across DLL boundaries. They recognized that controls are not to be derived from in the way MFC does. It's just wrong. You are to get an instance of the control itself and use it. That's most of the problem with where you are coming from. The control shouldn't be handling a control message. The container should.