|
Compact Framework Rant
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.
Wednesday, September 24, 2003 12:39:37 AM (Pacific Standard Time, UTC-08:00)
|