Design a form on your Pocket PC:
Then use it to capture data to an XML file database:
Introduction
FishForm is a complete application for designing forms and using them to capture data in the field on a Pocket PC with the .NET Compact Framework.
I wanted to do an article for the Compact Framework competition and was stumped for ideas. I was surfing the net and came across a news story about how organizations in Africa are using Pocket PC's in villages to take medical surveys because the Pocket PC is more portable and, more importantly, cheaper than a note book computer.
I looked around at some of the commercial software out there to make surveys for Pocket PC's and found that they all had one thing in common: you had to have a desktop PC to design the surveys and forms. This meant that you could not create an ad-hoc survey in the field but would always have to return to the "office" first.
FishForm allows you to create data entry forms right on the Pocket PC itself and then in the same program you can use those forms to enter data which is saved to a standard XML file for later integration into a larger database application.
While it may be used for surveys, I think it would also be very useful for any general purpose where you need to gather data outside of an office. For example, equipment condition checks, restaurant critiques, you name it.
I've learned *many* useful things about programming on the compact framework while working on this project and I hope to illustrate what it takes to make a complete application in this restrictive medium while sticking to the confines of the .net framework as much as possible. In other words I could have probably done things a bit faster and easier by bypassing the compact framework and using p/Invoke to call native windows functions much more than I have but I limited that to only where absolutely necessary as the spirit of this article is to show how to do it the .net way as much as possible.
Going into this I had some definite ideas of what I wanted my application to accomplish and look and feel like and how it would operate but very little knowledge of the .net compact framework. In the end it was all about compromise and very little about how I wanted things to work.
I've spent a lot of time working on this article because our company is going to be making a Pocket PC interface for one of our apps and I decided a complete application would be the best way to learn it end to end in case there were any surprises. I've probably re-written every class in it from scratch at least twice at this point and spent a good many hours each day that I worked on it searching all over the internet looking for workarounds or ways to accomplish things that I have come to take for granted on the regular .net framework.
If you look into the source code I've commented liberally where I've had to make compromises or where things don't operate as expected.
Features of the program
- ActiveSync integrated installation and removal program. (Install from PC, or Pocket PC directly)
- Follows Microsoft Logo guidelines (with standard exemptions for .net compact framework of course)
- Integrated html help with tutorials
- Useful to anyone who wants to capture data in the field into a database.
- The help files illustrate importing the captured data into a Microsoft Access database for reporting and analysis purposes.
Features of the source code
Articles by their nature are normally a very limited example of how to do something. This is normally excellent and can get you going in the right direction, but sometimes it's just as useful to have a complete end-to-end working application that you can take apart and pull out what you find useful and see how it works in practice, not in a made up example. I hope that my source code will be useful in this way. I've commented it liberally wherever anything was complex or interesting and taken care to use meaningful method and field names wherever possible.
There are too many useful things to learn from a complete application to be mentioned here, but some of the high points are:
- Custom control - Design component based on "Control". Selectable, draggable, responds to clicks, can look like a checkbox, radio button, combo box, single line edit box, multi-line edit box or label. Anyone interested in learning how to make their own custom control that does more than look pretty and is actually useful should find something of interest in the source code.
- Soft input panel and scrolling forms - most articles I've seen show how to use one or the other, but not both and that is really what's necessary. The SIP article most people first read from MS assumes that you can afford to simply eradicate 80 pixels of your form by not putting anything at the bottom, in the real world this is a terrible compromise as you end up wasting a third of your screen space all the time. The main data entry form illustrates a way to accommodate the SIP by auto-enabling it when an text box gets the focus, showing a scroll bar and turning the form into a scrollable form automatically so that nothing gets obscured and the process is natural for the user.
- XML files - all user created forms and data entered are stored in XML files that are standards compliant. I had never had any reason to do this previously and there were a lot of complicated examples out there that didn't really get the point across. Hopefully the source code here is much more straightforward to anyone interested in learning how to do the same.
- Installer - While mostly taken from the example that can be found here on this site and at GotDotNet.com, it differs in that it actually works and is a complete example. While this installer isn't earth shattering in any way, it's a fully working end to end example which is important because many of the articles that show how to do this are not complete and contain in fact some bugs. For more details on writing an installer setup for .netCF see the article here on CodeProject
- Help system - While .net compact framework applications are exempted from the regular logo requirements for a help system, that doesn't mean you don't need to make one. I've illustrated a method for calling into an external HTML file to display context help.
Top tips for writing your own .net application
Do read the logo requirements from Microsoft before you even start planning your application.
Do read the .net compact framework development frequently asked questions page
Do not assume that every class you're used to using in the regular .net framework will work the same way in the compact framework. They are all much more limited. For example, look at this documentation page on the Label class members. Note that each member specifically states whether it's supported by the .net compact framework or not and in this case none! of the events of a label are supported in the compact framework. Every component has limitations, be sure to check them out first.
Do read up on using p/invoke to call native Windows functions, in many cases it will be the only way to accomplish certain tasks. A useful article can be found here .
Do NOT assume that if it works on the emulator it will work the same way on the actual device. This is absolutely not true and there are tremendous differences between the two. One example: on the emulator you can always reliably tell where the user clicked to invoke a popup menu. This same code fails to work properly on the real device and seems to be a semi acknowledged bug. Time after time I found differences between the emulator and my V37 Pocket PC. So many that I can only recommend that if you are writing a serious application there is no substitute for having a real device to test on at every stage. I wrote a *lot* of code assuming the emulator would be good enough only to find that I had to throw a lot of it out and start over again when I first decided to test on the real device.
Do be aware of the OpenNetCF Smart Device Framework : "The Smart Device Framework enriches and extends the .NET Compact Framework by providing a rich set of classes and controls not available in the .NET Compact Framework." I avoided using it for this project because I wanted to stick as much as possible to the standard framework, but if I was developing a commercial application I would take a serious look at this because it fills in all the little areas that are missing from the standard compact framework.
What you need to change to compile the project on your computer
Before you build the solution, you need to make manual changes in two files in the "BuildCab" folder to indicate the path that you have unzipped the project folder to.
On my development system the project folder was in "C:\data\projects\FishForm\".
- FishForm\BuildCab\BuildCab.bat - change the two occurrences of the above path to your local path for the project folder
- FishForm_PPC.inf - change the token in the [Strings] section called "WHERE_I_PUT_THE_FISHFORM_PROJECT_FOLDER" to point to your local path for the project folder.
That's it! You should be able to do a rebuild all now in Visual Studio for a complete build of program and setup files.
History
- Version 1.0 - May 19th, 2004
