Porting woes - what to do about the PropertySheet?

Much as we try to reduce the differences between the Pocket PC and Smartphone, there are still some things that are unique to each of these flavors of Windows Mobile from a developer’s perspective. These differences cause problems when porting a Pocket PC application to Smartphone, or maintaining a single binary that runs on both devices.

One of these lingering differences is the PropertySheet control. Although you can technically use a PropertySheet in a Smartphone application, it is best suited for touch-enabled Pocket PC devices due to various usability issues. It is against our design guidelines to use PropertySheet controls in a Smartphone application and therefore you won't find any of the built-in applications use them. So how do you port a Pocket PC application to Smartphone when it has a user interface (UI) like this:

There are a couple of options I can think of, each with its own advantages and tradeoffs:

If you have several pages in your PropertySheet (3 or more) with many controls on each page, create a UI like this (with or without the numeric shortcuts):

You may have noticed many of our Smartphone applications including the settings dialog work this way. This allows you to keep each group of controls in its own dialog and thus gives you PropertySheet-like logical separation. This may also be ideal if the controls are related with complex validation rules so the code can be kept in separate dialogs.

One disadvantage of this option is that there is no built-in ListBox that gives you the numeric shortcut functionality. I remember seeing some sample source code to accomplish this but can't locate it anymore (please point it out if you have a link).

If you have fewer pages, you can simply combine all the controls into a single dialog like this:

This removes the logical separation, but is very easy to implement. It simplifies your user interface since there is a single parent window instead of multiple property pages to manage. It's even easier because Smartphone dialogs give you automatic scrolling when there are more controls than can fit in a viewable area. At design time, you can simply drop your controls on a dialog resource, add the WS_VSCROLL style, and you get automatic vertical scrolling without writing any additional code.

Given these tradeoffs, which option should you use for long term application compatibility? I don't have a good answer at this time, but I'd like to pose this question back to you, our developer customers. As you might have heard, our goal is to eventually unify Pocket PC and Smartphone into a single Windows Mobile platform. As a result of this unification, some controls may be removed or modified if they cannot be supported on all Windows Mobile devices (touch and non-touch enabled). We haven't made a decision about the PropertySheet control yet but it's one of the things we have to consider.

We want to hear from you about how extensively you use the PropertySheet control, what you feel about the above options and if you have any alternate suggestions.

-Mel Sampat

Comments

• Anonymous
  February 17, 2007
  One solution might be to put the tabs at the top of the dialog so that the focus is logically first on them, which would allow smartphone users to use their D-pad to move across them before moving down to the options. When you reach the bottom of the list of options, it would also help for focus to cycle back to the tab row at top. Since new smartphones seem to be mostly landscape screens, there should be sufficient space horizontally to show a good number of tab. If not, they should scroll. And tabs could be automatically numbered for direct access with the number keys.

• Anonymous
  February 17, 2007
  Ryan's comment is excellent. Numberi the tabs would make them really accessible. Also they can be used really well with only D-pad on pocket pc.  Skype is a good example of an application using tabs successfully on smartphone. I would hate giving up the power of the pocket pc for unifying the platform, though I do support this. Regards,

• Anonymous
  February 18, 2007
  The comment has been removed

• Anonymous
  February 19, 2007
  Given the smaller screen of the SP, aka 'Standard', Windows Mobile devices, having a way for grouping information can be even more important than on the Pocket PC. Some other smartphone OS, like Nokia, have tabbed controls.

• Anonymous
  March 02, 2007
  The comment has been removed

• Anonymous
  March 05, 2007
  I agree you need to work out to keep them.  They work great on my Nokia.  I see no reason they wouldn't work for CE.

• Anonymous
  April 26, 2007
  Since the numbered list with tabs names briging to individual dialogs seems like the natural counterpart of the property sheets on non-touch devices, why not changing this at the API level? I mean, the behaviour could be changed on the Smartphone platform so that the PropertySheet functions use the list of propsheetpages and display them as a numbered list and, when selected, show the individual propsheet page fullscreen over the list, managing the softkeys to control ok/cancel, sending PSN_APPLY to the page accordingly, and go back to the list. Of course this means more work on your side to modify the property sheet APIs for that platform, but it would make the platform much easier to target as we move forward to a single platform for touch and non-touch devices. It would also make it easier to have a single binary for all platforms without making it larger by containing both versions of the code, while maintining each flavor's benefits and avoids each developer coding his own numbered list. In turn, this would leads to a better user experience because applications would use the best UI on both more easily, and because there is no risk of the Smartphone/Standard platform getting less applications because of the extra work involved in writing special code for its differences.

• Anonymous
  June 18, 2007
  The comment has been removed