Wednesday, September 24, 2003

More Compact Framework Thoughts Wow!  Two posts in one day.  Considering the dearth of posts from this blog lately that is pretty amazing. After my earlier rant I remember something I brought up with the CF team at Microsoft. When I have heard the limitations of CF described in the past by MS folks it has been in the context of, "We are running on smaller, memory constrained devices so we built a smaller version of the framework that fits in just 2 MB."  That is all well and good but I am starting to do work for Windows CE based devices with 128MB and 256MB and I really want the full power of the framework.  While it is impressive that they were able to compress the amount of goodness that they did into 2 MB but what about developers for which there is abundant memory available?  Why didn't the team take more of a factored approach such that if I was willing to give them another 2MB I could get remoting or <insert your favorite dropped feature here>? This really brings to life the promise of only needing to know how to develop for one platform, .NET.  I don't need to know a long laundry list of limitations of things that I can't do on WindowsCE.  Instead I have to be willing to step up and trade RAM for features.  I know, I know not all features will be available on WindowsCE because of limitations of the OS.  I am fine with that.  The list of things removed due to OS limitations is going to be much shorter than the current list of things that were removed.  IOW the delta between desktop and compact will narrow but not necessarily close the gap. 10:26:51 AM

Compact Framework Rant I admit it.  I have been doing a considerable amount of Compact Framework programming over the last couple of months. First off let me say I think Compact Framework hold great potential.  That being said I think it has a long way to go. I recently build two applications using the compact framework.  One was a kiosk style application that had to communicate with other controller programs running on the kiosk.  This communication ended up happening using windows messages.  Luckily the MessageWindow class provides a way to receive messages however it is the only hWnd exposed so the applications I was communicating with had to do a FindWindow() on my forms to find their hWnds.  Ridiculous considering the hWnd is exposed off each windows form in the desktop framework.  Next problem we hit was that come to find out Windows CE has a 32MB process size limit!  Of course we were precaching a number of graphics, etc and even attempting to play video which meant that we hit this limit pretty quickly.  In a day when devices had 2-4 MB on average a 32MB process limit probably made sense.  Today however is it ridiculously small.  Next roadblock.  We needed to play animated GIFs.  They play in PocketIE so we figured no problem.  Wrong!  The animated gif support was ripped from the bitmap class in Compact Framework!  This of course meant that we needed to write our own animated GIF class.  Things were going fine until we were handling the dispose types for an animated GIF and realized that the lack of a way to XOR bitmaps was going to make the process very, very difficult.  Granted this is a limitation in the desktop framework as well as the compact framework.  Argghh! Next we move on over to writing a PocketPC application where things go a bit smoother but we still find some frustrations.  It is intended to be a wireless application used as a specialized tool for a customer service person.  Sort of like the folks you see at the Hertz car rental places.  It talks to a backend database as well as a wireless 802.11b printer.  Of course the middle tier that is in place uses remoting which, you guessed it, the compact framework lacks.  So we wrapped access to the remoted interface with a web service.  Things are going along well once we get around this roadblock, until we test on the actual device.  We realize that we have written an application that has no way to bring up the SIP (soft input panel) on the device. Not a problem we say.  We can just place the SIP control on our form and use it to display the SIP.  Whoa!  We don't have a menu bar on our form and for some bizzarro reason the SIP will only work on forms with a menu bar!  So we figure out how to make the API call and draw a few lines to show a fully functional SIP on our form. If you are interested here is how you show the SIP:   [System.Runtime.InteropServices.DllImport("coredll.dll")]   private static extern bool SipShowIM(int dwFlag); To show it:     SipShowIM(1); To hide it:     SipShowIM(0); There is a bottom line missing on the SIP since it counts on the menu bar to draw it.  So add a: e.Graphics.DrawLine(new Pen(Color.Black), 0, 294, 240, 294); In the forms paint when the SIP is showing and you are all set. 8:39:37 AM