Very fundamental question on scope in Visual C++ .NET C++/CLI programming [modified]
-
I am writing a C++/CLI CLR Windows Forms application. I'm able to write lots of evaluation programs and try out many features but I'm having trouble understanding how to architect my total application scope-wise. I have one main form ( call it "Form1" ) and it may spawn some modal dialog boxes. In addition I want to create some classes, preferrably managed ref classes and refer to their methods and invoke their member functions from the event functions in Form1 (e.g. Form1_Load, button1_Click, etc.). I'd like to code these ref classes in separate files. I also have an assembly from a third party which I've been able to use successfully (Galil motion controls DMCdNet.dll). So my question: Is their a canonical way of coding managed C++/CLI ref classes in separate files in my Visual Studio project, instantiate those managed class objects (somewhere) and then be able to refer to them in the private member (event receiver) functions in Form1.h? The books I've learned C++ from are: - C++: How To Program by Deitel & Deitel (very early edition) - Pro Visual C++ /CLI and the .NET Platform by Stephen G. Fraser
Jeff Cooper
modified on Friday, May 23, 2008 10:30 AM
-
I am writing a C++/CLI CLR Windows Forms application. I'm able to write lots of evaluation programs and try out many features but I'm having trouble understanding how to architect my total application scope-wise. I have one main form ( call it "Form1" ) and it may spawn some modal dialog boxes. In addition I want to create some classes, preferrably managed ref classes and refer to their methods and invoke their member functions from the event functions in Form1 (e.g. Form1_Load, button1_Click, etc.). I'd like to code these ref classes in separate files. I also have an assembly from a third party which I've been able to use successfully (Galil motion controls DMCdNet.dll). So my question: Is their a canonical way of coding managed C++/CLI ref classes in separate files in my Visual Studio project, instantiate those managed class objects (somewhere) and then be able to refer to them in the private member (event receiver) functions in Form1.h? The books I've learned C++ from are: - C++: How To Program by Deitel & Deitel (very early edition) - Pro Visual C++ /CLI and the .NET Platform by Stephen G. Fraser
Jeff Cooper
modified on Friday, May 23, 2008 10:30 AM
aa1ww wrote:
but I'm having trouble understanding how to architect my total application scope-wise.
That only means you have not yet studied Object Oriented Programming well enough yet. It does take time so don't get discouraged. However most if not all of the issues you seem to be asking about are covered in the classic Design Patterns book.[^] Most if not all of these patterns can also be seen in some level of detail on Wikipedia. And of course there are a multitude of other sites as well that discuss Patterns. Just to be clear there may not be anything specific to C++/CLI about your question, the answer you seek is a combination of fundamental C++ file management, .NET Platform fundamentals and Object Oriented Design. The bad news is there is no short cut to understanding the information. You must study it all until you have a sound grasp of all the concepts. Anything short of that will leave you constantly running into problems that you don't understand if you start trying to work on a production project.
led mike
-
aa1ww wrote:
but I'm having trouble understanding how to architect my total application scope-wise.
That only means you have not yet studied Object Oriented Programming well enough yet. It does take time so don't get discouraged. However most if not all of the issues you seem to be asking about are covered in the classic Design Patterns book.[^] Most if not all of these patterns can also be seen in some level of detail on Wikipedia. And of course there are a multitude of other sites as well that discuss Patterns. Just to be clear there may not be anything specific to C++/CLI about your question, the answer you seek is a combination of fundamental C++ file management, .NET Platform fundamentals and Object Oriented Design. The bad news is there is no short cut to understanding the information. You must study it all until you have a sound grasp of all the concepts. Anything short of that will leave you constantly running into problems that you don't understand if you start trying to work on a production project.
led mike
I'm sure I don't have my arms around the design idioms one might choose from but some of the architecting does indeed seem to be Visual C++ & C++/CLI dependent. Some examples of this: - Form1 is instantiated and launched by Application::Run which is passed a managed Application Context handle. So that requires an understanding of the specifics of the Application class. Would the descriptions in the "Design Patterns" book take that mechanism into account? - Managed classes cannot be instantiated at global file scope. This isn't as high-level a concept but it impacts the implementation as creating a lot of nonmanaged objects misses the advantages of the managed heap and creates a lot of messy typecasting and patching code bewteen the user defined nonmanaged classes and the managed Windows Forms classes. I'll look at Wikipedia. I was hoping that a few very common patterns more complicated than example programs but still idiomatic and popular might be in the code extant. I'll keep looking. Coop
Jeff Cooper
-
I'm sure I don't have my arms around the design idioms one might choose from but some of the architecting does indeed seem to be Visual C++ & C++/CLI dependent. Some examples of this: - Form1 is instantiated and launched by Application::Run which is passed a managed Application Context handle. So that requires an understanding of the specifics of the Application class. Would the descriptions in the "Design Patterns" book take that mechanism into account? - Managed classes cannot be instantiated at global file scope. This isn't as high-level a concept but it impacts the implementation as creating a lot of nonmanaged objects misses the advantages of the managed heap and creates a lot of messy typecasting and patching code bewteen the user defined nonmanaged classes and the managed Windows Forms classes. I'll look at Wikipedia. I was hoping that a few very common patterns more complicated than example programs but still idiomatic and popular might be in the code extant. I'll keep looking. Coop
Jeff Cooper
aa1ww wrote:
but some of the architecting does indeed seem to be Visual C++ & C++/CLI dependent.
Not tying to be mean but I suggest you stop using the word architecture until you have a better grasp on Object Oriented Design.
aa1ww wrote:
Some examples of this: - Form1 is instantiated and launched by Application::Run which is passed a managed Application Context handle. So that requires an understanding of the specifics of the Application class.
As I stated in my last post, that is an aspect of the .NET Platform and the .NET Framework, it is NOT specific to C++/CLI.
led mike wrote:
Just to be clear there may not be anything specific to C++/CLI about your question, the answer you seek is a combination of fundamental C++ file management, .NET Platform fundamentals and Object Oriented Design.
aa1ww wrote:
Would the descriptions in the "Design Patterns" book take that mechanism into account?
That does not make any sense. My reference to Object Oriented Design and Patterns was directed at your need to design your own code, not your need to understand the .NET Framework design. Although it could be applied that way because the .NET Framework uses many of the Design Patterns, that was not the intention of my statement.
aa1ww wrote:
I'll look at Wikipedia. I was hoping that a few very common patterns more complicated than example programs but still idiomatic and popular might be in the code extant. I'll keep looking.
I have no idea what that means but as I stated in my last post, this is a large subject and it takes time. So if you are looking for some sort of three hour tour that imparts the type of experiential knowledge that takes years for most of us to obtain I believe you are going to be spinning your wheels.
led mike
-
I'm sure I don't have my arms around the design idioms one might choose from but some of the architecting does indeed seem to be Visual C++ & C++/CLI dependent. Some examples of this: - Form1 is instantiated and launched by Application::Run which is passed a managed Application Context handle. So that requires an understanding of the specifics of the Application class. Would the descriptions in the "Design Patterns" book take that mechanism into account? - Managed classes cannot be instantiated at global file scope. This isn't as high-level a concept but it impacts the implementation as creating a lot of nonmanaged objects misses the advantages of the managed heap and creates a lot of messy typecasting and patching code bewteen the user defined nonmanaged classes and the managed Windows Forms classes. I'll look at Wikipedia. I was hoping that a few very common patterns more complicated than example programs but still idiomatic and popular might be in the code extant. I'll keep looking. Coop
Jeff Cooper