MFC vs. WinApp

hi,
I noticed that many people here dont appreciate MFC, while I c it very usefull and helpfull, for example MFC gives you the ability to treat the messages from windows os effectivly with almost no great effort, while u ve to write WinMain() to catch the messages and then wright ur own WinProc() with a huge switch statement to respond to the varios messages ..

I would like to discover what do u think about using MFC , and I like to read long explanations full of details supporting ur opinion

thanks in advance :)

the "message map" IS a switch statement. it's just hidden behind macros. I have never found the message map idea to be any easier than just writing the function. it's just about as much code. MFC has a lot of down side. for one, you have a versioning problem because exported classes are a no-no. Name mangling was never standardized and as a result MFC is painfully version dependant. so you application has to distribute it's own version of MFC or you aren't guaranteed that it will work. As I stated above though my main reason for not using MFC is it actually isn't any easier.

Quote:

---

Originally posted by Hershlag
the "message map" IS a switch statement. it's just hidden behind macros. I have never found the message map idea to be any easier than just writing the function. it's just about as much code.

---

Its actually a little more clever than that in the way it passes the messages down to the classes it derives from........but yeah it does a similar thing....

Quote:

---

Originally posted by Hershlag
MFC has a lot of down side. for one, you have a versioning problem because exported classes are a no-no. Name mangling was never standardized and as a result MFC is painfully version dependant. so you application has to distribute it's own version of MFC or you aren't guaranteed that it will work. As I stated above though my main reason for not using MFC is it actually isn't any easier.

---

If you have a decent version of VC++ you can statically link the MFC runtime code....but this does give a bit of a code bloat..

Personally I prefer MFC for GUI as I find it much faster to produce a standard window (and its added dialogs, menus,controls etc...)....I cant see how it is as tedious as creating a window "SDK style"....but then each to thier own...:)

I use MFC a lot, it's not for the feint of heart, but a lot better than writing a WinApp. I have not had any real problems with MFC or MFC DLLs while going through version 5, 6 and not 7 of MSDEV.

I think MS did a great job of writing a set of foundation classes for windows. And personally I think MFC is way ahead of any other class library on the market for writing Windows applications.

I have always hated how C++ guys think they have to use MFC. I do object oriented WinAPI coding all the time. As far as the "cleverness" of the message map goes.... Here's how I determine which class I'm in for Win32 API C++ coding:

Code:

---

long APIENTRY WindowProc(HWND hWnd, UINT iMessage, WPARAM wParam, LPARAM lParam)
    {
    ClassName *This = (ClassName *)::GetWindowLong(hWnd,GWL_USERDATA);
    if(iMessage==WM_CREATE)
          {
          CREATESTRUCT *cs = (CREATESTRUCT *)lParam;
          ::SetWindowLong(hWnd,GWL_USERDATA,(long)(This = (ClassName *)cs->lpCreateParams));
          This->m_hwnd = hWnd;
          }
    return This?This->CallBack(iMessage,wParam,lParam):0;
    }

---

This makes Callback() your "Message Map" and it works well. This is no harder than learning acres and acres of MFC macros.

> I do object oriented WinAPI coding all the time.

Is it possible to encapsulate all message handlers for child windows within their own class (rather than having a parent class handling them), using WinAPI? I've not really looked into it but this is often brought up as a reason why C++ and straight WinAPI don't mix. How do you know when writing the parent class, that it's going to have to handle the messages of child classes that may not have been written yet?

Enmeduranki, it is absolutely possible and in fact critical to make all windows into objects. It is a natural way of windows programming. Of course parent windows will need to be notified of certain actions such as button clicks but that is why you used a button in the first place, to notify the parent of an action to be requested in that window.

All windows with callbacks can be encapsulated nicely. All children can have their own encapsulation.

Quote:

---

Originally posted by Enmeduranki
I've not really looked into it but this is often brought up as a reason why C++ and straight WinAPI don't mix.

---

This is unfortunate. Please tell whoever told you this that MFC is an encapsulation of the Win32API and therefore a "mix" of C++ and WinAPI. So if they were arguing for MFC on this point they should be put to sleep.

>Of course parent windows will need to be notified of certain actions such as button clicks but that is why you used a button in the first place, to notify the parent of an action to be requested in that window.<

This is not encapsulated. A child class should handle it's own messages. How would you develop a library of self contained child controls (based on the existing common controls) that can be 'plugged' into an application?

you are not understanding encapsulation then. Let's focus on buttons since that seems to be the easiest. Encapsulation means you can do something like this:

Code:

---

Button mybutton;
mybutton.CreateWnd(parentwnd, x, y, w, h, "text");

---

and be done with it without calling any API directly. Here's the way it would work...

parameters:
parentwnd is needed cause the button needs to know where it is created (true in MFC of course). x, y, w, h is obviously positioning info on the parentwnd, "text" is obvious.

