Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

newbies question

Posted on 1999-08-03
43
Medium Priority
?
305 Views
Last Modified: 2010-04-02
I am new to visual c++
if i use appwizard to make a simple window application .. which could be "Hello World" as well...
could someone please explain me the programme flow for this application ..
By the term programme flow i mean that from where it starts and where it ends.
0
Comment
Question by:daknight2000
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 15
  • 13
  • 8
  • +5
43 Comments
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201674
The program starts in the equivalent of the WinMain function.  This is where your Window is created and displayed.  Then, the program enters what is called the message loop.  This is where the program waits and receives messages from windows.  The messages received by the message loop are handled (work is done with them) in the MainWindowProc, which you write.  These messages are WM_CREATE, WM_PAINT, and other messages to create the window.  On either of these messages, you can place the text display functions (of your choice) to say "Hello World".  When you close the window, using F4 or X, the window receives a WM_CLOSE and WM_DESTROY messages, in sequence, closing and cleaning up the window, and exiting the Message Loop in WinMain.  

If you want more examples, please ask.
0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201675
Note:  There are many other messages that your windows program receives, that you never see nor handle.  Windows is set up to handle these by default when you don't handle them.  These messages can be sent directly to your program (SendMessage), or placed in the message queue to be interpreted in your message loop (PostMessage).  Messages placed in the queue are read sequentially, after all messages sent directly by windows to your program.  There is very little to be seen as "flow" in a Windows program, as the program is many times a group of methods to take care of different events, instead of a line of actions to be taken in sequence.  

Laminamia :)
0
 
LVL 3

Expert Comment

by:Try
ID: 1201676
To add to what "Laminamia" has stated, unlike DOS programs that call the Operating System (for such things as Input and Output), the opposite is true of Windows programs; it's the Operating System that calls the programs, ... by way of messages (a message for this, a message for that, etc.).  IOW, your program is asleep all the time.  It wakes up whenever it receives a message from the Operating System (which means sometimes it hardly gets any sleep because messages are always coming to it).

This also means that your program DOESN'T KNOW what messages it will be receiving MOST of the time (AAMOF, nearly all of the time).  Keep this fact firmly in mind: as far as your program is concerned, messages arrive RANDOMLY.  With very few exceptions, your program doesn't know what message will be next, and that's where the 'Message Pump' (or 'Message Loop' as "Laminamia" earlier referred to it) comes in.  It, (i.e. the 'message pump') decides what function in your program will be handling which message (by way of a Message Map).

Messages that end up in your program that don't belong to program, are returned back to Windows (the Operating System) for it to take care of.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201677
Good comments daknight2000 :)

This can lead to some interesting considerations:  You have to be careful about initializing variables, because you have to be sure they aren't used before they are initialized or the memory for them is allocated.  Generally, it's not too hard to handle messages that you want to handle, but many times one message you want is really two, or three or more messages.  

Example:  You want to do something on the right button mouse click and something else with the double click of the right button.  These are the corresponding messages:

//Right Button Click
WM_RBUTTONDOWN
WM_RBUTTONUP

//Right Button Double Click
WM_RBUTTONDOWN
WM_RBUTTONUP
WM_RBUTTONDBLCLK
WM_RBUTTONUP

Notice, the messages contained in the first action are also in the second.  You have to be very careful about how you deal with these messages.  What you see isn't always what you get.  You usually get more :)

Laminamia

0
 
LVL 3

Expert Comment

by:Try
ID: 1201678
"Good comments daknight2000 :)"

I didn't see any comment from "daknight2000"!

Working with AppWizard is very helpful, in that the wizard will start you off with a fully functional (allbeit not too very useful) program.  Carrying on from where AppWizard left off, becomes your responsibility (meaning, depending on what type program you wanted the wizard to create for you e.g. an SDI, an MDI, using database, etc.), you must know beforehand what is it you want to achieve in your program.  At this point, your knowledge of MFC (and C++) must be sufficient to help you along in your journey.

