I just don't get it (Windows Forms that is). Please Help!

[A Wieser]

I've just started climbing the steep learning curve from VC6/MFC to Windows
forms and C++/CLI.

But I just can't find the documentation that describes the philosophy of
what's going on.

A simple example:

I want to create a popup menu class that can be reused on multiple forms,
and starts out with the some default items on it that I then add to.

I found the ContextMenuStrip component, but I can't see a way to derive a
class from this alone, and have the designers available for the class, and
have localization support.

Is there support for something like this:

public ref class MyContextMenuStrip : public
System::Windows::Forms::ContextMenuStrip
{
mypopup2(void)
{
// create all of my default menu stuff here, but have it updated by
the form designer!
}

// ... etc. etc.
};

and still having the ability to have localizable resources, and decent
editing, or must I start coding everything by hand if I want to factor out
common code in this way.

Tony

 

[Bob Powell [MVP]]

I'm not sure exactly what your problem is but you may want to consider the
way that Windows Forms and the IDE work together.

The Visual Studio IDE serializes code into and out of the
InitializeComponent method. This method isn't a member of the Form or
Control or even Component class but is put into the source by the code
serializer. The type, position and settings of all controls are defined in
this method and when it says in the help-file "Do not edit this method by
hand" youshould be careful not to because the method is also parsed to get
the settings of the various components of the form at design time.

Essentially, if you want to fully custmise the content of your form, you can
but only by altering the code outside of the InitializeComponent. If you
want the IDE to manage the code you can only use what it provides and never
touch the InitializeComponent.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[A Wieser]

| I'm not sure exactly what your problem is but you may want to consider the
| way that Windows Forms and the IDE work together.

Thanks for the reply.

I'm really looking for two things:

1. A way to edit a ContextMenuStrip in isolation of a form using the
designer, so that the localization, etc is handled in a convenient way.

2. A way to use "Visual Inheritance" (as I think it's called) from C++.
That is, a way to put part of a form in a base class, so they can share
menus, toolbars, etc, and then specialize the resource displayed and add
additional functionality through inheritance. It appears that VB and C#
support this, but not C++.

Tony

| > I've just started climbing the steep learning curve from VC6/MFC to
| > Windows
| > forms and C++/CLI.
| >
| > But I just can't find the documentation that describes the philosophy of
| > what's going on.
| >
| > A simple example:
| >
| > I want to create a popup menu class that can be reused on multiple
forms,
| > and starts out with the some default items on it that I then add to.
| >
| > I found the ContextMenuStrip component, but I can't see a way to derive
a
| > class from this alone, and have the designers available for the class,
and
| > have localization support.
| >
| > Is there support for something like this:
| >
| > public ref class MyContextMenuStrip : public
| > System::Windows::Forms::ContextMenuStrip
| > {
| > mypopup2(void)
| > {
| > // create all of my default menu stuff here, but have it updated
by
| > the form designer!
| > }
| >
| > // ... etc. etc.
| > };
| >
| > and still having the ability to have localizable resources, and decent
| > editing, or must I start coding everything by hand if I want to factor
out
| > common code in this way.
| >
| > Tony
| >
|
|

 

[Stoitcho Goutsev \(100\)]

A Wieser,

ContextMenuStrip is a control that cannot be edited outsude if the context
of a form (or user control). It needs to be placed on some design surface in
order to be edited.

ContextMenu strip I believe can be localized as part of the form or user
control localization. When you localize the form or user control to which
this context menu belongs you can provide different localized content.

I have the feeling that coming from MFC you don't understand the consepts of
visual design and RAD applications. I think you should start from there.

 

[A Wieser]

|A Wieser,
|
| ContextMenuStrip is a control that cannot be edited outsude if the context
| of a form (or user control). It needs to be placed on some design surface
in
| order to be edited.
|
| I have the feeling that coming from MFC you don't understand the consepts
of
| visual design and RAD applications. I think you should start from there.
|

So, if I want to reuse something, I have to copy and paste it onto the other
form, and double my localization and maintenance work? I think I understand
the concept of visual design and RAD, but the motivation? That's another
matter altogether.

I had hoped that C# etc wasn't just for building throw away prototypes, and
could be used to build a long lasting, maintainable product. Maybe I was
mistaken.

Tony

 

[Kevin Spencer]

So, if I want to reuse something, I have to copy and paste it onto the

other
form, and double my localization and maintenance work? I think I
understand
the concept of visual design and RAD, but the motivation? That's another
matter altogether.

I had hoped that C# etc wasn't just for building throw away prototypes,
and
could be used to build a long lasting, maintainable product. Maybe I was
mistaken.

Don't believe everything you read. It is certainly possible to do exactly
what you want. You can create a class that inherits
System.Windows.Forms.ContextMenu, just as you would inherit any other
inheritable class, customize the derived class, and use it in many projects.
I have done this myself many times. There are quite a few (too many IMHO)
..Net developers that do not understand the underlying technology involved in
the Visual Studio GUI, and its design-time support, which is fully available
to developers for developing their own designers and design-time components,
with all the support that the out-of-the-box components provide. They do not
seem to realize that all Visual Studio does is write code for you, which you
can perfectly well write for yourself.

Basically, you have 2 different issues, one of which is a piece of cake.
First, inheriting and customizing a Control. That part should not be
difficult at all for you.

The second task is providing design-time support for your Control. This is
the hard part, as it basically involves developing another class or classes
to interact with the GUI and provide the visual support, and of course,
there are no designers for these classes. But coming from a C++ background,
this shouldn't be difficult for you. Getting familiar with all of the
classes involved is going to be the real work.

Here are several reference points to start from. The first is more or less
an overview, with some walkthroughs and examples:

http://msdn2.microsoft.com/en-us/library/w29y3h59(VS.80).aspx

This second reference point gets a bit deeper into the Component Model, and
includes another section on developing Designers for Components:

http://msdn2.microsoft.com/en-us/library/0ffkdtkf(VS.80).aspx

Finally, here is a link to the documentation for the
System.ComponentModel.Design Namespace, which contains all of the classes
needed to develop Designers and Design-time support for Components:

http://msdn2.microsoft.com/en-us/library/system.componentmodel.design.aspx

Good luck!

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

I recycle.
I send everything back to the planet it came from.

 

[Stoitcho Goutsev \(100\)]

Kevin,

What Wieser wants is to design the control (context menu) as he designs user
control let say - saparately outside the context of any class. Only controls
that provide root designer can do that. Even thought it can be done it won't
be by simply deriving from the ContextMenu class.

One can create a component or a control and it can be reused, but the think
is that it needs to be placed on a form or user control in order to be
desigened. Nothing is lost; the design time experience and reusability is
still there and this is what I tried to explain.

I kind of disagree that implementing the design time support is the hardest
part. Working myself in a component company I'd say that the design time
support is one smller part of the whole control development. The only
difficulty comes from the fact that MSDN doesn't privde good documentation
on it, but thanks to the Reflector tool the things are not that bad.


In addition to the sources that Kevin provided I'd add the
the windows forms official site http://www.windowsforms.net/ and more ints
section for desgners
http://www.windowsforms.net/Articles/default.aspx?PageID=1&Cat=Designer&ModuleFilter=131&tabindex=2


Kevin you are right, though, one should not believe everything one reads on
the net.

 

[Kevin Spencer]

Yeah, the documentation of the Designer namespace is sparse, and that is the
hardest part, but that's why I said that creating the Designer is the hard
part! In the beginning, at least, there's a lot of "try this and see what
happens" in the learning process.

--

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

I recycle.
I send everything back to the planet it came from.