Sharing Code between Window Forms and Windows Mobile

[Robert W.]

I'm embarking on a project that will have both a desktop application and a
Pocket PC application. It seems logical to have as much code as possible
sitting in a shared project, which would be referenced and utilized by both
the Windows Forms application and the Mobile Device application.

Are there any "gotchas" (ie. warnings) that anyone knows about in following
this approach?

Robert W.
Vancouver, BC

[Tim Wilson]

My suggestion would be to only share code that is non-UI related and if you
really want to share assemblies make sure that the code conforms to the
lowest common denominator by compiling against the Compact Framework.

--
Tim Wilson
..Net Compact Framework MVP

"Robert W." <Ro*****@discus sions.microsoft .com> wrote in message
news:26******** *************** ***********@mic rosoft.com...

I'm embarking on a project that will have both a desktop application and a
Pocket PC application. It seems logical to have as much code as possible
sitting in a shared project, which would be referenced and utilized by both the Windows Forms application and the Mobile Device application.

Are there any "gotchas" (ie. warnings) that anyone knows about in following this approach?

Robert W.
Vancouver, BC

[Robert W.]

Hi Tim,

Thanks for this. Have you personally run into problems sharing code as I
described?

I also immediately thought about avoiding sharing code that involves
controls. But today I noticed that both a Windows.Forms form and a Mobile
Device form each have the identical 'using' statement at the top:

using System.Windows. Forms;

It'll be interesting to see if a DataLibrary with the above 'using'
statement would support code as follows for both platforms:

private void GetAllControls( Control.Control Collection parent, ArrayList
container)
{
foreach(Control c in parent)
{
if(c.HasChildre n)
{
GetAllControls( c.Controls,cont ainer);
}
container.Add(c );
}
}
I definitely need to do some tests, but added my post on here to tap into
the experiences of others who have tried this.

Robert


"Tim Wilson" wrote:

My suggestion would be to only share code that is non-UI related and if you
really want to share assemblies make sure that the code conforms to the
lowest common denominator by compiling against the Compact Framework.

--
Tim Wilson
..Net Compact Framework MVP

"Robert W." <Ro*****@discus sions.microsoft .com> wrote in message
news:26******** *************** ***********@mic rosoft.com...

I'm embarking on a project that will have both a desktop application and a
Pocket PC application. It seems logical to have as much code as possible
sitting in a shared project, which would be referenced and utilized by

both

the Windows Forms application and the Mobile Device application.

Are there any "gotchas" (ie. warnings) that anyone knows about in

following

this approach?

Robert W.
Vancouver, BC

[Tim Wilson]

> Have you personally run into problems sharing code

as I described? No. But then again I haven't really had a whole lot of need to do this.

The CF (Compact Framework) team modeled the namespaces, classes, etc. to
mimic the FF (Full Framework). So you'll notice lots of similarities between
the FF and CF. This was absolutely by design. This allows devs to leverage
their knowledge between the two frameworks. But keep in mind that the CF
emphasizes the word "compact". So the CF is a subset of the FF. If you look
at the documentation you'll notice the statement "supported by the .NET
Compact Framework" on certain members (now I must warn you that the docs are
not 100% accurate, particularly with the event members). This gives you an
idea of what you can and cannot use between CF and FF. So in your code
example, the "HasChildre n" property would not compile against the CF since
it's not supported. But you could always just check the Count of the
Controls collection. So there are usually work arounds. You'll just need to
find the combination that works for both the CF and FF and then compile that
in a project against the CF.

The reason that I implied that it's best not to share UI related code is
mostly for two reasons:
(1) The form factor of a device (like a Pocket PC or Smartphone) is
drastically different from a typical desktop computer display. So the UI is
pretty much a rewrite anyways.
(2) Through the designer, the generated resx files for Forms are not
compatible between FF and CF projects.

So there's nothing wrong with having utility methods to perform tasks on
controls, but you'll want to ensure that you have different projects, one
for the FF and one for the CF, so that you can more easily define proper
UI's.

--
Tim Wilson
..Net Compact Framework MVP

"Robert W." <Ro*****@discus sions.microsoft .com> wrote in message
news:C3******** *************** ***********@mic rosoft.com... Hi Tim,

Thanks for this. Have you personally run into problems sharing code as I
described?

I also immediately thought about avoiding sharing code that involves
controls. But today I noticed that both a Windows.Forms form and a Mobile
Device form each have the identical 'using' statement at the top:

using System.Windows. Forms;

It'll be interesting to see if a DataLibrary with the above 'using'
statement would support code as follows for both platforms:

private void GetAllControls( Control.Control Collection parent, ArrayList
container)
{
foreach(Control c in parent)
{
if(c.HasChildre n)
{
GetAllControls( c.Controls,cont ainer);
}
container.Add(c );
}
}
I definitely need to do some tests, but added my post on here to tap into
the experiences of others who have tried this.

Robert


"Tim Wilson" wrote:

My suggestion would be to only share code that is non-UI related and if you really want to share assemblies make sure that the code conforms to the
lowest common denominator by compiling against the Compact Framework.

--
Tim Wilson
..Net Compact Framework MVP

"Robert W." <Ro*****@discus sions.microsoft .com> wrote in message
news:26******** *************** ***********@mic rosoft.com...

I'm embarking on a project that will have both a desktop application and a Pocket PC application. It seems logical to have as much code as possible sitting in a shared project, which would be referenced and utilized by

both

the Windows Forms application and the Mobile Device application.

Are there any "gotchas" (ie. warnings) that anyone knows about in

following

this approach?

Robert W.
Vancouver, BC