However, if you notice, all Windows applications have a certain 'look' and 'feel' that is consistent with all of them.  It wouldn't matter if I wrote the program, or Laminamia, or someone else; they pretty much look and feel the same.  AAMOF, if you were to be using a Windows program, you wouldn't know who wrote it, ... because of that consistency.

That consistency is achieved through something called, "Window Classes", which has NOTHING to do with the kind of classes used in C++; they are totally different.  Instead, Window Classes define certain attributes and charcteristics of each window in a Windows application (e.g. Style, Window Process, Icon, Cursor, etc.).

In a traditional-style program, a Window Class must be defined and registered before a window can be created.  When you register a Window Class, you are telling Windows about the form and function of the window.  However, just registering a Window Class does not cause a window to come into existence.

Each window is represented by a Window Object in memory that tells the Windows operating system where to draw the window and what routine to call in response to a mouse click, a keystroke (assuming the window has input focus), a timer expiration, etc.  A Window Object is created with the CreateWindow() function passing the Window Class as one of its parameter.  (This is the shortcut explanation, because MFC actually does some additional work behind the scene for you.)

In a Windows program, there are a lot of activities occurring behind the scene for you, and until you start studying more about how Windows (the Operating System) function, you will not know how to reap the many benefits of it.
0
 

Author Comment

by:daknight2000
ID: 1201679
Well as per my littel knowledge.. the case you explained to me happens when someone write a simple C style programme. I guess I did not explain my question very well. Here is it again.
Suppose I make a windows application using appwizard and later i modify it to print "Hello World" on screen.
Following is the list of my kiddi questions:-
1:- why i cant see WinMain() in Class view.
2:- some books explain that .. WinMain() is hidden .. and on the execution  if looks the object of CWinapp class and with this object it calls InitInstance() .. and so on. If its so then who is going to take care of message loop?  I am really confused at this point.
3:- Say for example i write a programme in C++ under DOS, and if I add a new class to this programme .. then most of the times I would need to decalre an instance of this class in main() and then to call the respective functions. Why I cant see the samething in Visual c++ ( programming for windows using MFC).
0
 
LVL 3

Expert Comment

by:PinTail
ID: 1201680
AppWizard places a single CWinApp derived object - called 'theApp' in the implementation file for the CWinApp derived class.

Because this object is global ( and let's not get into what that means here ), it is created when the application loads.

Then, as illustruted by this stack trace, that object is retrieved by the 'hidden' WinMain, It's InitApplication member is called, then it's InitInstance member is called.

CThreadSlotData::GetValue(int 1)
CProcessLocalObject::GetData(CNoTrackObject * (void)* 0x5f801580 CProcessLocal<_AFX_BASE_MODULE_STATE>::CreateObject(void)) CProcessLocal<_AFX_BASE_MODULE_STATE>::GetData()
AfxGetAppModuleState()
AfxGetModuleState()
AfxGetApp()
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00140e6b, int 1)
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00140e6b, int 1)
WinMainCRTStartup()
KERNEL32! 77f1b304()

What you don't see is a lot of stuff that has been done by the compiler, and linker when you build your application.  

If you have ever wondered what all the preprocessor directives are for, as well as they bizaar linker switches; some of them have to do with the placing of the CWinApp derived object in the right place in the object file, and initialization of information in the Exe header so that WinMain can find the 'entry point'.

You can write your own WinMain if you wish.  

I would suggest that the only way really to understand the Window OS and Windows programming, is to wirte your own WinMain.
0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201681
I meant, good comments, try, sorry :)
0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201682
Please don't reject an answer if you need more clarification.  I answered your question about what goes on.  The compiler does it behind the scenes in the case of MFC programming, but it is the same as using API calls, because MFC is based on the API calls.  Write a Windows program using WIN32 API and you'll understand what happens behind the scenes using MFC.  That's the best way to learn what happens.  

Laminamia
0
 

Author Comment