Let's pretend that the button text is "Exit" and it means the window needs to be closed. obviously this is an action intended for the main window. Therefore it is a message sent to the parentwnd and NOT the buttonwnd. The button window will handle those appropriate to itself but messages sent to the parent are OBVIOUSLY (to any reasonable person) still within the bounds of the object oriented encapsulation.

I understand what you are trying to do. You are attempting to say that the button class itself should handle the click. Not true. How should he exit the parent window if it is handled internally. That's just nonsense.

COM has an example of this sort of thing (parent being called by child) It's called events. Get used to it. It's within the bounds of reason for C++ and does not break from proper encapsulation.

Think... Think... Think....

I believe I know why you are confused on this one. Messages appropriate for the encapsulated window would be handled in that class. Messages appropriate for the parent window would be sent to the parent class. Thus the encapsulation of messages is present I think that's what you are after. but windows MUST send messages to eachother in some form otherwise how could a parent know that his button did something? how could he know to close in an exit button? Notification is after all the purpose of a button.

>Let's focus on buttons since that seems to be the easiest<

No, lets not. Let's focus on a common control, as stated in my last response.

Thanks for the encapsulation lesson anyway.

"Button" IS a common control genius

>Messages appropriate for the parent window would be sent to the parent class. Thus the encapsulation of messages is present I think that's what you are after.<

Yes, but you don't have the choice. If you want the listbox, button, etc to be self contained it's not possible. How would I create a class to list and run execs using the standard list box. No message needs sending to the parent window. Using the API, every time I create an application and want to use my custom list box based class I've either got to re-type or copy/paste the code that that should be handled by the child to the parent.

>but windows MUST send messages to each other in some form otherwise how could a parent know that his button did something?<

Why does the parent need to know? I'm not disputing that some messages need to be passed between windows, but that messages are passed to the parent even though they could (and should) be handled by the child. This breaks encapsulation.


>"Button" IS a common control genius

Sorry, you're correct. But your example is fudged. If the message is intended for the parent, of course it doesn't break encapsulation. However, in your over-eagerness to use a 'simple' example you completely missed the point.

no I didn't miss the point. What you're not understanding is that common controls messages are never seen by us. they are hidden in windows dll's and handled inside windows dlls. What you're probably looking for is CUSTOM controls where we actually have our own message handling.

one of my initial replies handled that issue. all messages intended for a particular window would be handled nicely by that window's object. "encapsulated"

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.

Quote:

---

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.

Quote:

---

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)

Quote:

---

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 :cool:

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

Quote:

---

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.

Quote:

---

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?

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.

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.

Quote:

---

Out of curiosity what do YOU use?

---

Which do I use? MFC. I don't prefer it over the WinAPI, it just means I don't have to repeatedly throw up on my keyboard while coding. I plan on looking into C# when I want to really start coding for windows, right now it's just little utilities and such.

Quote:

---

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

---

What's "everything else"?

Quote:

---

It's the closest you can get to actually talking to windows. Everything else is a shell around the API.

---

Okay, does this make it any less retarded?

I didnt get yet any strong reason to describe MFC as a weak archetcure !!!

may I ask about any other helpfull libraries for windows programming in C++ except MFC?

Strong reason ??

MFC was made by Microsoft..

did you ever use their Blundows operating system?? if you did, you'll know...
MFC is not fun to write big programs.. could be horrible.

Well, I have to admit that I'm not as anti-Microsoft as a lot of people are. In fact, I think Windows was well done in large part. *ducks to avoid flying objects*

I think MFC is a poor architecture because it violates several things that I would call good design. I know that design is a matter of preference but a few of these things are widely accepted in C++.

1. It is macro heavy for virtually no good reason.
2. To use a control that is SET IN STONE you derive from it thus violating the correct is-a has-a relationship (as discussed previously).
3. It uses exported classes which is not compiler or version independant and requires either static linking or multiple versions of the same dll. Any good COM discussion should explain this one to you.
4. It basically is nothing more than a thin wrapper around the API (with a few exceptions) and this does not simplify anything. If you are learning MFC, you are learning JUST AS MUCH as if you just learned the API.

that's all I can think of right now.

Quote:

---

Originally posted by Dual-Catfish

What's "everything else"?

---

VB, Java, Delphi, etc... other ways of coding for windows.

Quote:

---

Originally posted by moemen ahmed
I didnt get yet any strong reason to describe MFC as a weak archetcure !!!

may I ask about any other helpfull libraries for windows programming in C++ except MFC?

---

QT's API runs on both MS Windows and Linux/Unix. Maybe even Solaris.

MFC isn't an architecture, it is a solution to an architecture. I have heard that MFC is poor OOP design however I have not investigated the reasons. This is even mentioned in Charles Petzolds book on Win32. MFC is an Adapter, also known as wrapper classes.

