Main form and partial class

I've got a large form with a tabbed interface, and decided
to separate
out some functionality into separate files so that a few of
us can
work on the form at the same time.  Perfect use of the
partial class
feature, no?

So, I do so.  imagebuttons.cs scannerbuttons.cs tabpage1.cs
tabpage2.cs and so on..

In the Solution Explorer, each of these files shows up as a
form.  If
you double click on one, you end up in a form designer. As
far as I
can tell, if you don't put a control, or create an event
handler in
these forms, you shouldn't have a problem.

But if you do ANYTHING to one of these forms, the designer
puts an
InitializeComponent routine in the file and when you try to
build,
Visual Studio will complain,

"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Mi
crosoft.CSharp.targets(147,9):
error MSB3105: The item
"obj\Debug\PartialClassPlay.Form1.resources"
was specified more than once in the "Resources"
parameter.  Duplicate
items are not supported by the "Resources"
parameter.

Turns out, the designer also creates a .resx file for that
partial
class file.  Delete that, delete the InitializeComponent
routine, and
delete anything else the designer put in the partial class
file and
everything is back to normal.

So, is there anything I can do to prevent this from
happening in the
first place?  Or is this just the effect of an incomplete
implementation of partial classes in the designer (i.e. it
doesn't
check if it already has a designable form in one of the
class files,
so it makes a new one anyway)?

I've had the same problem and no, I don't think you can do
anything about
it.
I think if you do that, you will still have to have the
constructors and
InitializeComponent() method in the "main"
partial class.
The other partial classes can have their specific code.


On 7/31/06, Roy Green <roygreengmail.com> wrote:
>
> I've got a large form with a tabbed interface, and
decided to separate
> out some functionality into separate files so that a
few of us can
> work on the form at the same time.  Perfect use of the
partial class
> feature, no?
>
> So, I do so.  imagebuttons.cs scannerbuttons.cs
tabpage1.cs
> tabpage2.cs and so on..
>
> In the Solution Explorer, each of these files shows up
as a form.  If
> you double click on one, you end up in a form designer.
As far as I
> can tell, if you don't put a control, or create an
event handler in
> these forms, you shouldn't have a problem.
>
> But if you do ANYTHING to one of these forms, the
designer puts an
> InitializeComponent routine in the file and when you
try to build,
> Visual Studio will complain,
>
>
>
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Mi
crosoft.CSharp.targets(147,9):
> error MSB3105: The item
"obj\Debug\PartialClassPlay.Form1.resources"
> was specified more than once in the
"Resources" parameter.  Duplicate
> items are not supported by the "Resources"
parameter.
>
> Turns out, the designer also creates a .resx file for
that partial
> class file.  Delete that, delete the
InitializeComponent routine, and
> delete anything else the designer put in the partial
class file and
> everything is back to normal.
>
> So, is there anything I can do to prevent this from
happening in the
> first place?  Or is this just the effect of an
incomplete
> implementation of partial classes in the designer (i.e.
it doesn't
> check if it already has a designable form in one of the
class files,
> so it makes a new one anyway)?
>

Did you consider splitting it up into UserControls? One
UserControl for
each tab page.

That's a pretty straightforward way of splitting the thing
up into
multiple pieces. And it's a much more manageable technique
than trying
to cram it all into one class. (Even if you have split it
across
multiple files, one huge class seems pretty unmanageable to
me. I've
always split my tab pages up into UserControls .) Even if
you could get
this use of partial classes to work, I'd regard it as a
much less
pleasant solution than splitting the UI up into one class
per page.

And I suspect you won't get the partial class approach to
work. Visual
Studio expects to be working with just one
InitializeComponent method
per design surface. So even if you split your code across
multiple
files, the designer-generated code is all still going to
have to be
inside of one file for the simple reason that the generated
code all
needs to be inside a single method.

