C / C++ / MFC

Terry O'Nolley23-Sep-03 7:53

Terry O'Nolley

23-Sep-03 7:53

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.

Michael Dunn22-Sep-03 17:58

Michael Dunn

22-Sep-03 17:58

You need include guards in your header files:

// In ClassX.h
 
#ifndef CLASSX_H_INCLUDED
#define CLASSX_H_INCLUDED
 
// rest of header here...
 
#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

Terry O'Nolley22-Sep-03 18:15

Terry O'Nolley

22-Sep-03 18:15

Thanks Mike - that did the trick.

I had used those a while back without remembering why I used them Smile | :)

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.

Rick York22-Sep-03 18:26

Rick York

22-Sep-03 18:26

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

Alvaro Mendez23-Sep-03 4:22

Alvaro Mendez

23-Sep-03 4:22

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.

Rick York24-Sep-03 14:09

Rick York

24-Sep-03 14:09

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

John M. Drescher22-Sep-03 18:02

John M. Drescher

22-Sep-03 18:02

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_)
// make sure _MYCPPFILENAME_ is not defined in any of your headers or cpp files
#define _MYCPPFILENAME_

// Put your class def here.

#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

Terry O'Nolley22-Sep-03 18:20

Terry O'Nolley

22-Sep-03 18:20

I have done what you suggested and it is perfect.
This will save me a lot of time. Many thanks!

John M. Drescher22-Sep-03 18:30

John M. Drescher

22-Sep-03 18:30

I use the macro for this all the time because I prefer the #ifdef solution and it saves me a a few steps...

John

Callbacks

halblonious22-Sep-03 16:50

22-Sep-03 16:50

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

Phil Speller22-Sep-03 22:14

Phil Speller

22-Sep-03 22:14

The problem is to do with your FontHook pointer. To get this working you need to remove the following from your code:

<br />
  //create the pointer<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

halblonious23-Sep-03 11:35

23-Sep-03 11:35

Thank you very much, that seemed to work. Now, I'm off to figure out how to make do what I want...

halblonious

Member 42425922-Sep-03 22:14

Member 424259

22-Sep-03 22:14

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

halblonious23-Sep-03 11:37

23-Sep-03 11:37

I've got it working now. Thank you for your comment.

halblonious

David Crow23-Sep-03 3:07

David Crow

23-Sep-03 3:07

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?

halblonious23-Sep-03 11:36