|
In PocketPC (all versions) and the Pocket PC ancestor
(Palm-Sized PC) the standard file open/save dialogs are designed in
a way inspired by the Palm OS. Perhaps some people in Microsoft
already regret this, but it is a fact and we need to cope with it.
FILE OPEN DIALOG
So, the file open dialog (unlike in the desktop and full CE
version) is more like a filtered search and not a single directory
view. Thus you have a directory filter, and file type filter (in
open file) and a list of files.
The file list contains all the files with the selected file
extension in a 1-level directory on all the storage devices. Note
that for the internal storage the dialog uses "My
Documents" as a root directory and not the device root
directory. Thus from the FILE OPEN dialog perspective you have these
storage devices:
\My Documents
\Memory Card1
\Memory Card2
... etc ...
Of course the names of the memory cards varies from device to
device.
The dialog can show files only in these locations and in 1-st
level subdirectories in them. As the directory
combo box (by itself) specifies a filter and not a complete location
it may contain only a name and not a full path. Thus
NSBComDlg1.InitDir = "\Some card\somedir"
is invalid and will be
ignored or may cause strange results on some versions of the OS, but
NSBComDlg1.InitDir = "somedir"
is valid and will initialize the directory filter with "somedir"
and the files in
\My Documents\somedir
\Memory card1\somedir
... etc ..
will be listed. Of course that directory should exist in one or
more of these locations.
FILE SAVE DIALOG
In this dialog there are 3 filters:
1. Folder (directory)
2 .File type
3. Location (meaning in fact storage card/device)
InitDir is of no use here, it is even treated a bit incorrectly
by the system. Thus you should use FileName property to initialize
the dialog:
NSComDlg1.FileName = "\Storage device\Directory\filename.ext"
or
NSComDlg1.FileName = "\My Documents\\filename.ext"
or
NSComDlg1.FileName = "\Storage device\filename.ext"
I.e. you must specify a full path name. The file name at the end
may be whatever you want - treat it as a proposed file name for
example.
You cannot omit any of the path parts without risking strange
behavior on some Pocket PC OS versions. Furthermore on some
occasions the system gets confused if the proposed file name is only
one character long - so propose a descriptive file name to the user
when OpenSave is invoked and no prior save operation has been
performed (from which you may keep the last name under which the
file has been saved).
The IsPocketPC property.
The NSComDlg object provides a property named IsPocketPC which
returns True if the platform on which the application runs is a
Pocket PC. Using it you can implement different behavior for Pocket
PC and other platforms thus making the code reusable regardless of
the platform. The only other way is to use only the FileName
property for initialization and specify full path name in it. In
this case only the Open file dialog on Pocket PC will not initialize
with any specific directory which seems to be the acceptable
sacrifice if the aim is single code to serve all the platforms.
CONCLUSION
The NSBASIC Common Dialogs control makes use of the system
provided standard dialog boxes and does not implement them.
Therefore it reflects the system behavior and all the mentioned
specifics are the same no matter how you use the corresponding
dialogs - from NSBasic or from C for example.
Unfortunately the limitations of the File open/save dialogs on
Pocket PC make it nearly impossible to use the same code as on a
desktop or on a full scale Windows CE device (such as HPC or a
tablet). An implementation of own file dialogs has been considered,
but there are two reasons to provide this control in this
form:
1. The Pocket PC users are already familiar with this
behavior which is also exerted by some alternative dialog
implementations from Microsoft (for instance applications built
using MFC use file view with similar limitations - see pocket word
and excel for example). Therefore, no matter how you feel about
these dialogs they are already a standard and the applications
designed for regular users should use them to keep the user within
the realm he/she already knows.
2. The control provides almost the same methods
and properties as the former Microsoft Common Dialogs control thus
making applications porting easier.
Any other implementation we may provide in future
will be alternative choice, but not a replacement for this control
(because of the above reasons).
|