by:daknight2000
ID: 1201683
thanx alot ..
laminamia i m sorry for rejection ... i really never ment the "rejection"  .. it was by mistake.
i should be careful in future

0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201684
No problem . . . What else do you want to know about the WinMain, etc, or how program flow looks?  Would you like me to answer your question more, or has the explanation so far been sufficient?

Laminamia :)
0
 
LVL 3

Expert Comment

by:Try
ID: 1201685
I think we can all take our cue that no answer will ever be sufficiently clear for this person to understand.  Learning about 'program flow' takes more than a question followed by an answer.  It takes reading, practicing, learning on one's own and a sustained dedication to expand one's knowledge and expertise through hard work.  To know about the 'program flow' of a Windows program, means the person will have to know about what's happening behind the scene, and THAT is not easily explained for a newbie to easily understand.

Laminamia, I believe you have done well at trying to explain this person's question, and if he/she couldn't even prevent a "mistake" from happening (how much does it take to know which radio button to select) that resulted in the rejection of your answer, there is no reason to believe any kind of answer will ever get through to him/her.  He/she needs to do their own research.

Laminamia, you did well!  Know when to fold.
0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201686
:)
0
 
LVL 1

Expert Comment

by:kirthir
ID: 1201687
CCmdTarget is the main class which implements message-map architecture. CWinApp is the derived class of CCmdTarget, so
by virtue of inheritance it got the message-handling capabilities from CCmdTarget.


0
 
LVL 4

Expert Comment

by:yowkee
ID: 1201688
Well.... Try and Laminamia both did a good work!:) daknight2000, If you still not very clear, I'd recommend you to buy a good book for reference. "Programming Windows with MFC" be Jeff should be a good choice. Or you could find Jeff's earlier MSJ articles (1996) in MSDN CD.
0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201689
Thanks yowkee :)
0
 
LVL 3

Expert Comment

by:Try
ID: 1201690
Laminamia, in some respect you must be thankful that "daknight2000" rejected your answer.  I say this from experience because many times when you try to help someone, rather than the person inquire further (until he/she gets a clearer understanding of the subject), they'd accept the answer but then turn around and give you a "D" rating.  It DOESN'T MAKE SENSE.

If they're not satisfied with the answer, just ask for more clarification!  They don't.  They accept it, but then reward your effort with a "D" rating.

It's a risk you take when you answer some of these type questions, because in genuine kindness towards helping others, the person asking the question (instead of being thankful and appreciative of the help) turns around and seek to punish the individual responding to their request.  (Who needs to get punished for helping someone!)

I'm NOT saying "daknight2000" sought to punish you.  I'm saying he/she was hardly in a position to reject your answer when what you were doing, was trying to educate him/her in as clear a manner about the many activities that go on behind the scene from the time a program gets activated to the time a window is displayed with data on it.

Comments I give more freely (sometimes), but when it comes to ANSWERING, I am definitely more selective about whom I choose to answer.  I usually check their profile to see if this is someone who'd appreciate the research and work that might be required in answering their question (plus the amount of points being offered usually tells me how valuable the answer is to them).
0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201691
:)
0
 
LVL 11

Expert Comment

by:alexo
ID: 1201692
This thread is a perfect example of why working with automatic code generators ("wizards"), frameworks (MFC), etc. without having a good grasp of the underlying technology (Win32) is detrimental.

VC attempts to shield the programmer from the complexities of Win32.  This allows novices to create simple GUI applications rather quickly and gives them a false sense of security.  However, a day will come when you'll have to do something outside the "helpful" environment (and sometimes even against it).  What then?

Remeber what H. R. R. Tolkien said about Visual C++: "Do not meddle in the affairs of wizards, for they are subtle and quick to anger."

Try, bad day?
0
 
LVL 3

Expert Comment

by:Try
ID: 1201693
Alexo, you're like a wizard yourself.  You show when and where least expected!!  Fortunate for the rest of us, you're a good wizard who is slow to anger!
0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201694
Cheers alexo :)
0
 

Author Comment

