191 lines
8 KiB
Plaintext
191 lines
8 KiB
Plaintext
Issues wrt Specs
|
|
-----------------
|
|
|
|
preamble - pls list your issues below. Be sure to explain
|
|
problems & suggest alternatives.
|
|
|
|
chuck, 4/28/91
|
|
|
|
JonN 5/1/91 Added some items relating to Test Driver code review.
|
|
JohnL 5/3/91 Added own take on field updates, magic group behaviour
|
|
JohnL 5/14/91 Added Message popup on top of Set focus dialog
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
|
|
=========
|
|
STANDARDS
|
|
=========
|
|
|
|
Saving App coordinates & sizes in DS. Problems include:
|
|
a) extra access DS slows things down.
|
|
b) need extend schema, another thing to install correctly
|
|
c) different display monitors make things messy, yet more
|
|
code needed to do the right thing. Ditto if errors when
|
|
accessing DS.
|
|
d) if bring app up, shutdown & bring up again, good chance we
|
|
dont get same result unless we hit master always, which is
|
|
not acceptable.
|
|
Suggest we store the stuff locally. Wont follow user about, but then
|
|
none of the other apps (like WinFile, PrintMan) do anyway! None of the
|
|
above will be an issue.
|
|
|
|
Saving parameters
|
|
Are parameters like fConfirmation shared between PrintMan,
|
|
UserTool, etc.? Should we have an internal WINNET API to handle
|
|
this?
|
|
We need a master list of every configuration parameter, eventually
|
|
we will have to define an LM_GUI_CONFIG DS class.
|
|
|
|
Saving attributes one at a time. We can do this at moderate coding cost
|
|
with ParmNums, but a few other issues arise:
|
|
a) if user has multiple select & sets several items, the number
|
|
of times we hit the net can be pretty high.
|
|
b) if we set all at once, and get an error, the object is
|
|
unchanged. If we set one at a time, and get an error halfway,
|
|
the object is half changed. This makes it much harder to explain
|
|
to the user. Backing out is not a solution either. We have hit
|
|
an error and there is good change we cannot backout.
|
|
c) DS efficiency issues?
|
|
The problem we are trying to solve is what happens if 2 admins modify the
|
|
same object. The proposed solution of only setting the attributes that have
|
|
been modified partially solves the problem, but introduces some other
|
|
problems that need to be looked at carefully. Suggest further investigation.
|
|
|
|
John's addition to the above: So we are going to force the majority of
|
|
the admins to suffer from slower data entry/editting for a situation
|
|
that *might* happen once in a blue moon? There *are* worst case scenarios,
|
|
but if we are really concerned about the user losing data, then we should
|
|
do some type of record locking mechanism (is this possible?) which prevents
|
|
multiple admins from editting the same record. The proprosed scheme
|
|
doesn't really give the user anything except a slower program
|
|
and a *lower* chance of losing data.
|
|
|
|
Timer Refresh in main window issues
|
|
With automatic refresh, we run the risk of calling for refresh more
|
|
frequently than we can perform them. Do we have some uniform way of
|
|
detecting and handling this? [both FuncSpec and CDD issue]
|
|
|
|
The behavior specced on lines 198-200 is not consistent with lines
|
|
444-446. The behavior specced on lines 198-200 is difficult to
|
|
implement, since a window does not typically know whether it is in
|
|
the foreground of an application. 444-446 is much easier to
|
|
implement, and seems to me to be good enough. If this is necessary,
|
|
would it be acceptable if this applies only to dialogs we display
|
|
(i.e. not to dialogs displayed by the Print Manager proper)?
|
|
|
|
Logon Dialog position
|
|
I had previously understood that the Logon Dialog was centered only
|
|
when called during Windows startup. Should it always be centered as
|
|
per line 60?
|
|
|
|
MsgPopup on top of SetFocus dialog
|
|
The current spec. states that when an admin app encounters one of the
|
|
following:
|
|
|
|
1) an invalid domain/server on the command line
|
|
2) The user running the application doesn't have the
|
|
necessary authority on the specified server or
|
|
3) An error occurs when getting initial data from the domain or
|
|
server given
|
|
|
|
(these are all during start up) the Setfocus dialog appears, then, on
|
|
*top* of the setfocus dialog, a message popup appears stating the
|
|
given error has occurred with the prompt: Do you want to select another
|
|
domain or server to administer? If the user selects "No", then
|
|
everything goes away, else the user is placed on the setfocus dialog.
|
|
|
|
I propose changing the behavior to the following:
|
|
|
|
Error occurs
|
|
Show Message popup with same contents as above, if the user presses
|
|
"No" then everything goes away, else the Set focus dialog
|
|
is brought up.
|
|
|
|
This is primarily a development issue. The implementation is easier
|
|
of we can just put up an error message then the setfocus dialog. The
|
|
current behavior doesn't add anything for the user (in fact, the
|
|
MsgPopup will probably cover the Setfocus dialog).
|
|
|
|
|
|
=============
|
|
PRINT MANAGER
|
|
=============
|
|
|
|
Move queue from one server to another. This is very hard to get right:
|
|
a) we need to worry not just about the Queue, but all its
|
|
associated stuff: printers, drivers, ports, permissions,
|
|
auditing, etc. Not all of this info is remotely available, so
|
|
it is very easy to go wrong.
|
|
b) How often will users do this? Unlike DFS volumes, people do not
|
|
move printers from one server to another frequently, since there
|
|
is a physical element of the print hardware involved.
|
|
Suggest we nuke this. To properly setup a printer, the user needs to
|
|
setup from Print Man anyway, so just have the user to delete and recreate.
|
|
|
|
When the user pauses a printing print job, it is the print _destination_
|
|
which should be paused, rather than the print queue (thx Chuck).
|
|
|
|
Please spec default setting of "Admin Menus" preference if DS access
|
|
fails. I assume TRUE for now.
|
|
|
|
WN31.DOC still contains a reference to the WNetViewQueueDialog API. Is
|
|
this obsolete?
|
|
|
|
If a job was submitted locally (from an OS/2 app running on the server),
|
|
the job's username is NULL. Should we pass some string, perhaps
|
|
"LOCAL"?
|
|
|
|
Is it important to seperate the devicenames with commas in the
|
|
compat-mode properties field? It makes my life slightly easier to
|
|
seperate them with spaces (as does the API).
|
|
|
|
While we're at it, why is this read-only? It seems to me that the user
|
|
may well want to change the list of ports in the compat-mode dialogs,
|
|
and it isn't difficult to support.
|
|
|
|
Lines 387-391: This implies that if the server is down, we cannot move
|
|
the share to another server. This was one of the reasons we wanted to
|
|
provide the capability to change servers in the first place. Another
|
|
good reason to nuke this functionality!
|
|
|
|
Lines 483-484: I don't think we should create a new DosPrintQueue unless
|
|
it is necessary, possibly if we change the list of ports, certainly if we
|
|
change the server. Remember that DS propagation delay will make the
|
|
new queue unreachable for a while. There are also more failure modes on
|
|
creating a new queue and deleting the old one.
|
|
|
|
Lines 457-458: Do we use the same model for all drivers? If not, we
|
|
must prompt for model every time we add a new driver.
|
|
|
|
Lines 421-422: Is it necessary to create a new port when only the
|
|
printer list is changed? Is this error message appropriate in this
|
|
case?
|
|
|
|
Lines 529-530: Do we want to force the admin to delete+recreate the
|
|
share just to change the password?
|
|
|
|
|
|
=====
|
|
LOGON
|
|
=====
|
|
|
|
Why do we compare the old and new passwords case-sensitive? There is no
|
|
such thing as a user password on a core server.
|
|
|
|
|
|
=====
|
|
OTHER
|
|
=====
|
|
|
|
Do applications other the the Print Manager Extensions need to be notified
|
|
of changes in logon status? One scheme proposed is to broadcast a
|
|
user-defined message selected by RegisterWindowsMessage, which any
|
|
interested app can watch.
|
|
|
|
Please spec an error message for failure to write user preferences to the DS,
|
|
e.g. failure to write the Confirmation preference. It would be easiest
|
|
to implement if the error message were not specific to the preference being
|
|
written, although it may contain a field on the type of error. The user
|
|
probably knows what preference was being changed anyway.
|