Motivation for an Adapter pattern: Sometimes a toolkit class that's designed for reuse isn't reusable only because its interface doesn't match the domain-specific interfaces an application requires.

Quote:

---

Originally posted by Hershlag Well, I have to admit that I'm not as anti-Microsoft as a lot of people are. In fact, I think Windows was well done in large part. *ducks to avoid flying objects*

---

And you can tell this from an interface? Remember you are looking at an interface, not an implementation. I think that the Win32 API is terrible.

I'm not talking about their code obviously. the operating system architecture on the binary level can be seen by all though, DLLs and such. besides I'm mostly talking about the general reliability and usability that everyone likes to complain about.

you should register so we can put a name to the comment

so ppl what ll be ur advice to someone whos a newbie to windows programming(in c++) to learn MFC,winAPI......or what ???

books and tutorials ll be nice with ur reply :)

depends on how much of a newbie you are to C/C++. If you are very good with C/C++ I say go for WinAPI (you knew I would say that) Otherwise try out VB or something. Windows in C/C++ is tough for a lot of people and takes a lot of practice. Give it a shot though.

but understand that if you learn MFC you should take a look at the straight API. You'll realize that they are the same thing. MFC is just a wrapper. You'll have to decide if you WANT a wrapper like the rest of these people.

Book -> Petzold - Win32 Programming

first thanks for responding :)
definitly im not into stepping back to VB( i used to program in VB, in fact till now i gain money by making programs in VB) but i chose to step into C++. so i ve already learnt alot about c++ and im now ready to go to windows programming

so I think that learning more about API ll be the right choice (as I already used some WinAPI in VB)

ty :)

When you use C++ or any structural lightweight language you should strive for generic design. Learn how to plan, learn how to identify with solutions technologies (design patterns) that are used to solve architectural constraints. Only than can you know what to use, and what you need.

Quote:

---

Originally posted by TK
When you use C++ or any structural lightweight language you should strive for generic design. Learn how to plan, learn how to identify with solutions technologies (design patterns) that are used to solve architectural constraints. Only than can you know what to use, and what you need.

---

I couldn't agree more. especially with the generic design comment. People fail to create reusable code when they don't strive for this. It is part of the glory of OOP, so don't forget about it! And I do agree that it depends on what he's trying to accomplish. That's why I suggested VB as a possibility. It makes him a different dev type but it is a valuable/fast paced method of development.

Quote:

---

Originally posted by Hershlag

---

You are more adept at C++ than I am currently, however you don't seem to understand where the solution tehnologies originated, nor do you support the the purpose of the langauge.

Quote:

---

Originally posted by TK

You are more adept at C++ than I am currently, however you don't seem to understand where the solution tehnologies originated, nor do you support the the purpose of the langauge.

---

What are you talking about, I wasn't arguing with you.

Who is using the C++ language? Surely it is not the developers but the vendors (used as a weapon). C++ can be used to apply solutions. The solutions are re-curring in software. Find them, they are out there, documented, and open.

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.

Oh, you're back.


One statement and one statement alone I will respond to.

Quote:

---

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

---

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. The one's you keep referring to as the control's messages ARE THE PARENT'S MESSAGES

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

Quote:

---

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"?

Quote:

---

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.

Quote:

---

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.

Quote:

---

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

LMAO.

---

*sigh*

Quote:

---

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?

TK is an annoying creature. He pops his head in to throw out software marketing buzzwords and ramble about what appears to be theoretical nonsense. It would be nice if he actually contributed in such a way as to resemble someone with programming knowledge but so far, no such luck.

I wouldn't get frustrated so easily. What computer science topics other than Win32 and C++ have you investigated.

what a troll

Quote:

---

Originally posted by Hershlag
what a troll

---

Well if I told you TK stood for Troll King how would you react? :)

Yeah Fordy, he was the one p***ing us off by saying new compilers will be faster than ASM...

Yeah I know who he is......He's been around for a real long time.....

He's as much part of this board as the CProg Logo

howdy,
now be nice when you answer this one, i can tell from the last 5 pages you do have it in you.
How would you rate Borlands VCL to M$ MFC. i imagine they are both similar in wrapperness (new word) but different in thier respective aproach.
if you flame me i'll tell tk to come back and with his wealth of knowledge and ask another question.:rolleyes:

M.R.

You called Microsoft M$ so I assume your mind's already made up. I don't know about borland's version but I do know that there is a version of MFC for borland's compiler. MFC is in wider use. dunno what else to tell you cause I haven't used VCL

howdy,

Quote:

---

I assume your mind's already made up.

---

i didn't mean to offend you with my symbology i ask this question only because i have C++ Builder 5 and not VC++. actually i'm about 9 monthes into learning C++ and want to take the step into windows programming.

if it matters i have spent most of my time in Linux on EMACS, i just like the way gcc works with EMACS.


M.R.

If you work in Linux too, why don't you learn wxWindows? It is platform independent and sort-of MFCish.