Best practices for C++/CLI use of forms?

[Chris]

I'm a C++ developer finally getting up to speed with C++/CLI and
the .NET framework.

I'm wondering if anyone knows of resources, or has tips to share, on
best practices for working with and extending visual content in
Windows Forms in C++. In addition to seeking general resources I have
three particular questions:

1 - Is there a better practice for using the visual form editor than
its default behavior of injecting all code and handlers into the
generated .h file? I would prefer to be able to designate delegate or
controller classes in files that don't contain generated code, and to
factor these into manageable chunks (e.g. a delegate for each
application menu, a controller for each major panel on the main
window, etc.)

2 - Switching visual content and controls: I want to have some panels
of content that get swapped into a view based on application state. I
don't want a tab control; I'm after a content pane that changes modes
of content viewing - not unlike Explorer for its various view modes,
or iTunes as it changes from library to music store etc. Right now
it's looking to me like I'll have to implement these alternate content
panels purely in code and remove and add views programatically. Is
there a best approach here? It would be nice to be able to layout
Panels visibly and have them instantiated for swapping into & out of
the form.

- Custom controls: what's the best practice if I want to subclass
control - again does it all have to be done programatically and added
to the form in code, or is there a way to subclass a control and
designate your subclass in the visual form editor?

Thanks for help & newb tolerance.
- Chris

 

[Ben Voigt [C++ MVP]]

I'm a C++ developer finally getting up to speed with C++/CLI and
the .NET framework.

I'm wondering if anyone knows of resources, or has tips to share, on
best practices for working with and extending visual content in
Windows Forms in C++. In addition to seeking general resources I have
three particular questions:

All the wizards and designers work much, much better with C#. .NET makes it
so easy for C# and C++/CLI to work together that there's no reason not to.

1 - Is there a better practice for using the visual form editor than
its default behavior of injecting all code and handlers into the
generated .h file? I would prefer to be able to designate delegate or
controller classes in files that don't contain generated code, and to
factor these into manageable chunks (e.g. a delegate for each
application menu, a controller for each major panel on the main
window, etc.)

This is a side effect of using a designer built around C#.

2 - Switching visual content and controls: I want to have some panels
of content that get swapped into a view based on application state. I
don't want a tab control; I'm after a content pane that changes modes
of content viewing - not unlike Explorer for its various view modes,
or iTunes as it changes from library to music store etc. Right now
it's looking to me like I'll have to implement these alternate content
panels purely in code and remove and add views programatically. Is
there a best approach here? It would be nice to be able to layout
Panels visibly and have them instantiated for swapping into & out of
the form.

This sounds like a tab control is still your best choice, hide the tabs if
you don't want them.

- Custom controls: what's the best practice if I want to subclass
control - again does it all have to be done programatically and added
to the form in code, or is there a way to subclass a control and
designate your subclass in the visual form editor?

In .NET subclassing (and derivation) are mostly not done. Instead extended
behavior is achieved through containment and aggregation.

So usually you would make a user control that contains the other control you
wanted modified behavior of, you'd implement the modified behavior in code
of the user control, then you'd put the user control on your other forms.