Where to start?

I've got VS2005 and a Dell Axim X51 running Windows Mobile 5.0. I want to start off by creating a simple HelloWorld application and deploy it to hand held. What do I need to do to get up and running with compact framework development in VS2005?

What version of VS do you have? I think Express won't do, but pretty much anything else will. Just start a Mobile App project. Looks like it is now on the Smart Device node in the new project treeview.

I would guess that you use the emulator by default, but since you have some hardware, you should change that over, as the emulator, while fairly reliable, is not as true to life as a true device would be.

The key to mobile apps, in my opinion, is not using more than one form. Since you already have experience with desktop apps, and the language, you will find mobile dev pretty similar. There are less controls, and other things have been removed, which means that you sometimes have to be a bit more creative, such as layering controls on controls to get different effects. For example, you might want to use buttons rather than radio buttons for alternatives, just because buttons are bigger, and easier to hit with your fingers. Unfortunately, you can't change the backcolor on a button in mobile, so you can't have one set to one color, and another set to another color. However, buttons also are not 3D, so if you use a panel instead (which has a backcolor property, and responds to click events), you can accomplish the same thing.

The issue with forms is that they take noticeable time to load. Therefore, I always advise people to use a single form with a bunch of panels. Swapping panels into and out of the viewable area by altering their Top property is instantaneous and looks like forms to the user. Then all you have to decide is what controls to put on each panel, and how to transition from one panel to the next.

Great advice on the single form with panels.

I got it from a book, so I'm not taking any credit, but once you see how slow forms are in a mobile app, you'll understand why this is a really critical concept. Once a form has been loaded into memory, then it's quick, so loading a bunch of forms at startup is a viable option, but since they have noticeable load times, they are painful during a program run.

Hey Shaggy, just curious, is there a reason you use the panels and not a tab control? Thanks.

Hi,
answering on shaggys' behalf, panels are invisible and you can just move them to where you want, and it appears that it is a new screen, and more importantly, you are in charge. You can have several panels on a form, and make it look like several forms using this method.

With a tab control, you have the tab buttons at the bottom, which puts the user in charge.

Pete

Tabs can be turned off, can't they? A tab might actually be easier at design time since you can easily select a particular tab to work on. At run time, just hide the tab buttons.

The only issue I know of with panels is that once you get so many that they don't all fit on the screen, they can become a bit of a chore to manage visually. This isn't an issue in code, because you just use regions to separate the code for the various panels.

I haven't tried tab controls. If you can make them utterly invisible to the user, and get the sizing right, then they should work fine for this. However, panels are sort of the "core" control for mobile dev, and you should be familiar with their features. The fact that they are the one control I know of that still has a backcolor property, and also that they are invisible regions that respond to click events, means that they can fill in for many different types of controls that have been left out of the Compact Framework, such as multi-select listboxes, colored buttons, funky labels, etc. Therefore, I would tend to reach for a panel rather than figure out what other types of controls I could use. However, panels do get to be problematic once you have a whole lot of them, so if you can get the right features from a tab control, then go for it. You need it to be totally invisible, sizeable to the full screen size, colorable (that one's optional, but I use it plenty as an orientation cue for the user), and it has to be able to swap almost instantaneously.