My Problem is i have 2 forms and 2 form must know each other.Becuase vs2005 code generater puts everything in .h (header) files.i came to a point in which i must do //in Form1.h header file #include "Form2.h" ref class Form1 { Form2^ m_MyForm2; .... }; //in Form2.h file ref class Form2 { Form1^ m_MyForm1; } Don't say immediately YOU SHOULD PUT .h to .cpp(i know that..) if it was "Native C++" i would use forward decleration .h file and include all neccessary header files to cpp but unfortunately in C++/CLI.net this causes problems.But i decided to do as in Native C++ and worked on generated files,seperated function declerations to .h , and function definations to a .cpp(this also doesn't solve anything) you just cant forward dec a ref class .(at least in my case this didn't solve the problem) what i have tried was... //in Form1.h header file ref class Form2; //Forward dec... ref class Form1 { Form2^ m_MyForm2; .... }; //in Form1.cpp #include "Form2.h" //in Form2.h file ref class Form1; //Forward dec ref class Form2 { Form1^ m_MyForm1; } //int Form2.cpp file #include "Form1.h" this doesn't solve anything .i am sure there is a simple way of doing this.if you know ,say it please.

Splitting classes into .h/.cpp files is not be a problem in C++/CLI projects and it will get rid of your problem if you do it right. In fact, that's what I'm doing in my C++/CLI projects with great success right now.

What you've done is an entirely different problem: Form1.h includes Form2.h and Form2.h includes Form1.h. That's a circular header dependency which will always cause problems, whether in native C++ or C++/CLI.

You can get away by not including the respectively other header in each header file, keeping the prototype forward declaration (the "ref class Form1;" or "ref class Form2;" line) but moving *all* code that accesses members of Form1 or Form2 into the .cpp files. This, however, would violate the self-contained header rule (a header should include all other headers it needs to compile, otherwise you might end up in include-order-hell some day).

The better choice thus would be to create an interface for the methods you need and implement that in your forms. This would break the circular dependency and make the headers self-contained again. It would also have the advantage of loosening the coupling between both forms, enabling you to be more flexible about replacing one of the forms in the future.

On a more general note, you really shouldn't be creating forms that rely on each other. Forms really always have a parent-child relationship. If a child needs to inform its parent of something, events are the right thing to use. Communication between two windows on the same level (eg. two MDI child windows) is highly unusual and certainly not expected by the user :)