128 lines
3.3 KiB
Plaintext
128 lines
3.3 KiB
Plaintext
|
|
||
|
|
|
||
|
|
NT User Interface
|
||
|
|
Design Overview
|
||
|
|
N-Level Outline Listbox
|
||
|
|
Kevin LaChapelle (KevinL)
|
||
|
|
Revision 0.5 10/06/91
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
1. SCOPE
|
||
|
|
|
||
|
|
This document provides a general design overview of the N-Level
|
||
|
|
Outline listbox design.
|
||
|
|
|
||
|
|
2. REFERENCES
|
||
|
|
|
||
|
|
BLT Specification
|
||
|
|
|
||
|
|
3. OVERVIEW
|
||
|
|
|
||
|
|
The current design for the OLB does not contain a data structure
|
||
|
|
other than that of the underlying windows listbox. This has
|
||
|
|
proven to be inadequate for a n-level implementation for several
|
||
|
|
reasons that are not discussed here. The key area that needed
|
||
|
|
improvement was how to insert an element into the listbox and have it
|
||
|
|
placed in the proper location. The reason that this has proven
|
||
|
|
difficult is because it is possible for elements to have identical
|
||
|
|
"parent" values. (In the case of Multiple networks the server/domain
|
||
|
|
names can be identical across domains).
|
||
|
|
|
||
|
|
The solution to this problem is to have an underlying data
|
||
|
|
structure that takes the form of a tree. Specifically one that has
|
||
|
|
the following structure:
|
||
|
|
|
||
|
|
LBI * plbi
|
||
|
|
BOOL fShowChildren // Display children (if any)
|
||
|
|
NODE * pnParent // Parent
|
||
|
|
NODE * pnChild // First Child
|
||
|
|
NODE * pnLeft // Left and Right
|
||
|
|
NODE * pnRight // Siblings
|
||
|
|
|
||
|
|
The benefits of using a tree are many:
|
||
|
|
|
||
|
|
- You will always know based upon your location in the tree
|
||
|
|
what index in the listbox you are. (The tree is always sorted, and
|
||
|
|
thus provides a way to easily count the path from the root.)
|
||
|
|
|
||
|
|
- This allows for easy preservation of selection across refreshes.
|
||
|
|
|
||
|
|
- Easy way for to purge unwanted data from memory.
|
||
|
|
For example: If someone expands a node, then chooses
|
||
|
|
to collapse that node. A pointer to that node could be entered into
|
||
|
|
a list for cleanup. This list would contain pointers to parents
|
||
|
|
whose children were no longer visible and after an appropriate time
|
||
|
|
delay that information would be purged. Of course at the moment it
|
||
|
|
would be too dificult to delete anything more than one level of
|
||
|
|
expansion because if the user happens to expand that node again we
|
||
|
|
must present the same expansion as was there before.
|
||
|
|
|
||
|
|
EXAMPLE:
|
||
|
|
|
||
|
|
ABLE TO PURGE:
|
||
|
|
|
||
|
|
domain
|
||
|
|
server
|
||
|
|
server
|
||
|
|
server
|
||
|
|
server
|
||
|
|
server
|
||
|
|
domain1
|
||
|
|
|
||
|
|
domain is collapsed
|
||
|
|
|
||
|
|
domain
|
||
|
|
domain1
|
||
|
|
|
||
|
|
after a period of time all of the servers are purged. If the user
|
||
|
|
expands domain then we reload the servers.
|
||
|
|
|
||
|
|
|
||
|
|
UNABLE TO PURGE:
|
||
|
|
|
||
|
|
domain
|
||
|
|
server
|
||
|
|
server
|
||
|
|
server
|
||
|
|
share
|
||
|
|
share
|
||
|
|
share
|
||
|
|
server
|
||
|
|
server
|
||
|
|
domain1
|
||
|
|
|
||
|
|
domain is collapsed
|
||
|
|
|
||
|
|
domain
|
||
|
|
domain1
|
||
|
|
|
||
|
|
after a period of time the servers can't be purged because we would
|
||
|
|
then have to remember the level of expansion of each server because
|
||
|
|
if the user re-expands domain, then we should show what was there
|
||
|
|
before the initial collapse.
|
||
|
|
|
||
|
|
4. CLASS HEIRARCHY
|
||
|
|
|
||
|
|
The C++ classes for implementing the OLB is as follows:
|
||
|
|
|
||
|
|
LB_TREE
|
||
|
|
LBNODE
|
||
|
|
LBI
|
||
|
|
|
||
|
|
|
||
|
|
5. CLASS DETAILS
|
||
|
|
|
||
|
|
T.B.F.I
|
||
|
|
|
||
|
|
6. OPERATION
|
||
|
|
|
||
|
|
7. OPEN ISSUES
|
||
|
|
|
||
|
|
8. REVISION HISTORY
|
||
|
|
|
||
|
|
Who When What
|
||
|
|
--- ---- ----
|
||
|
|
KevinL 10/06/1991 Created this document.
|
||
|
|
|