|
How would you resolve the issue I was having without using preprocessor directives?
I seemed to have been caught in a Catch-22.
WHen I followed your example, it didn't give an error relating to duplicate class definitions, but I got errors for an undefined keyword (ClassX) because the ClassX header wasn't included until after I tried to define an object of ClassX.
|
|
|
|
|
|
I know this. But your first suggestion told me to include the header file in the .cppp file for Window 2 to avoid the "duplicate class name" error. I couldn't do this, because there was a member variable of tyoe ClassX in Window2.
When presented with the preprocessor directives, I implemented them and it fixed the problem but you said this was not a preferred technique because of portability concerns.
How would you do this without preprocessor directives?
ClassX
Window1 : has a member var of ClassX so needs #include ClassX.h
Window2 : has a member var of ClassX so needs #include ClassX.h
if I include them both where you have agreed they need to be ie before the ClassX object is defined I get a compiler error of a duplicate class name.
If I include them where you first told me (in the CPP file before the window header) I get an undefined name error.
Using preprocessor directives allowed me to successfully do what I needed but you said it was a poor solution.
I would like to know the correct solution.
|
|
|
|
|
You need include guards in your header files:
#ifndef CLASSX_H_INCLUDED
#define CLASSX_H_INCLUDED
#endif // ndef CLASSX_H_INCLUDED There is also #pragma once but I prefer the above way since you can test for whether ClassX.h has been included with #ifdef CLASSX_H_INCLUDED
--Mike--
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
CP SearchBar v2.0.2 released
|
|
|
|
|
Thanks Mike - that did the trick.
I had used those a while back without remembering why I used them
And I never noticed when I stopped using them.
I guess it took a big screeching halt to make me remember to always use them.
|
|
|
|
|
I take things a bit farther. Here is what I do :
#ifndef _HEADER_H
#define _HEADER_H
#else
#error repeated include of this file
#endif
then if this header must be included in another header file (nested) I do this -
#ifndef _HEADER_H
#include header.h
#endif
I went through and converted a rather large project to this scheme and my compile times decreased considerably. If you use a standard macro naming mechanism (_HEADER_H for me) then this is quite easy to use.
The Ten Commandments For C Programmers
|
|
|
|
|
Rick York wrote:
#ifndef _HEADER_H
#include header.h
#endif
I used this technique for a while and then I realized that the increased code clutter (three lines/include vs just one) wasn't worth the extra milliseconds saved per compiled unit. Instead, I made sure to use a precompiled header which really sped things up.
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
I know what you mean but I only do this when nesting include files - including one header in another. This keeps the headers safe. I don't do this in standard code as I'll see the error soon enough.
Yes, in most projects, the savings amount to milliseconds but in large scale projects this can add up significantly. I have been forced to use a library that is absolutely atrocious in this respect.
The Ten Commandments For C Programmers
|
|
|
|
|
Terry O`Nolley wrote:
Why is it that you can include headers like "afxdb.h" in a zillion files and not get this error?
You can use either an ifdef to include the cpp file only once
#if !defined(_MYCPPFILENAME_)
#define _MYCPPFILENAME_
#endif //def _MYCPPFILENAME_
Or you can use this as the first statement in your header file
#pragma once
There is a macro in vc6 that does this for you. Click Tools then customize then addins and macro files and then make sure SAMPLE is checked. Then open your header file and click tools then macros select sample and then select OneTimeInclude and click run.
John
|
|
|
|
|
I have done what you suggested and it is perfect.
This will save me a lot of time. Many thanks!
|
|
|
|
|
I use the macro for this all the time because I prefer the #ifdef solution and it saves me a a few steps...
John
|
|
|
|
|
In a function, I create a font chooer dialog for my user, for which I'm trying to add a callback function, like so:
//create the pointer
LPCFHOOKPROC FontHook;
//create the font chooser dialog
CFontDialog dlg(&LogFont,CF_ENABLEHOOK|CF_EFFECTS|CF_BOTH|CF_NOVECTORFONTS|CF_NOSCRIPTSEL|CF_INITTOLOGFONTSTRUCT,NULL,NULL);
//tell it to hook to the function
dlg.m_cf.lpfnHook = FontHook;
//display the font dialog
if(dlg.DoModal() == IDOK)
{
//blah blah
}
Then, elsewhere in the view I added the actual callback function, like so:
UINT CALLBACK FontHook(HWND hdlg,UINT uiMsg,WPARAM wParam,LPARAM lParam)
{
//blah blah
return TRUE;
}
It compiles fine, but when I try to use the font dialog is gives me an application error:
"The instruction at '0xcccccccc' referenced memory at '0xcccccccc'. The memory could not be 'read'."
It desplays this three times, before quitting out. I figured out it's on the .DoModal line where it's having the issue, I think. It gives me this error when debugging:
"Unhandled exception in Application.exe: 0xC0000005: Access violation."
Can anyone please tell me what I'm doing wrong or forgetting to do?
halblonious
|
|
|
|
|
The problem is to do with your FontHook pointer. To get this working you need to remove the following from your code:
<br />
LPCFHOOKPROC FontHook;<br />
Then ensure that you have a prototype for the callback fn somewhere before where you create your dialog. Prototype will look something like:
<br />
UINT CALLBACK FontHook( HWND, UINT, WPARAM, LPARAM );<br />
What you are doing wrong is creating an uninitialised local pointer in your dialog creation fn and you specify this pointer as the address of the callback fn. In debug mode, items such as un-initialised pointers always get set to 0xCCCCCCCC so that it's easy to recognise them as such.
Phil
|
|
|
|
|
Thank you very much, that seemed to work. Now, I'm off to figure out how to make do what I want...
halblonious
|
|
|
|
|
Try this instead of ur function write
UINT_PTR CALLBACK CFHookProc(
HWND hdlg, // handle to dialog box
UINT uiMsg, // message identifier
WPARAM wParam, // message parameter
LPARAM lParam // message parameter
);
and then try out if not write back
Thanx
TAKE CARE
|
|
|
|
|
I've got it working now. Thank you for your comment.
halblonious
|
|
|
|
|
In addition to what Phil has already pointed out, by using CF_BOTH , I believe that the hDC member of your LOGFONT structure must also be initialized. Are the other members properly initialized?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
They must be, because it seems to work now that I changed that line. Thank you.
halblonious
|
|
|
|
|
hi~
Screen go blank after a certain time of no action from user.
i draw *.jpeg on my dialog.
when my screen go blank and wake up, my drawing on dialog is gone.
so i think it will be ok to call OnPaint after getting WM_POWERBROADCAST,
but i failed to get WM_POWERBROADCAST. plz help me to get how i can get WM_POWERBROADCAST
|
|
|
|
|
This shouldn't be necessary.
You should perform all your painting in response to a WM_PAINT message (for a CDialog -derived class, in your OnPaint handler).
If you need to perform some drawing elsewhere, it's typically better to update your state, then call Invalidate to redraw the whole window, or InvalidateRect to redraw only a portion of the window. Windows will then post a WM_PAINT message to your window (if there is an invalid region) once any higher priority messages have been processed.
You should consider any drawing operations performed at any other time to be temporary.
|
|
|
|
|
Hi,
does anyone know where i can find a deivce manager like project?
thanks
|
|
|
|
|
|
Where can I find code samples for this control? I am using VC++6.
|
|
|
|
|
MSDN is a good place to start. Google.com would be another.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Question: Is it possible to implement Drag & Drop so that Windows (shell) will create a "Copying" files progress dialog during the drop operation?
I have an MFC application that implements asynchronous OLE drag and drop between a TreeView and Windows Explorer using CFSTR_FILECONTENTS/CFSTR_FILEDESCRIPTOR clipboard formats.
With synchronous drag and drop, an hour glass cursor is displayed ... with asynchronous drag and drop, no feedback at all is provided via the cursor (I believe).
It is desired to display a "Copying files" progress dialog indicating the status of the copying operation when my application is the DragSource and Windows Explorer is the DropTarget.
Can anyone point me in the correct direction to get Windows to display this dialog when it is the drop target? Does it require additional clipboard formats? Does it require delayed rendering? Does it require a shell extension?
Any help would be greatly appreciated 'cause I am stumped.
Thanks.
- matt
|
|
|
|