by:daknight2000
ID: 1201695
i appologized for my mistake ... but Mr./Ms Try still in a mood of cussing, it should be pertinent to note that Laminamia also accepted my appologize. All this seems that I am being victimized by Try.
:(
0
 
LVL 11

Expert Comment

by:alexo
ID: 1201696
Many experts consider a "D" as an insult.  Note that, unlike a rejection, a graded question goes on the experts record (last 10 grades received) for everybody to see.  For experts with low turnaround this is very unpleasant.

Since Try is not currently very active on EE (14 answers), his run of "D"s could grace his record for some time.  Now when one checks his info, the reason for the "D"s is not shown.  It could be honest mistakes, vindictive customers or, as a naive looker may assume, an indication of a bad expert.  I got my share of "D"s and my ego didn't like it any...

Please remember that experts are non-payed volunteers *and* human beings with real feelings.

Now the real question is: are you ssatisfied with the answers you got?  If so, the proper etiquette for thanking Try and/or Laminamia for their efforts is a good grade.

Try, 6 more "A"s for a perfect score.  Concentrate on that instead ;-)
0
 

Author Comment

by:daknight2000
ID: 1201697
I wanted to ask more ... but the cussing attitude stoped me
As i mentioned earlier that I appologized Laminamia  and he/she also accepted my appologize, but still Try is not in mood to spare me then :((
0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201698
Don't worry daknight2000...did you learn what you needed to?  If not, what more do you wish to know?  Most experts will be more than happy to answer your questions (Heaven knows they've answered mine =)

Laminamia


0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201699
And do you think that you've received the answer you needed, and if so, who do you think should be rewarded the points (just to rephrase alexo's thoughts)...

Laminamia :)
0
 
LVL 3

Expert Comment

by:Try
ID: 1201700
"daknight2000" if you need to ask more questions in order to understand what it is you need to know, by all means, GO AHEAD and ask them.  That's why experts responded to your initial question.

