A Shocking display of ignorance !

[ThermoSight]

Hi !

Please excuse my shocking display of ignorance but I've got this C++ .NET problem that I can't seem to resolve any other way.


In many if not most cases, I encounter problems on a monumental scale when two .h files include each other.

For reasons I've been unable to determine, it doesn't happen in every case, but I've suffered enuf traumatic events to be wary of mutual inclusions.

Frequently I'll find that when I do this, at least one class/sourcefile will compain that such-and-such namespace doesn't exist when, clearly, it does.

Then, thinking that the "#pragma once" is preventing the .h file from being included properly, I comment out the "#pragma once" statement, only to be greeted with complaints that a class is being redefined.

Further, there doesn't seem to be an "#ifdef" or "#ifndef" statement to assist me in controlling compilation.

'til now, I have been successful in finding "workarounds", but I can't count on that in the future. So, what is the recommended procedure when two .h files must include each other?

thanks for your help with this very puzzling problem.

bill

[wildfrog]

One thing that often helps is to use forward declerations:


// ClassA.h

#include "ClassB.h"

class ClassA
{
ClassB* ptr;
};


// ClassB.h

// instread of including "ClassA.h" just make a forward decleration
class ClassA;

class ClassB
{
ClassA* ptr;
};

- petter

[ThermoSight]

Duh!

Why couldn't **I** have thought of that?

Thank you SO MUCH for your help, Sir.


-bill-

[ThermoSight]

Hello again.

I would like to revisit the "mutual includes" problem wherein two .h files include each other. I have attached two .h files for your inspection.

This is an ultra-simple MDI application comprising exactly two .h files. Form1 is the parent form which contains a single button ("Create-a-Kid"), and a text box where the name of the currently active child is displayed.

ChildFormA is the other .h file. As the files currently exist, the application works. Clicking on "Start" brings up Form1, and clicking on "Create-A-Kid" creates a child form. Note that closing a child form removes that child, causing the focus to revert to the previous form, and that change of focus is reflected in the parent form's text box which displays the now-newly activated child.

But, closing the last child form LEAVES THE NAME OF THE LAST CHILD in the text box, as if the child was still alive.

To resolve this problem, the parent form provides three inline functions: decrementChildCount(), remainingChildren(), and clearLastName().

Currently commented out in the ChildFormA declaration, are five lines in the button1_Click method which use those three functions to determine whether a closing child form is the last remaining child form, and if so, to clear the name of the last child from the parent's textbox. (Also commented out is the "include Form1.h" statement near the top of ChildFormA.h).

However, the "mutual includes" problem prevents the code from compiling.

Can someone here show me what I'm doing wrong?

Thanks again.

bill

[NoHero]

[ Merged Threads ]

[NoHero]

Please reuse your existing threads if the topic is almost the same, this helps to keep the problem better focused on one thread and it is more consince for the others.

Thanks

[ThermoSight]

OK! Thanks NoHero.

Say, I have an update that gets this particular job done, but the basic problem remains.

As it turns out, I can work with the basic Form pointer rather than the more specific MDI2::Form1 pointer because MS has included the tools necessary to work with forms and controls (please see button1_Click method in the attached file).

However, while that accomplishes this specific task (clearing the TextBox when all the child forms have been deleted), the problem remains that functions declared in the parent form class cannot be called by the children because the "mutual includes" problem prevents including "Form1.h", or at least as I have implemented it here.

I'm not suggesting this is a .NET problem. On the contrary; it is certainly my error but I just can't see what I've done wrong. Can someone help me out here (examine two attached files in the earlier post)?

Thanks for your help.

addendum: Boy, I guess I can't even do an upload properly. I just looked at the attached file. Don't waste your time. it's garbage. Thanks anyway.

addendum2: I resolved the problem in my usual way ... a "workaround".
I created a third class called Bridge. Because of the "mutual includes" problem, ChildFormA cannot invoke the functions declared in Form1.h. So, what it does is call an intermediate function declared in Bridge.h which in turn calls the target function in Form1.h. Very messy; indeed, it's unbearably so. Can anyone show me what I'm doing wrong with the includes in .NET? The #ifdef and #ifndef don't seem to do a darn thing in .NET.


bill

[ThermoSight]

If anyone's interested, I've taken this quest for the ultimate answer to life a step further, but still haven't reached the ultimate goal .....

1st, I've determined that the #ifdef/#ifndef I thought didn't work, does in fact work. But that hasn't gotten me any closer to my very elusive goal of overcoming the "mutual includes"problem.

2nd, I've determined that in addition to the "bridge file" I mentioned yeserday wherein mutual includes are avoided by instead calling functions in a 3rd class used solely to make calls on the first class, the trivial solution of combining the two classes in one file also resolves the problem: class 2 can call functions in class 1 directly, the bridge class is no longer needed.

Neat, but one can't do that very often. (also, I found that when combining two forms classes in one file, one o' the forms cannot be seen in the IDE although it is entirely functional in the executable).

I plan to continue working with #ifdef/#ifndef and #define/#undef to find a way around this problem. If you already have the answer, I'd sure appreciate hearing from you.

Best wishes,

bill