Thread: MFC vs. WinApp

also, EVERY framework sends messages to the parent. VB, MFC, Java. It is how the button notifies of click. I seriously think you don't understand what needs to be hidden by an object.

example of encapsulation of the button in windows dll....


WM_LBUTTONDOWN
WM_MOUSEMOVE
WM_LBUTTONUP
WM_SIZE
WM_CREATE
WM_DESTROY
etc..

these are messages we never see because windows already hid them. Otherwise they would have been handled in the Button class that I spoke of. THESE are the things that should be encapsulated. sorry if you misunderstood that whole "some messages need to be sent to the parent" thing.

>What you're not understanding is that common controls messages are never seen by us.<

What? How does one actually use a common control then? I must have been hallucinating when I've written LBN_* handlers (which didn't need to be handled by the parent).

>What you're probably looking for is CUSTOM controls where we actually have our own message handling.<

Yes, you could write custom controls to replace all the common ones if you wanted to. No arguments here.

>It is how the button notifies of click. I seriously think you don't understand what needs to be hidden by an object.<

Stop trying to figure out what I don't understand. I'm getting slightly bored of repeating myself. How would you implement a stand alone list box based class? This list box class should be capable of handling the notification messages (LBN_SELCHANGE, etc) that are normally sent to the parent. The parent doesn't need to be notified because all the functionality of the list box is encapsulated in the class. I should just be able to take this class and plug it in my application without having to worry about having to write any message handlers.

>these are messages we never see because windows already hid them<

Hooray. I've had my basic encapsulation lesson. Now I'm getting a lesson in Windows basics. Thanks, man.

What? How does one actually use a common control then? I must have been hallucinating when I've written LBN_* handlers (which didn't need to be handled by the parent).

if you're talking about "handlers" in MFC such as OnSelChange, yes they are handled by the parent window class. that's where the message map lives.

How would you implement a stand alone list box based class? This list box class should be capable of handling the notification messages (LBN_SELCHANGE, etc) that are normally sent to the parent. The parent doesn't need to be notified because all the functionality of the list box is encapsulated in the class. I should just be able to take this class and plug it in my application without having to worry about having to write any message handlers.

Sounds like we're getting somewhere. Here's the deal... The control, as it exists, is designed to send messages back to the parent. simple encapsulation of that control will still send messages back to the parent.

but you don't sound like you want the control "as it exists". What you want is a custom control that USES the common control. For that you will need to handle the messages in your own window. This means that your class will need a window inside it that will be the parent of the common control. Best solution? maybe not but you have to understand that your request is not just an encapsulation of the common control but a change in the way it works.

As far as MFC goes, if there is some message handling in the Listbox object that does not get to the parent it is because they either do what I just described or they subclass the parent wnd callback.

Either way, encapsulation of the common control is done how I described originally and encapsulation of a modified control takes a bit more work. (after all, you are modifying the behavior)

Originally posted by Hershlag

if you're talking about "handlers" in MFC such as OnSelChange, yes they are handled by the parent window class. that's where the message map lives.

because I know you will likely dispute this, I should ask you to surf here http://msdn.microsoft.com/library/en...asp?frame=true and read up. MFC does the same thing

and in the future just understand that I'm always right

>if you're talking about "handlers" in MFC such as OnSelChange, yes they are handled by the parent window class. that's where the message map lives. <

Yes but you use message reflection to enable the control to handle the message in MFC.

>Sounds like we're getting somewhere.<

Yippie.

>Here's the deal... The control, as it exists, is designed to send messages back to the parent.<

Even when it needn't. It doesn't matter if this is how it was designed, it breaks encapsulation.

> but you don't sound like you want the control "as it exists". What you want is a custom control that USES the common control.<

No, what I want is a control that behaves in a self contained manner. You're trying to work around an API that was not designed with OOP in mind.

>For that you will need to handle the messages in your own window. This means that your class will need a window inside it that will be the parent of the common control. Best solution? maybe not but you have to understand that your request is not just an encapsulation of the common control but a change in the way it works.<

Thank you, this should work.

>Either way, encapsulation of the common control is done how I described originally<

It's not encapsulated. You said earlier -

>it is absolutely possible and in fact critical to make all windows into objects. It is a natural way of windows programming<

A common control is a pre-defined window (object), that behaves in a way a C++ object shouldn't. It may have to use other objects to implement its functionality.

>because I know you will likely dispute this, I should ask you to surf here http://msdn.microsoft.com/library/e...frame=true and read up. MFC does the same thing<

I'm no fan of MFC either, but have actually used it before dismissing it out of hand. As I said above MFC enables messages to be handled by the controls with a hack called message reflection.

>and in the future just understand that I'm always right <

Ok.

Originally posted by Enmeduranki

Yes but you use message reflection to enable the control to handle the message in MFC.

reflection is the parent window sending the message back to the control's object. No dice.

Originally posted by Enmeduranki

Even when it needn't. It doesn't matter if this is how it was designed, it breaks encapsulation.

I hate to keep lecturing on what encapsulation is because it obviously bothers you. If a hypothetical control is imagined such that it's responsibility includes notifying the parent about something, a C++ class that encapsulates that functionality should still notify the parent. Parent notification, as in the case of the button is not a break from encapsulation. "reflection" doesn't make it more encapsulated it just allows the object to get the message back that it sent. The selection changing is something the listbox notifies the parent of because a given parent may want to do something in that case. This is how the control is generalized. This is after all what a "plug-in" control should be isn't it?

>reflection is the parent window sending the message back to the control's object. No dice. <

Why not? It may not be clean, but it works. The message is handled by the object it originated from.

>If a hypothetical control is imagined such that it's responsibility includes notifying the parent about something, a C++ class that encapsulates that functionality should still notify the parent.<

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.

>"reflection" doesn't make it more encapsulated it just allows the object to get the message back that it sent.<

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.

>The selection changing is something the listbox notifies the parent of because a given parent may want to do something in that case<

But it may not. It seems flawed to make it have to.

>This is after all what a "plug-in" control should be isn't it?<

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?

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.

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.

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.

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.

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.

MFC is a poor architecture. In the case of the common controls that we have been arguing about it is so unbelievably clear. All C++ developers are aware of the difference between is-a and has-a as it relates to design. MFC screws that up entirely. You see, a CListBox for instance should be a class set in stone. It is after all a control hidden by the system and can not be changed. The control that you have been talking about making HAS A list box in it. You see? You should not be deriving from CListBox but your specialized control should CONTAIN a listbox. The CListBox should just be something that is constant. That is why there is a need for a "reflection", because the entire concept behind MFC is flawed. Surely you have heard people say how poor the architecture is.

Bah, how about neither? The Win32 API is retarded, and MFC is bloated, slow, and error-prone.

ok.

MFC is slow.... hmmm somewhat slower than straight API but faster than everything else.

WinAPI is retarted. Ummm.. dunno what to say about that. It's the closest you can get to actually talking to windows. Everything else is a shell around the API.

Out of curiosity what do YOU use? (please don't say java or VB, I'll die laughing)

I think that they both suck too. What do I use? A different operating system.

ah well a different operating system is fine, but this poll presented a choice between Windows programming options.