But because it's an interactive process, you also play a role in the exchange, which means you keep asking more questions from any of the experts who have submitted an answer or comment(s), and you keep doing this until you either have a solution to your technical problem or you're satisfied with an answer.  Then, depending on how helpful and encouraging the expert who helped you might have been, you ask for a final answer from him/her (if one wasn't already submitted) and issue a grade as an expression of appreciation.  AAMOF, if you feel the expert may have been exceptionally helpful, you may even feel that the points you originally offered, should be increased for that particular expert.  There are several things the person asking the question can do, the most important being to ask follow-up questions.

Most experts are genuinely motivated to simply helping others, and they do so by submitting comments.  In that regard, you may see several experts offering added information to a question simply to enhance the solution, or clarify a portion of it.  It is then for the person asking the question to decide at the end which expert may have contributed significantly to the question and then ask that person to submit a final answer, followed by the awarding of the points (etc.).

You do not reject an answer without stating why you believe the answer does not offer help or solution to your technical problem.  To reject an answer without asking follow-up questions for the expert to clarify, is regarded as impolite and one sure way to draw fire from others who believe that for trying to help someone such impoliteness doesn't deserve further assistance.  As Alexo mentioned earlier, we do not get paid for helping someone; we just do it!

Feel free to ask further questions, and know that it's an interactive process.

Because Laminamia was the first expert to have answered your question, she is the one most deserving of all recognitions.
0
 
LVL 3

Expert Comment

by:Try
ID: 1201701
If you want to write Windows applications, I would not worry too much about 'program flow'.  It hardly matters; at least not until you start getting into the nitty-gritty of things, and even then, if you're going to work with MFC, it shields you from a lot of the drudgeries of detailed work.

'Program flow' is more of a throwback of times past when programs used to be written in sequential logic.  Then it was critical and essential to know about 'program flow' in order to determine where corrections and updates had to placed.  Windows has done away with all that!!  To prove it, Windows allow the user to go ANYWHERE in the program and do WHATEVER he/she wishes to do at that point.  ("WHATEVER" means 'whatever the program is supposed to do at that place.')

Windows succeeds in doing this because it receives and processes messages RANDOMLY, and anything that is random doesn't have a "flow".

Even if you're working with a simple application as one that's going to print "Hello World", the thought of 'program flow' doesn't come into essence, because AppWizard takes car of the necessary requirements in order for you to produce such a simple program.  The same would be true if it was a more complicated program.  Having said that, what AppWizard does is very limited to what you want to ultimately achieve, but it gets you started and going.  At that point, your journey has already begun.  To continue along that journey is when you start thinking about messages.  That's where AppWizard stops and you begin.  It shouldn't matter to you HOW you got there.  All you know is that you're there now, and the Message Loop is where you know your hundreds and thousands of messages are going to be obtained, translated and directed to the proper place in your program for it to be processed.  Windows does that for you automatically, so it hardly matters what the flow of activities are.  Windows takes away that burden from you.

However, if you're someone who wants to get down into the belly of the beast, then that's where your interest is not so much about writing programs, but about understanding the guts of Windows for purposes of fine-tuning, upgrading, and maintaining it.  But even then, there's no 'program flow' because Windows does NOT operate that way.

Nevertheless, it does help to round off your knowledge by knowing some things about the operating system called, Windows, and that is when you start reading up on the structure of the Microsoft Foundation Class Library to know what CObject is, the roles of CCmdTarget and CWinThread, and why you ended up at CWinApp.  Doing this will provide you with knowing what functions in those classes are responsible for creating your application object, initializing it, running it and eventually terminating it.  In the process you'll also understand what all it takes to get a window displayed on the screen along with the procedures necessary for you to write (aka painting) to it.

Many (if not all) of these activities take place behind the scene and are done initially by AppWizard for you, and later, MFC continues to do about 90% of the work for you.  Your 10% is the tough part because that's where you must know how to get MFC to work for you, NOT against you.

Hope this better explains things.  As usual, ask questions if you need to know more.
0
 
LVL 3

Expert Comment

by:Try
ID: 1201702
If you want two very good books to read, consult "Programming Windows: 5th Edition" by Charles Petzold (Microsoft Press).  Chapter 3 deals with Windows and Messages and will set you on the right track.

The next book is, "Visual C++ MFC Programming by Example" by John Swanke (RD Books).  Chapter 3 explains very clearly about Messaging.  This book is written with a lot of diagrams and is very user friendly.

I consult both very frequently and wished I had them when I was just starting out.  (Life would have been so much kinder and gentler to me then.)
0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201703
Good books... I agree (I've read Petzold, and, though his style is criticized by some, his teaching of windows programming basics is awesome).

Laminamia
0
 

Expert Comment

by:mmachie
ID: 1201704
you could run your program in the debugger and step through all the gory details.  then you could see exactly what's going on.
0
 
LVL 3

Expert Comment

by:Try
ID: 1201705
What "mmachie" suggested, is an open-ended exercise, because if you were to have ten programs you'd have ten different examples of gory details; fifty programs, ... fifty different examples of gory details; 100 programs, (etc.).

Debugging is largely an exercise of turning inside-out the workings of a program in order to uncover what's going on inside THAT particular program.  Debugging answers the need to know about how a program is doing its work, and therefore, ten different programs will give you ten different answers.

With regards to how Windows handles a program, is NOT debugging, because I have written many Windows programs which are still being run by Windows, but are not being debugged.  The processes are not one and the same.

To understand how Windows runs a program, you'd need to have some knowledge on the architecture of Windows, the Win32 API's and MFC Internals.

The two books I've suggested earlier, are a very good start(partcularly the one by John Swanke, because he does such a very good job of explaining matters in such easy terms).

Two more good ones on MFC (one for beginner and the other after you've graduated) are:   "Beginning MFC Programming" by Ivor Horton (Wrox Press), and "Programming Windows with MFC: 2nd Edition" by Jeff Prosise (Microsoft Press).

The bottom line:   You have to do a lot of reading, a lot of practicing, a lot of experimenting, and along the way, ... a lot of asking questions.

If you believe you have gotten some good information and your question answered, how about asking Laminamia to submit a final answer and award her the points (considering it was a mistake you said you made when you earlier rejected her answer).
0
 
LVL 11

Expert Comment

by:alexo
ID: 1201706
>> [...] and award her the points.
Internet rule #1: Do not assume *anything* about the person on the other end of the bit stream.
0
 
LVL 3

Expert Comment

by:Laminamia063099
ID: 1201707
I'm here for whatever daknight2000 thinks.... Tell me if you want me to submit more information or a final answer...

and thanks alexo :)


0
 
LVL 3

Expert Comment

by:Try
ID: 1201708
There comes a time when the bluffing is over, and you have to call the other person's hand.
0
 
LVL 3

Accepted Solution

by:
Laminamia063099 earned 300 total points
ID: 1201709
The program starts in the equivalent of the WinMain function.  This is where your Window is created and displayed.  Then, the program enters what is called the message loop.  This is where the program waits and receives messages from windows.  The messages received by the message loop are handled (work is done with them) in the MainWindowProc, which you write.  These messages are WM_CREATE, WM_PAINT, and other messages to create the window.  On either of these messages, you can place the text display functions (of your choice) to say "Hello World".  When you close the window, using F4 or X, the window receives a WM_CLOSE and WM_DESTROY messages, in sequence, closing and cleaning up the window, and exiting the Message Loop in WinMain.    

Everything you write in your program has to be called by a message in the message handling part of your WindowProcedure, called as a callback procedure, like subclassed windows, or called through one of the above.  There is no program flow that is set in stone, nor can you try to do so.  That would not be a windows program.  You must write a sound program where the different members can interact and be called/messaged by windows when needed.

Laminamia :)
0
 

Author Comment

by:daknight2000
ID: 1201710
ummm.. I guess I was not able to my question, I got my answer from www.iftech.com...
what i have got from there is like this
every mfc programme started from winmain()
in winmain looks for global object of a class derived from CWinApp
and with this object it call InitInstance()
in InitInstance()  it reintailizes the m_pMainWnd and invoke ShowWindow() and UpdateWindow() with it.
here the window is created
afer gettin out of InitInstance successfully it hooks in to message loop waiting for messages at the
nReturnCode = pThread->Run();
Please clarify me if I am worng
thanks alot all.. specailly laminamia and try
0
 
LVL 3

Expert Comment

by:Try
ID: 1201711
What we needed from you was feedback.  Now that you have provided us with something, I shall fill out the process in more detail.  There are much that are missing!

However, right now I'm a little under pressure with my time, but will get back to you later today (even if its tonight).
0
 

Author Comment

by:daknight2000
ID: 1201712
thanx alot
but i wanted to read some material before needing explanations....
I am waiting ..
:-)
0
 
