Welcome to MSDN Blogs Sign in | Join | Help

MelSam's Blog

Mel Sampat on Windows Mobile
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:

Pocket PC screenshot

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.

Posted: Thursday, February 15, 2007 10:38 PM by MelSam

Comments

Daniel said:

We use the property sheet control for the settings in our PocketPC application. This is mostly because user's implicitly expect this layout because of the system using it as well for the global settings.

Switching to the first mentioned option will be unexpected for users and thus I am not fond of it. It really is only something suitable for a smartphone. The second option is okay if there are only a few entries, but scrolling more than one or maybe two pages will just make it hard to navigate for the user.

A third option may be to use a popup combobox which would have all the section names (former tabs). Upon the user changing the selection, the app could switch to another dialog (which has the same combobox). This should be possible to handle on SmartPhone and PocketPC and while not a usual approach on WM, it should be something users can recognize.

# February 16, 2007 12:04 PM

Ram said:

Hi

We are currently in process of port our application from PPC 6700 to Palm Treo 700WX. We have seen that our application abruptly exists.

Scenarios:

1) When navigating between different screens of the application

2) When navigating from the application to the TODAY of the Windows Moible.

3) We have also seen the application is initializing it just disappears.

4) We have also observed that there are 2 to 3 instances of the application memory.

5) We have also observed that application doesn't start when we click on the App Icon.

Dependent Software

1).NET CF 2.0 SP2

2)SQL CE 3.1

About the Application

1) Multi Threaded

2) Network connection based

Question.

1) Could you give some hints the behavior of the application that we observing? (Scenarios Described)

2) Do you of any issue of port the code or the guide line that need to be followed?

Thank you

Regards

Ram

r.rampraveen@otis.com

# June 19, 2007 3:03 AM

Lutz said:

I was porting my screenshot taking program (ScreenShotCE) from Pocket PC to Smartphone and had exactly this problem. I decided on option 2.  However I noticed that the dialog does not work reliably when scrolling is involved. Controls at the bottom of the page tend not to activate properly even though they are in the tab list. I think you have to add a dummy control to the very bottom of the page or something to make this work reliably.

# August 20, 2007 5:07 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker