|
In VS install directory, there're some files(.cpp, .h) seems to be source code of MFC. So can I put them back into VC and compile them?
|
|
|
|
|
Yes but if you make any changes you will need to distribute your new DLL(s) along with your app
|
|
|
|
|
You can. But you really shouldn't do it unless you have a very good reason to do so. And I can't think of a good reason to.
If you want to change the behavior of some class, just subclass it and handle it in that good old C++ way...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</A>
|
|
|
|
|
Oh...I'd like to have a try. Just to know MFC libray better.
So are there any instructions about compiling MFC source code on the internet?
|
|
|
|
|
I'm not sure how building the library yourself will help you "know MFC libray better", but...
Take a look in the atl/mfc src directory.
For example, in VS 2005, there's a readme.txt that states:
Building ATL and MFC
To build either ATL or MFC open a command prompt and run vcvars32.bat from <path to vc8>\bin
Change directory to <path to vc8>\atlmfc\src
atlmfc.mak can be used to rebuild all ATL and MFC libraries and DLLs.
Following is the command line you can specify with NMAKE
nmake /f atlmfc.mak [ALL | ATL | MFC] [CLEAN= ] [LIBNAME= ] [PLATFORM= ]
Targets
ALL - builds both ATL and MFC. This is the default target. LIBNAME has to be
specified.
ATL - builds only ATL.
MFC - builds only MFC. LIBNAME has to be specified.
CLEAN=1 cleans the files generated by the specified targets
LIBNAME="name of the MFCdll being built" - specifying MFC80 builds the prebuilt DLLs
PLATFORM=[AMD64|IA64] if building for 64-bit on a 32-bit system
Mark Salsbery
Microsoft MVP - Visual C++
"Great job team! Head back to base for debriefing and cocktails."
|
|
|
|
|
Very long time ago, I just wondered why doesn't MFC add all Windows message handlers to CWnd and make them all virtual, so that derived classed don't need to add message handlers but only to override virtual functions.
MFC claims that it uses message maps rather than virtual functions just in order to tune the performance, now it's time to tell the real difference. 
|
|
|
|
|
Cool. Let us know the results!
From Technical Note TN006:
"Microsoft Windows implements what are essentially virtual functions in window classes using its
messaging facility. Due to the large number of messages involved, providing a separate virtual
function for each Windows message results in a prohibitively large vtable.
Also, since the number of system-defined Windows messages changes over time, and since a specific
application may want to define some Windows messages of its own, the message-map mechanism
provides a level of indirection that prevents interface changes from breaking existing code."
Mark Salsbery
Microsoft MVP - Visual C++
"Great job team! Head back to base for debriefing and cocktails."
|
|
|
|
|
Hi All,
How Can we make a Modeless Dialog Box to Act as Modal Dialog Box??
Thanks
Today is a gift, that's why it is called the present.
|
|
|
|
|
The two kinds of dialogs are created differently. If you're using MFC or ATL, call DoModal(). In the APIs, call DialogBox() instead of CreateDialog()
|
|
|
|
|
I know that but what I want is , how can we make a Modeless Dialog box Once Created to act as Modal dialog box? If I have a dialog and on a button click I am creating a modeless dialog box using create(). Is there a way in which I can make my modeless dialog box to act as modal dialog box?
Thanks
Today is a gift, that's why it is called the present.
|
|
|
|
|
Why are u creating it modalless to make it modal? Just create it in modal way.
CDialogBox* MyDialog;
MyDialog->DoModal ();
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
narayanagvs wrote: Is there a way in which I can make my modeless dialog box to act as modal dialog box?
Actually, no. Unless you 'recreate' (destroy previous and DoModal a new one) your dialog, you cannot turn a modeless into a modal one.
--
=====
Arman
|
|
|
|
|
You can probably do something when your dialog looses the focus. If the focus is going to a window other than your dialog or its children then put the focus back to your dialog but I dont know how well it would work or how it would effect other apps running on the system. Ie its a hack
|
|
|
|
|
You could disable the dialog's parent window, then be sure to re-enable it when your dialog closes. But yeah, this is a hacky idea. Raymond Chen[^] has written some posts about doing manual modality like that, check out his blog.
|
|
|
|
|
Michael Dunn wrote: Raymond Chen[^] has written some posts
"This is like asking for a cheeseburger and then trying to peel every last bit of cheese off the patty to turn it into a plain hamburger."
Mark Salsbery
Microsoft MVP - Visual C++
"Great job team! Head back to base for debriefing and cocktails."
|
|
|
|
|
You can disable the parent window.
« Superman »
|
|
|
|
|
narayanagvs wrote: How Can we make a Modeless Dialog Box to Act as Modal Dialog Box??
Is this with MFC? If so, that's already happening.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
hi,
Suppose there is a program named b.exe, how to program in vc to intercept a message from b.exe?
Thanks in advance,
Cui Sheng
|
|
|
|
|
I assume by message you mean a window message (WM_?????). Have a look at the SetWindowsHookEx API.
Steve
|
|
|
|
|
|
Hello,
Well, I have created a custom MFC control that derives from CWnd. I have done some work to add double buffering, but now i have a problem. My application sucks up 100% of the CPU.
I have it narrowed down to one line.
void CGameArea::OnPaint()<br />
{<br />
mPlayer->Draw();<br />
<br />
CRect r;<br />
GetClientRect(&r);<br />
<br />
CDC *dc = GetDC();<br />
dc->BitBlt(r.left,r.top,r.right-r.left,r.bottom-r.top,&mBackgroundDC,0,0,SRCCOPY);<br />
ReleaseDC(dc);<br />
}
I am currently not calling the base CWnd OnPaint function because I am doing all the painting myself. Somehow, this is causing the problem.
If I uncomment the base class OnPaint call, my CPU usage goes back to normal, but I get a lot of flicker.
Any idea why NOT calling the CWnd OnPaint would cause 100% CPU usage??
Thanks ahead of time for any help.
-Kevin
-- modified at 8:53 Wednesday 18th July, 2007
|
|
|
|
|
If you don't validate the invalid region of the window then you will continue to receive WM_PAINT
messages until you do so  Not good!
This should do it:
::ValidateRect(*this, NULL);
or use a CPaintDC instead of a CDC
//CDC *dc = GetDC();
CPaintDC dc(this);
...
Mark
Mark Salsbery
Microsoft MVP - Visual C++
"Great job team! Head back to base for debriefing and cocktails."
|
|
|
|
|
Holy crap, you're the man. You know, I almost tried switching to CPaintDC, but kept telling myself it wouldn't matter.
It all works now. Thanks.
|
|
|
|
|
kalden wrote: mPlayer->Draw();
In addition to what Mark said, I also doubt how you took the DC in the mPlayer->Draw() function;( I am not sure what exactly that draw function does). I suggest you to pass the CPaintDC object to that function and do all the drawing in that DC.
|
|
|
|
|
I am passing a memory DC to a game DLL at initialization. That DLL has the mPlayer->Draw() code and uses GDI+ to draw to the memory DC. The memory DC is then copied to the control DC using Bitblt.
I know there are potential problems with this if the window resizes, but I am not worrying about that at the moment.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