LVL 3

Expert Comment

by:Try
ID: 1201713
While every MFC program does start from WinMain(),  technically, every MFC program starts from a '_tWinMain()' function that calls and returns the result of an AFX function called, 'AfxWinMain()'.  Both the '_tWinMain' and 'AfxWinMain' functions are located and tucked away in different modules that are embedded and later '#include'd in your application by AppWizard, but both have the same set of parameters listed in the same order that yet another function, 'AfxWinInit()' has.  All these activities (and more) get executed as part of the 'WinMain()' package before you can see any result on your computer screen.

Inside the AfxWinMain function, the first thing it does is to declare a pointer of type CWinApp and assign the value of AfxGetApp() to it ('AfxGetApp' gets the address of the one and only application object associated with your program).  (Be mindful that your application object gets created first in keeping with the rules of C++ regarding global objects, which is why AfxGetApp() is able to obtain it before 'tWinMain' even starts working.)

Following some interim verification of pointers inside AfxWinMain, the returned Boolean result of InitInstance() is tested.  (There's more nitty-gritty stuff here that I'll pass over, such as 'AfxWinMain' calling 'AfxWinInit' which in return calls 'AfxGetModuleState', etc.)  Just know that 'InitInstance' of your program eventually gets called (if one were included).

Because 'InitInstance' is an overrideable function of CWinThread, your application will use it to do essential initializations of objects (including document template and frame window objects).  If your program does not override 'InitInstance' of CWinApp to do its own initializations, your program will end right here; it will go no further and ExitInstance() will be called.  This will have occurred because the Boolean result from 'InitInstance' will have returned FALSE if no initialization took place, and TRUE if there were.

