Deriving from custom forms in C++, is it possible?

  • Thread starter Thread starter Vincent Finn
  • Start date Start date
V

Vincent Finn

I know the answer to the question above is yes but my reason for
asking is that it doesn't seem to work properly

I have a manged C++ WinForms project
In it I have a form A, I want to derive a form B from it

Firstly the menu that the MSDN says should be available from the 'Add'
menu to 'Add an Inherited Form' isn't there
This seems to only be available for C# and VB.Net

Fine I can do it by hand, messy but not a big problem

I created form B and derived it from form A instead of
'System::Windows::Forms::Form'
Then I hit the second problem
This compiles and runs but I can't edit form B in the designer

Am I missing a step here or is it not possible to get the form
designer for inherited form in C++?

Vin
 
For a real answer, we kinda need more info. IE, what do you mean by "Not
being able to edit the inherited form"?? What are you trying to edit??

Are you trying to edit the stuff (controls, menu bar, menu's) set up on the
first form?? almost everything in form A would be private, and so you
couldn't edit it in form b. Change them all to protected (Faster if you do
this by hand).

Next thing to check is namespaces. In order for form B to have any chance
of comming up in the form designer, it can only be wrapped inside of 1
namespace. IE namespace1::FormB is valid, Namespace1::SubNamespace1::FormB
will crash on you.

Can't think of anything else obvisous (can't spell either)..

GE
 
For a real answer, we kinda need more info. IE, what do you mean by "Not
being able to edit the inherited form"?? What are you trying to edit??
Click to expand...

I mean that when I try to open the form in the Design window (by
double-clicking on the .h file) I get the following error

--------------
The designer could not be shown for this file because none of the
classes within it can be designed. The designer inspected the
following classes in the file:

B --- The base class 'Config.A' could not be loaded. Ensure
the assembly has been referenced or built if it is part of the
project.
--------------
Are you trying to edit the stuff (controls, menu bar, menu's) set up on the
first form?? almost everything in form A would be private, and so you
couldn't edit it in form b. Change them all to protected (Faster if you do
this by hand).
Click to expand...

Don't get that far although that would have been a question later
since I noticed in C# that you don't get access to the events for
buttons that are on the base form in the derived form.
making them 'protected virtual' gives access although it is a bit
messy that you can't get to the handler by double-clicking, I assume
that'll be the same in C++
Next thing to check is namespaces. In order for form B to have any chance
of comming up in the form designer, it can only be wrapped inside of 1
namespace. IE namespace1::FormB is valid, Namespace1::SubNamespace1::FormB
will crash on you.
Click to expand...

They are both in the Config namespace (that is the project name)
I tried using the 'Config::B' and simply 'B' but made no difference

Any other suggestions?

Vin
 
This is fireangel again, just at my work account..

The only other thing I can really think of is dealing with constructors. Do
you have any default constructors defined?? IE, FormA (void), FormB (void)??
In order for the form to be "designed" (Displayed really), a default
constructor must exist. I guess the reason for this is that the designer
can't come up with default values to pass to into the form, and so just gives
up.

Did you rename any of the namespaces, project name, or file names?? I've
had some issues with renaming some stuff and the compiler barfing on me from
it. Basically, for the project, there is a "Default Namespace" which (in
your case) has to be Config. When you go to compile the form, the compiler
takes the default namespace, then form name to name all the resources. IE,
if your the default namespace was test1, the resource file name for FormA
would be FormA.test1.resources. FormB would be looking for a file name of
FormA.Config.resources (You can see the slight diff), and formB would die in
loading...

If you still have problems, why don't you email what you have to fireangel1
AT comcast DOT net. Its my home account (i'm off the rest of the week)..

Hope it helps

GE
 
Vincent Finn said:
I know the answer to the question above is yes but my reason for
asking is that it doesn't seem to work properly

I have a manged C++ WinForms project
In it I have a form A, I want to derive a form B from it
Click to expand...

I've managed to derive from custom form after moving base class in a
separate assembly.
 
This is fireangel again, just at my work account..

The only other thing I can really think of is dealing with constructors. Do
you have any default constructors defined?? IE, FormA (void), FormB (void)??
In order for the form to be "designed" (Displayed really), a default
constructor must exist. I guess the reason for this is that the designer
can't come up with default values to pass to into the form, and so just gives
up.
Click to expand...

The default constructor is there
Did you rename any of the namespaces, project name, or file names?? I've
had some issues with renaming some stuff and the compiler barfing on me from
it. Basically, for the project, there is a "Default Namespace" which (in
your case) has to be Config. When you go to compile the form, the compiler
takes the default namespace, then form name to name all the resources. IE,
if your the default namespace was test1, the resource file name for FormA
would be FormA.test1.resources. FormB would be looking for a file name of
FormA.Config.resources (You can see the slight diff), and formB would die in
loading...
Click to expand...

I changed nothing except the base class

From a compile point of view it does work
It builds and runs and the inherited form display correctly
the problem is that i can't do anything with the form in the designer
If you still have problems, why don't you email what you have to fireangel1
AT comcast DOT net. Its my home account (i'm off the rest of the week)..
Click to expand...

Thanks.
I'll cut it into a smaller project and send it to you.

Vin
 
I've managed to derive from custom form after moving base class in a
separate assembly.
Click to expand...

That works for me too.
That is very odd, you'd think that it should be less likely to work
accross assemblies than in a single one!

Looks like a bug to me

Vin
 
I looked at your sample program, and the only way to get it to work is to use
diff namespaces. I'd say you definatally have a bug.

I went through all my projects that have multiple forms, and wouldn't you
know, everytime we had forms inherit, we had diff namespaces. What luck...

Sorry I couldn't help..

GE
 
I looked at your sample program, and the only way to get it to work is to use
diff namespaces. I'd say you definatally have a bug.

I went through all my projects that have multiple forms, and wouldn't you
know, everytime we had forms inherit, we had diff namespaces. What luck...

Sorry I couldn't help..
Click to expand...

Oh well, at least I know I amn't going mad
and I can use Vladimir's work-around messy as it is

Thanks, Vin
 
Back
Top