Page 1
Page 2
Page 3
The Document List View / Card Model
The "List View/ Card Model" is a
pattern where the main screen of the application is a list of
available items (files, contacts, records, etc.) that a user can
tap on to manipulate. When an item is selected a "Card"
is opened with the information from the file allowing the user
to update or view the information associated with the item. For
example, the main list of files found when running Pocket Word
is shown in Figure 1:
You'll notice there isn't a File menu to perform
open and save operations because these are implied by the tapping
and selecting "OK" on the item viewed. The guidelines
discourage developers from using a "File" menu at all.
This column will go through how I created
a file based list view for eVB applications. I wanted to match
the file listings found in Pocket Word, Notes, and other Pocket
PC applications so this technique does not use the common file
dialog control provided by Microsoft. Microsoft already includes
a very easy method for creating document lists when using eVC++.
You can create an application using the MFC appwizard and selecting
the appropriate template. You can learn all the gory details by
checking out CceDocListDocTemplate and CceDocList
in the help file. However, this is an eVB article and there
doesn't seem to be an easy way to take advantage of this class
from eVB (Note: if you know how to do it...let me know!). So,
let's build our own and learn a few tricks while doing so.
Before we get into the code and description,
I want to point out some of the requirements I defined before
jumping into the project:
- The final result should look as much like
the file view found in the built in applications.
- To simplify the design, our list will include
files of only one type. This is a simplification based on the
80/20 rule (80% of my applications have a single file type associated
with them). Since I'm adding this to applications with a defined
file type, I don't really need to handle multiple extensions.
This allows us to avoid handling graphics, extensions, and sorting
for different types of documents.
- The list must include all files within
the "my documents" hierarchy and we need a folder
dropdown menu that allows us to select individual folders.
- The list must have the ability to be sorted
by name, date, and size.
- The date format should be identical to
the lists found in the built-in applications. That means showing
only "mm/dd/yy" for most dates, and the "hh:mm"
with an "a" or "p" when the file is from
today.
There were a couple of things I do not have
in my file list view. One, I did not define how to support multiple
levels of directories below the "My Documents" folder.
In other words, I can list all the files found in "My Documents"
and it's children, but I didn't bother to go (recurse) into any
of the sub-folders and do the same thing. I don't feel this is
much of a limitation, since the casual user would have to jump
through a few hoops (and use "file explorer") to get
a deeper set of folders. I also do not use any graphics, so feel
free to add the folder icons if desired. Finally, I have not implemented
any of the directory management functions normally found in the
directory dropdown list.
Let the Games Begin
Figure 2 shows my version of a file
list view for an application. The initial view lists all the files
that match an extension we've defined in the application. Now
would be a good time to download the source and try the application
out. There isn't enough space to fully reproduce the technique
to create the form or all the code, so you'll find it much easier
to follow along if you download
the code.
The application (really a framework waiting
for a real application) consists of the list view form and a basic
module with the support functions for formatting and populating
the file list. Our form includes a list view control to hold the
files, two list boxes for the directories and sorting (normally
hidden when not in use) and some command buttons to activate the
lists as needed. I did not use drop down controls because their
look is pretty much fixed and I wanted to provide the ability
to manipulate the file lists as much as desired for look and feel.
Previous Page
Next Page