|
Same here.
I just occasionally come up with trace sequences that kinda get out of hand and in some unique circumstances, it would help to have the debug window "reset" to help my eyes track the start of the sequence better/faster.
Right now I put a trace in with a hiddeous, jumps out at you, string to help me find the start of the last iteration of trace sequences.
Thought I'd check with the rest of you to see if someone had ever come across something like that before.
Thanks for the input.
|
|
|
|
|
Heh I tried a formfeed - no love there.
I haven't dug into the internals of how these messages get routed to a debug window,
but I always assumed the messages are just written and it's up to the receiver to deal
with them.
Therefore, even if there was an extension to the IDE that did this, I'm not sure how it
could be used programmatically at runtime.
I'm interested in seeing a solution though.
Good luck,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
No luck here either.
However, Hans Dietrich brought up "SysInternals DebugView" in another post in the thread. It doesn't do the clear screen thingy but it has a highlighting feature that is pretty cool. I had been meaning to dig through all those Sysinternal utilities someday. So far, the regmon (I think that's what it's called) has been the only one I've found I can't live without.
Thanks for the help.
|
|
|
|
|
You should give DebugView a try. You can set filters on lines with specific words - like 'ERROR' or 'WARN' - and DebugView will colorize those lines according to the colors you set.
|
|
|
|
|
That's sweet.
It's picking up traces from any debug exe run on the machine with Visual Studio running.
I downloaded the whole sysinternals collection right after MS bought them in case they were going to remove them from circulation but I never noticed that one before.
thanks for the heads up.
|
|
|
|
|
You can use the "exclude filter" option to exclude any unwanted lines. Sometimes, when you are reading lines in DebugView, the cursor will suddenly junp to bottom, because some other app has written debug output. I just add exclude filter to stop cursor from jumping around.
I also have a number of "5 character" filters defined - for example, '~~~~~', '-----', '=====', etc. - each with a different background color. I add 5-character sequence to end of TRACE string, for lines I want to watch for. It makes it very easy to see that line in TRACE output.
I once tried to add '*****' as filter, but everything turned that color! DebugView uses it as wildcard character. LOL!
|
|
|
|
|
Thanks for the advice and guidance.
|
|
|
|
|
Thanks Hans!!
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I am writing an event handler for the menu bar. In response to the WM_COMMAND message, my WndProc is supposed to send wParam to the function like this:
...<br />
case WM_COMMAND:<br />
guiObject->OnMenuSelection((UINT) wParam);<br />
...
Here is the code for the menu handler:
void GuiObject::OnMenuSelection(UINT menuID)<br />
{<br />
switch(menuID)<br />
{<br />
case ID_FILE_QUIT:<br />
break;<br />
default:<br />
break;<br />
}<br />
}
So why is the compiler giving me this error? How do I fix it?
|
|
|
|
|
What is ID_FILE_QUIT defined as?
Mark
<br />
<br />
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
It's defined in the resource file. Visual Studio's resource builder made it.
#define ID_FILE_QUIT 40001
Right now, it's the only menu item there is.
|
|
|
|
|
Hmm I can't reproduce that.
resource.h is included somewhere?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Well this is strange... Resource.rc is #included in the header. When I hover over it with the mouse, it even tells me the #define'd value. But now I see that I am also getting a "error C2065: 'ID_FILE_QUIT' : undeclared identifier". When I #include the resource.h file in this particular .cpp file, now it suddenly works. How is it that the compiler can look up it's value on a mouse-over, but somehow can't find it unless I #include it in the .cpp file as well?
|
|
|
|
|
Kevin Strickland wrote: How is it that the compiler can look up it's value on a mouse-over, but somehow can't find it unless I #include it in the .cpp file as well?
Subtle difference between the way info is gathered to build the intellisense database and the way the compiler parses through
the code.
I hate when that happens
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: Subtle difference
That is not even close to subtle. LostYourSense is NOT A COMPILER, period.
Perhaps he can get a good trade on ebay ... compiler for filet-o-fish
|
|
|
|
|
led mike wrote: That is not even close to subtle.
I forgot the facetious tags
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: I forgot the facetious tags
I don't think Visual Studio supports those.... yet
|
|
|
|
|
Kevin Strickland wrote: So why is the compiler giving me this error?
If we are to assume that the error is pertaining to the case ID_FILE_QUIT statement, then you need to verify that it is an integer constant. Otherwise, please note the line that is in error.
"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
|
|
|
|
|
Hello MFC/Visual C++ experts,
I already read some articles and discussions about my problem in the
web:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=968335&SiteID=1
http://www.codeguru.com/forum/showthread.php?t=407572
http://forums.devx.com/archive/index.php/t-157559.html
I tried to incorporate an example I found in the web using a
CFrameWnd into my existing application, which, however, is an ATL
one (using _tWinMain to startup, instead of the approach via an
CWinApp object). I use the following to create the CFrameWnd:
m_pMainFrame = new CMainFrame;<br />
m_pMainFrame->LoadFrame(IDR_MAINFRAME,<br />
WS_OVERLAPPEDWINDOW | FWS_ADDTOTITLE, NULL,<br />
NULL);
He fails at the following assertion (line 23 in afxwin1.inl):
AFXWIN_INLINE HINSTANCE AFXAPI AfxGetResourceHandle()<br />
{ ASSERT(afxCurrentResourceHandle != NULL);<br />
It seems that he doesn't find the menubar (IDR_MAINFRAME is the ID
of my menubar). What I did before to merge the example into my pro-
ject is to copy the resource file from the example, import it into the
resource view in Visual Studio, drag the resources into my existing
resources.rc, copied the new resource IDs into my resource.h, suc-
cessfully compiled and then executed, which gives the above assertion
failure.
What do I have to do that he correctly finds my menu bar? In the
resources.rc it already is. Does he need additional informations? Does
he use the string table for that? Do I have to do DoDataExchange()?
Do I have to invoke AfxEnableControlContainer() or AfxOleInit() or
other application initializing stuff before I can use the CFrameWnd?
I don't know what else to try, so if anyone could help me, I would be
very thankful.
Best regards,
Peter.
|
|
|
|
|
p_473 wrote: using a CFrameWnd into my existing application, which, however, is an ATL
one
I only had to read that far.
If you're going to use MFC classes then, except for a (very) few classes, you need to use an MFC application.
It is possible to get around this, but whether it's portable to future versions or not, I don't know.
Here's some of the issues:
1) Initialization. The MFC library needs to be initialized. The one-and-only CWinApp object is part of this.
You'll need that object even if you don't use its message pump. You'll also need to call AfxInitialize() and/or
AfxWinInit(). From the AfxWinInit() docs:
"If you call AfxWinInit yourself, you should declare an instance of a CWinApp class. For a console application,
you might choose not to derive your own class from CWinApp and instead use an instance of CWinApp directly.
This technique is appropriate if you decide to leave all functionality for your application in your implementation of main."
2) Window messages. If you're using a message loop outside of the MFC framework, then you need to pass all unhandled
messages to the MFC framework from your message loop. You can do this by passing them to your CWinApp object's
PreTranslateMessage() method.
Hope this helps a bit.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hello Mark,
thank you for your very helpful answer. I read in some books and
also found the following:
http://support.microsoft.com/?scid=kb%3Ben-us%3B173974&x=14&y=9
So the last point for me to successful add MFC support to my ATL EXE
project is: Currently, my project uses a subclass of CAxDialogImpl<>
as the main window. It is instantiated in an object of class
CAtlExeModuleT<>, in function PreMessageLoop():
CMainDialog mainDlg;
mainDlg.DoModal();
Then, an instance of the CAtlExeModuleT<> is created and in
_tWinMain() its .WinMain() member function is invoked.
When I follow the above Microsoft-article, where it is proposed to
replace the _tWinMain function with InitInstance() and ExitInstance()
member functions of a global CWinApp object, in the InitInstance()
function a CWnd is created and CreateEx() invoked on it.
So here is my question: How to do that with my CMainDialog object?
CWnd and CAxDialogImpl aren't compatible, aren't they? I really would
like to not change the CMainDialog object since it contains many
COMMAND_HANDLER() functions and uses event sinks (COM stuff) to
realize its functionality.
Is there a way to keep it as the "main (dialog) window" of my appli-
cation? Would be great if you could help me here.
So thank you very much for your already precious help.
Best regards,
Peter.
|
|
|
|
|
I would try this before doing all that:
Note the current project's entry point setting (linker settings)
Set the project settings to use MFC DLL or static link
Make sure changing that setting didn't change the entry point setting - if so, set it back to the noted setting from step 1
Add a single global CWinApp object in the main module:
CMyWinApp theMFCApp;
Add these lines to your _tWinMain:
AfxInitialize();
AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0);
The last part I'm not sure of since I haven't used ATL windows. Wherever you have access to
the app's main message loop, add a call to your CWinApp object's PreTranslateMessage method, something like:
if (!theMFCApp.PreTranslateMessage(&msg))
{
... MFC didn't process the message - let ATL handle it...
... pass it on to the ATL message handler...
}
You should be able to create MFC windows.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hello Mark,
thank you for your help. To make the problem clearer, I decided to
put the (fortunately short) code I started from in this mail (see
below and sorry that I didn't already do that before).
I already checked the first point of your advice and my project was
already "use MFC in a shared dll". The entry point settings I didn't
find. In Visual Studio 2005 (which I use) under
Project->Settings->Configuration Properties->Linker ... and then?
Could you tell me where I find the entry point settings?
I also added the global CWinApp object.
You wrote that you are not sure about the last point. - Did you mean
the second AfxWinInit... line or the following part concerning the
app's main message loop?
> Wherever you have access to
> the app's main message loop, add a call to your CWinApp object's
> PreTranslateMessage method
Could I put it in _tWinMain or would that be "too late", do I have to
put it before, e.g. directly after instantiating the global CWinApp
object? And finally:
> ... MFC didn't process the message - let ATL handle it...
> ... pass it on to the ATL message handler...
I tried to figure out how, but didn't find out. As I wrote in my
previous mail, the WinMain() member function of the CAtlExeModuleT<>
object is invoked, which only has the int nShowCmd as a parameter.
How do I get the "msg" object into it, if you meant that? - Is there
an appropriate member function which I have to invoke instead of
the WinMain() member function?
class CSampleModule : public CAtlExeModuleT< CSampleModule >
{
public :
HRESULT PreMessageLoop(int nShowCmd)
{
HRESULT hr = CAtlExeModuleT<CSampleModule>::PreMessageLoop(nShowCmd);
if (FAILED(hr))
return hr;
CMainDialog mainDlg;
mainDlg.DoModal();
return S_FALSE;
}
};
CSampleModule _AtlModule;
extern "C" int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE ,
LPTSTR , int nShowCmd)
{
return _AtlModule.WinMain(nShowCmd);
} I hope the problem I have is clearer now. I think it only must be a
single step to the solution of the problem, but I yet don't have the
knowledge to do this step. So I hope you could help me with your
advanced knowledge - you would relieve me from this great problem I
am stuck in.
So thanks again for your help you already provided and hopefully
could do until this hard nut is cracked.
Best regards,
Peter.
|
|
|
|
|
It looks like you don't need to change linker settings if you were already set up to use the
MFC DLL library.
The CWinApp object should be outside of _tWinMain() -
CWinApp MyMFCApp;
int APIENTRY _tWinMain(HINSTANCE instance,...
{
AfxInitialize();
AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0);
<font>return _AtlModule.WinMain(nShowCmd);
}
</font>
I haven't used ATL windows so I don't know where the message loop is. There should be somewhere you can
intercept messages and send them to MFC. The PreMessageLoop looks promising.
I'll take a look around and see if I can give you a more specific answer.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hello Mark,
Thank you for your help, so the last problem to solve is how to
get one main event loop for the WinApp object and the _AtlModule?
Yes, you would really help me with taking your look around because
I think your possibilities (as a MVP) are greater than mine.
Nevertheless I of course will try my best to also figure out a
solution in parallel. I think if we could solve that problem we
could be rightly proud, since it seems not to be well-documented.
So I hope we will find the solution and look forward to your answer.
Best regards,
Peter.
|
|
|
|