Skip to main content
gamedev.net
🔒 Locked

MFC

Started by Guardian_Light 2 replies 700+ views
Original Post
Guardian_Light
Guardian_Light
It seems like all I *ever* post about is MFC... I just recently seperated my CWinApp and CFrameWnd classes into there respective files. Unfourtantly I got four linker errors claiming my message map was already declared in the CWinApp file when it started trying to link the CFrameWnd file. I generated a standard MFC app through app wizard and examined the code output. There message map wasn't defined in the header, but in the source file. I switched my my message map at the end of my source file and volia! No problem. I know enough about MFC to know that things needed to be defined in order, but I'm still scratching my head over this one. Anyone have an idea my this would be? I always used to define my message maps in the header file and it only stopped working when I split up the frame and app classes. Anyways, I should stop rambling. Maybe this is a question for the Microsoft MFC news groups... "So little time, so much fun." ~Michael Sikora Edited by - guardian_light on October 6, 2001 1:37:49 PM
felisandria
felisandria
Hmm.

The Message Map is just a script to do the WndProc for whatever window it''s declared for. Actual position of the message map shouldn''t really make any difference unless it was having problems determining the script origin.

To make sure the script functions properly, just be sure that it''s delimited by
BEGIN_MESSAGE_MAP(Classname, BaseClass)
END_MESSAGE_MAP()

Note that often problems are caused when separating classes out because people don''t script the correct class name or base class type. Always make sure that you put the correct class name and base class in the BEGIN_MESSAGE_MAP parameters or you might have problems like you described, and make sure they''re present. Otherwise it might catch it if it can extrapolate the classes when it gets confused, but remember that things are compiled in a certain order and file delimiters are often ignored by the MSVC compiler, so if you didn''t have the right classes in the script it probably got lost if your script was up top.

-fel
~ The opinions stated by this individual are the opinions of this individual and not the opinions of her company, any organization she might be part of, her parrot, or anyone else. ~
Guardian_Light
Guardian_Light
Actually, I agree. The position shouldn''t matter in the slightest.

I tried changing the MS generated source and suprise! When the messsage map is moved to the header file, the same linker errors arise. So if I''m doing it wrong, so are MS''s developers =)

I wonder if it''s compiler specific? Does anyone have a compiler other then MS Visual C++? Want to try it?

~Michael Sikora
felisandria
felisandria
Umm... the message map as an entity is itself compiler-specific. MFC is compiler-specific. Borland uses OWL or some other such construct.

Message maps should show up both in the .h and .cpp. The .h really isn''t that special, it''s just a define of the necessary message map functions (if you pull out all the commented stuff that the compiler doesn''t bother looking at) and the DECLARE_MESSAGE_MAP() macro which to be honest doesn''t do anything at all other than say "Hey guys, we''re using a message map in this class so look for the script k?". Without the declare, obviously, it doesn''t think you even have a message map, so it doesn''t bother pulling it out of your script and your command handlers won''t fire.

The .cpp part is the actual scripting part, which declares the class to script it for, the derivative so it knows what basics to look for, and the stuff to look for and respond to as well as the functions that you have set up to handle the response for message and command type handlers.

-fel
~ The opinions stated by this individual are the opinions of this individual and not the opinions of her company, any organization she might be part of, her parrot, or anyone else. ~

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.