Thread: MFC vs. WinApp

you're on crack there chief

>Just that it is STILL the parent that is getting it. <

But it isn't necessarily processing it. Which is the point.

>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.<

The parent may want to use them, but the functionality belongs with the control. In a modern OOP GUI based language (not one that is hacked together from an old C API) you install event handlers into a instance of a control. The control 'owns' the handlers. The parent sends the message to the control.

>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. <

Why doesn't it belong there? You are able to write message handlers for the parent window, so why not for the control?

>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.<

I've had very limited experience with COM so I'll have to take your word for it, but Microsoft must have regressed since they developed it because with C# the controls handle the messages.

>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.<

Rubbish. A list box is a list box. A specialised list box is a list box.

>Surely you have heard people say how poor the architecture is.

Yes, but I think this is due to a large extent on what MFC is built on top of.

>One statement and one statement alone I will respond to. <

Why only one? Please tell.

>Windows handles the control messages internal. You never see them. Until you understand this point, you will never be able to understand why the control's object doesn't get "it's own" messages.<

What a suprise, I need to understand something. I thought we'd already been through this. Lets take a look at exactly what I wrote -

Why doesn't it belong there? You are able to write message handlers for the parent window, so why not for the control?

Where exactly does it say anything about a control "getting it's own messages"?

Originally posted by Enmeduranki
>One statement and one statement alone I will respond to. <

Why only one? Please tell.

because until you understand this, your other questions are irrelevant.

Originally posted by Enmeduranki
Where exactly does it say anything about a control "getting it's own messages"?

how about "You are able to write message handlers for the parent window, so why not for the control?"

do you know what a message handler does or not?

>because until you understand this, your other questions are irrelevant.

LMAO.

>do you know what a message handler does or not?<

Ok, time for some fun. Spot the differences -

The parent will recieve a message and then pass it to the relevent control. Upon this being done the event handler will be executed. This event handler has been inserted into an object of the control.

The windows operating system will recieve a message and then pass it to the relevent window. Upon this being done the event handler will be executed. The event handler has been inserted into an object of the WNDCLASS.

This was all I was trying to say. Sorry you jumped to conclusions.

Originally posted by Enmeduranki
>because until you understand this, your other questions are irrelevant.

LMAO.

*sigh*

Originally posted by Enmeduranki
Ok, time for some fun. Spot the differences -

The parent will recieve a message and then pass it to the relevent control. Upon this being done the event handler will be executed. This event handler has been inserted into an object of the control.

The windows operating system will recieve a message and then pass it to the relevent window. Upon this being done the event handler will be executed. The event handler has been inserted into an object of the WNDCLASS.

This was all I was trying to say. Sorry you jumped to conclusions.

ok? a quote from somwhere in MSDN? comparing the difference between MFC and WinAPI I assume?

it sounds as if you know MFC and not the API. I could be wrong on that one but I'm not sure if that had been mentioned. But here is why I have been saying that MFC has it wrong.

case 1:
if you Create a window of your own, you make a WNDCLASS and fill it in with a "Callback" function. This is a message handler at it's lowest, most true level. It handles all WM_* messages sent to a window.

case 2:
If you create a window of a common control WNDCLASS such as a listbox, you did not create the WNDCLASS and you have not created the callback. Those things are inside windows in this case.

in case 1, you get the messages for that window. In case 2 you do not. Therefore, the messages you speak of being handled by the control's object are case 1 parent messages. No matter how MFC blurs that fact, it is still fact.

>ok? a quote from somwhere in MSDN? comparing the difference between MFC and WinAPI I assume?<

No, that was penned by my own fair hand a few moments ago. I wasn't really thinking about the differences between the API and MFC, just showing how it could be (and is in some languages) done. I've never really used (or care to use) MFC extensively.

>Therefore, the messages you speak of being handled by the control's object are case 1 parent messages. No matter how MFC blurs that fact, it is still fact.<

Yes and the C++ language blurs what is going on underneath. That's one of the side affects of OOP or any high level language that builds on something else.

blur in this context means twists/changes facts

C++ does not do that, it ABSTRACTS. Very different

look, I don't care to argue this anymore. Your mission appears to be to show that WinAPI is stupid. In the process you are attempting to say that C++ is limited in its ability to handle it. I have made my argument that C++ can "mix" with anything you please but you can go on believing what you want to believe.

>blur in this context means twists/changes facts

C++ does not do that, it ABSTRACTS. Very different<

By your reasoning C++ will probably twist facts. Compilers don't normally produce OOP assembly. I wouldn't be suprised if the API didn't twist facts to provide a convenient interface.

>look, I don't care to argue this anymore. Your mission appears to be to show that WinAPI is stupid. <

Where have I said that?

>In the process you are attempting to say that C++ is limited in its ability to handle it.<

I'm saying that the WinAPI wasn't designed with OOP in mind (which isn't necessarily a bad thing in some peoples opinion).

>I have made my argument that C++ can "mix" with anything you please but you can go on believing what you want to believe.<

Ok.

No No No... I must have the last word!

You are arguing about how the Win32 API works. How it handles a process. I think that you should look at the constraints, the reason why the solution was used, what problem did it solve. The nice thing is that the solutions are generic, basically all of the API can be generalized. Dig deeper.

Not nearly as much technology is created as the amount of technology that is simply reused. If I reuse some solution and I am a vendor, is that really my solution? Only if you never knew the origin.

>You are arguing about how the Win32 API works.<

Nobody was arguing about how the API worked.

>The nice thing is that the solutions are generic, basically all of the API can be generalized. Dig deeper.<

Thanks for that pearl of wisdom. I don't know what we'd do without you.

>Not nearly as much technology is created as the amount of technology that is simply reused. If I reuse some solution and I am a vendor, is that really my solution? Only if you never knew the origin.<

I'm not sure what your point is, but if you're a software developer then aren't you always re-using someone elses technology?