While still inside 'AfxWinMain', if the Boolean result of 'InitInstance' tests TRUE, the next activity that takes place is a call to Run().

Before I explain Run(), let me back up a bit to 'InitInstance'.  AppWizard automatically overrides 'InitInstance' for you as you were selecting the various features (default or otherwise) while going through its various steps in the creation of your program.  Inside 'InitInstance' are functions that are called to create your document template, frame window, and controls objects (in addition to reading and parsing command line options and scripts).  One such function is ProcessShellCommand(), which is directly responsible for creating your program's main frame window along with the controls (such as toolbars and statusbars).  The creation of controls are done through two functions that were inherited by your program's CMainFrame class (put there, courtesy of AppWizard) from CWnd and CFrameWnd.  They are Create() and PreCreateWindow().  In your program, Windows inserted a WM_CREATE message that got routed to both your CMainFrame handlers 'OnCreate' and 'PreCreateWindow'.  When these functions are finished doing their work, then and only then is control returned to 'ProcessShellCommand' of your program's 'InitInstance' routine, followed by the displaying and updating of your main frame window with these controls.  At this point, "Hello World" is still not seen.  That will happen as a result of the 'Run' function.

Before you can see anything displayed, Windows has to register certain classes (at least one).  These are NOT C++ classes.  MFC communicates to Windows, information pertaining to these Window Classes which define certain attributes and charcteristics of each window in a Windows application (they are, Style, Window Process, Icon, Cursor, etc.) before the message loop gets activated.

The Windows Message Loop is an enormously complicated subject if one were to study it in its full depth and scope since it incorporates other factors, Processes and Threads (both worker and interface kinds along with their respective states).  It is really complicated.  However, the simple explanation of it I have outlined below.

Suffice it to say that the message pump (or the 'message loop' as some choose to call it) is made up of three functional parts:

1)  The obtaining of messages through the GetMessage() function
2)  The translation of messages through the TranslateMessage() function, and
3)  The routing of messages through the DispatchMessage() function.

There are three kinds of messages Windows pass through the message pump, Window Messages, Command Messages, and Control Notification Messages.

Window Messages are generally concerned with the inner workings of a window, such as creating it, drawing it and destroying it.  They are usually sent from the system to a window or from window to window and starts off with the letters "WM" followed by an underscore and a desriptive command as in WM_PAINT, WM_CREATE, WM_MOUSEMOVE, etc.  All the other types of message also starts off the same way with the same letters.  It is their 'wParam' and 'lParam' data that differentiates which one is which.  (This means these two fields must be utmostly studied and treated with great care and notice.)

Command Messages are generally concerned with processing a user request.  They're generated when the user clicks on a menu item or a toolbar which are then sent to the class object that can handle that particular request (e.g. load files, edit text, save options, etc.).  They are identified by their usage of the word, "WM_COMMAND" preceding the rest of the information.

