Conformation of Cross Platform ability

Jan 22, 2009 at 7:17 PM
I plan on using this controll on some Window Mobile (.Net Compact Framework 3.5 and 4.0 to be precise). How have you determined that your Control is indeed cross platform?

The only real definitave way is to develop the control as a Compact Framework Library (or is it Control - i forget) project type, the compiler is smart enough to know the target framework and will only present objects, properties, and methods that are available on CF.

If you develop the control this way you _know_ it is CF Compatabe, and because of assembly redirection (i cant remember its proper name, but the CLR will see that its a NETCF library and redrirect all calls to the Desktop .NET Framework) you can use the same code on the Desktop.

the only cavet is that you must not use any specific Mobile libraries or namespaces; and unless you are doing something very wierd you wont hit this problem.

if you have any problems or questions, email me OTL, I have done mobile development for years, and will be happy to help.
Jan 22, 2009 at 7:49 PM
Great idea! By cross platform i mean linux/macos with mono2 support. I'll try to see what i can to do with CF.
Jan 22, 2009 at 8:11 PM
sweet, keep me in the loop because at looking at the source code myself it doesnt seem to be a completely insurmountable obstacle to drop the code in a CF project and get it compiling
Jan 22, 2009 at 8:19 PM
What current parts of control doesn't build on CF? Is there some differences/limitations with the effect of uercontrol? Does CF support native dll functions import?
Jan 22, 2009 at 8:23 PM

Things notably missing from Windows Mobile version of GDI+ are:
Text support
World Transform support. In general transforms are only supported on a Path object
Many image operations.

Jan 22, 2009 at 8:44 PM
I havent attempted to build the control in cf just yet (I intend on doing this when I get home from work), I dont anticipate much that will fail, one ovious thing is threadding (cf doesnt implement a lot of 'higher level' thread sync objects).

as long as you are using System.Drawing (S.D) & System.Drawing.Imaging (S.D.I) and are not pinvoking graphics api's yourself (S.D & S.D.I wrap these api's iirc) then there may be not much of an issue.

to answer your questions, CF supports p/invoke, and a lot of image functions.

a while ago I had a go at writing a similar control for Live Maps, it worked fine, I got the basics working (creating a URL from a gps point, downloading a set of tiles, drawing them, navigating, zooming etc...). I used S.D & S.D.I to do this and had no issues.
Jan 22, 2009 at 9:22 PM
Its just occurred to me, how do you intend on supporting mono2 while you are doing a decent amount of DllImport (p/Invoke) as you cannot distribute gdi32 nor msimg32 (NativeMethods.cs) with your application. these are platform specific libraries that you are only ever going to find on the Windows platoform.

You seem to be using PInvoke mainly for graphics operations - please consider using what is available in System.Drawing | System.Drawing.Imaging - is there anything specific that these two namespaces dont do that you really need ?
Jan 23, 2009 at 5:30 AM
look at: MainMap.RenderMode = GMapRenderMode.GDI_PLUS;

GDI is just for for faster drawing only on windows.
Jan 24, 2009 at 11:05 PM ijust tested building on CF, and it's not so easy, a lot missing functions, need to redone some part.. I'l try to split logic & presentation in separate dll, maybe something can work then easyer..
Jan 25, 2009 at 2:04 AM
ok, so I have just dropped it in a cf project to see what happens and it does indeed look like there would need to be some major architectual changes to make this work.

nothing bad on your part, just 'high level things' like the background worker class dont exist on CF - to do the same thing you use a Thread.

anyhow, your project on Google Maps has freshed my taste for my own very similar project for Live Maps (nothing is released yet, its still on my hard-drive).

i do like the way you have done parts of your control, its quite simple which is always good. if the moons allign properly mabye we can join heads to port your control to CF
Jan 25, 2009 at 2:48 AM
background worker/EventWaitHandle is ported by

...i'll keep on 'major architectual changes' and if i can manage that with wpf, CF should work too
Dec 23, 2009 at 8:24 PM

on progress:

more info