What exactly are you expecting it to do? Either it has to
put all the
designer generated code into a single generated file, in
which case you
don't get the benefit you're looking for - developers
can't work
independently on the same UI. (Unless you have a source
control system
that supports concurrent work with merging, in which case
you're already
good to go - you don't need to split things up at all in
that case.) Or
it'd need to somehow create an equivalent of
InitializeComponent for
each individual code-behind file, but it'd need to give
them all
different names as they're all part of the same class, and
it'd need to
arrange for them all to be called at once.

I guess they could have supported this scenario if they
wanted to. But
it's something that would have required explicit extra
support, and
probably quite a lot of work as it's fairly big change in
how the
designer works. And all to support development of classes
that are quite
clearly too big and complex to be manageable, and that are
ripe for
splitting up into pieces. Since they don't support this, I
suspect
there's no way you're going to be able to coerce the
designer into doing
it as it stands.

Basically, the Windows Forms designer is a *client* of the
partial
classes feature. Partial classes were added to C# and VB.NET
in order to
make the designer system's life easier, not more complex.

You basically want to use partial classes in a way that is
different
from how the designer wants to use them. A perfect use of
partial
classes? I think that depends on how you happen to like to
structure
your code. (I happen to dislike great big classes, so I
wouldn't want to
do it that way.) But the problem is that it's a *different*
use of
partial classes from the way the designer wants to use
partial classes.
So sure, you can do it, but you'll have to live without the
Windows
Forms designer, which is a rather hefty price to pay.


If you want multiple independently designable chunks of UI,
you need to
split it up into multiple design surfaces. Making each tab
page a
UserControl is a way to do that.


-- 
Ian Griffiths
http://www.int
eract-sw.co.uk/iangblog/ 

> -----Original Message-----
> From: Roy Green
> Sent: 31 July 2006 21:34
> To: DOTNET-WINFORMSDISCUSS.DEVELOP.COM
> Subject: [DOTNET-WINFORMS] Main form and partial class
> 
> I've got a large form with a tabbed interface, and
decided to separate
> out some functionality into separate files so that a
few of us can
> work on the form at the same time.  Perfect use of the
partial class
> feature, no?
> 
> So, I do so.  imagebuttons.cs scannerbuttons.cs
tabpage1.cs
> tabpage2.cs and so on..
> 
> In the Solution Explorer, each of these files shows up
as a form.  If
> you double click on one, you end up in a form designer.
As far as I
> can tell, if you don't put a control, or create an
event handler in
> these forms, you shouldn't have a problem.
> 
> But if you do ANYTHING to one of these forms, the
designer puts an
> InitializeComponent routine in the file and when you
try to build,
> Visual Studio will complain,
> 
>
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Mi
crosoft.CSharp.targets(
14
> 7,9):
> error MSB3105: The item
"obj\Debug\PartialClassPlay.Form1.resources"
> was specified more than once in the
"Resources" parameter.  Duplicate
> items are not supported by the "Resources"
parameter.
> 
> Turns out, the designer also creates a .resx file for
that partial
> class file.  Delete that, delete the
InitializeComponent routine, and
> delete anything else the designer put in the partial
class file and
> everything is back to normal.
> 
> So, is there anything I can do to prevent this from
happening in the
> first place?  Or is this just the effect of an
incomplete
> implementation of partial classes in the designer (i.e.
it doesn't
> check if it already has a designable form in one of the
class files,
> so it makes a new one anyway)?

Ian suggests:
> Did you consider splitting it up into UserControls?
> One UserControl for each tab page.

+1 for this technique. I've been doing this since VB5, and
it works very
well.

You can simplify the job of gluing them together (or
refactoring their UI,
for that matter) by having them each present a common
interface to the
container Form. Depending on the nature of the data being
shared between the
Form and the Pages, you could simply define an Interface
that each must
implement:
interface IJklPage
{
        void SetData( MyDataset myds );
        MyDataset GetData();
        bool Closeable();
        // maybe some events to signal changes
}

Or, if it's more complex, maybe define a base class JklPage
that implements
the plumbing necessary to communicate with the container,
and have each tab
Page inherit that implementation.