Control Notification Messages are generally sent by Control windows to their parent when something significant happens, such as when a combo box is about to be opened.  These types of messages give Parent windows the opportunity to further control their windows when necessary (e.g. the Parent can put information in a combo box when it is opened, that weren't there when the combo box was first created).  Control Notification messages are further subdivided into three types with all using the "WM" letters.  The first format has messages as, WM_PARENTNOTIFY, WM_CTLCOLOR, WM_HSCROLL, etc.  The second format has message using "WM_COMMAND", and the third format has messages using "WM_NOTIFY".  It is their 'wParam' and 'lParam' values that differentiates which format is being used.

The message pump in an MFC application is in the Run() member function of CWinApp.  Run() is called when your application completes its creation and initialization of the various matters I outlined earlier.  It then divides its time between performing background processing (such as getting rid of temporary CWnd objects) and checking the message queue.

When a new message comes in, Run() uses GetMessage to fetch it from the queue, then runs two translation functions on the message ('PreTranslateMessage' and the 'TranslateMessage' API) before calling the DispatchMessage function.  Any message not processed by the message pump (meaning, gets returned to it) are sent on to a default function which passes such a message back to Windows for Windows to resolve.

The way the message pump knows where to deliver a message depends on three things:

1)   The class that will be handling the message must have been derived from CWnd (or CCmdTarget for Command Messages).
2)   You must write (or have) a member function in that class that will handle the message.
3)   Define a lookup table (aka a Message Map) in the class with an entry for the member function, and an identifier of the message it is to handle.

These conditions having been satisfied, MFC then directs an incoming message to your handler by calling the following functions in the following order.

1)   AfxWndProc() receives the message, finds the CWnd object to which the message belongs, and then calls AfxCallWndProc()

2)   AfxCallWndProc() saves the messages (i.e. message identifier and parameters) for future references and then calls WindowProc().

3)   WindowProc() sends messages on to OnWndMsg() and then if unprocessed, to DefWindowProc() which then turns it back over to Windows for it, Windows, to take care of.

4)   OnWndMsg() calls either OnCommand() for WM_COMMAND messages or OnNotify() for WM_NOTIFY messages.  Everything left over, is considered a Windows message.  It is at this point that OnWndMsg() searches your class's Message Map for a handler that will process any Windows message.  If OnWndMsg() cannot find a handler, it returns the message to WindowProc() which sends the message on to DefWindowProc() etc.

5)   OnCommand() checks to see if this is a Control Notification (i.e. the 'lParam' is not NULL); if it is, OnCommand() tries to reflect the message to the control making the notification.  If it isn't a Control Notification (or the control rejected the reflected message) OnCommand() calls OnCmdMsg().

6)   OnNotify() also tries to reflect the message to the control making the notification; if unsuccessful, OnNotify() calls the same OnCmdMsg() function.

7)   OnCmdMsg(), depending on what class had received the message, will potentially route Command Messages and Control Notifications in a process known as "Command Routing".  (To explain briefly this process, for example, if the class that owns the window is a Frame Class, Command and Notification Messages are then also routed to the View and Document classes looking for a Message Handler for the class to see if one is present that will process the message.)



Notice what a question, simple in appearance, can generate in the way of explanation.  This is just an example of what all are involved when programming a Windows application using MFC.
0
 

Author Comment

by:daknight2000
ID: 1201714
thanks alot ... its a good explanation to my point
0
 
LVL 3

Expert Comment

by:Try
ID: 1201715
If you believe you have had your question satisfactorily answered, the proper response would be for you to accept an answer (or if none were submitted, to request one be submitted), which in this case, Laminamia has already submitted one.

As far as I'm concerned, since she was instrumental in the answering of your question, she should receive the credit.
0
 

Author Comment

by:daknight2000
ID: 1201716
ok .
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article shows you how to optimize memory allocations in C++ using placement new. Applicable especially to usecases dealing with creation of large number of objects. A brief on problem: Lets take example problem for simplicity: - I have a G…
Container Orchestration platforms empower organizations to scale their apps at an exceptional rate. This is the reason numerous innovation-driven companies are moving apps to an appropriated datacenter wide platform that empowers them to scale at a …
The viewer will be introduced to the technique of using vectors in C++. The video will cover how to define a vector, store values in the vector and retrieve data from the values stored in the vector.
The viewer will be introduced to the member functions push_back and pop_back of the vector class. The video will teach the difference between the two as well as how to use each one along with its functionality.
Suggested Courses

670 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question