[duxhelp] Re: Embosser setup woes

  • To: <duxhelp@xxxxxxxxxxxxx>
  • Date: Mon, 14 Mar 2005 23:14:34 -0000

Peter,

Let me talk this out loud and, if it doesn't have you in
screaming fits first, perhaps others will help formulate
things.

In fairness, I am also trying to consider minimal
modifications here.

1)  My vote is to implement the "recommended" settings for
given form sizes.  (Specifically NOT the "maximum" as
before)

2)  The "maximum" settings however, should more stringently
serve as a safety buffer in case anyone tries to exceed what
can fit a given size of form/embosser.

3)  When all's said and done, emb.elt can be edited locally,
just as easily as a dot mws file - almost easier in fact.

4)  emb.elt should be protected during (re)installation
where this file has been customised.  (This files does still
need some fine tuning)

5)  There is a need to differentiate between what happens
when setting up a NEW device, or editing an EXISTING device.

6)  Settings for a specific "Global Device" should stick (in
Registry?)

7)  Settings for a "Document Device" obviously stick with
the document.

What should happen when adding a new device?

8)  If a user attempts to use a setting that is not
acceptable, they should be warned AT THE TIME they tab out
of the relevant field or group.  For example, if you input a
binding margin of 2, when you already have characters per
line at the maximum.

    You recently suggested that users did not like frequent
error messages popping up like this - sorry, but I'd like to
meet one of these users!  

    Everyone I have spoken to says they would prefer to be
told at the time.  At the moment, an erroneous entry such a
"999" does produce a "notification" - but hitting OK,
results in simply going back to previous settings.  I want
to be told, "Hey!  That's an invalid entry!"

What should happen when editing/changing an existing device?

9)  This is where (we here in the UK at least) have been
having problems.  The most common being unexpected changes
of embosser settings.

I suspect many are down to embosser settings being stored in
the Registry in HKEY_LOCAL_MACHINE.  (It seems many
administrators restrict access to this part of the Registry
anyway)  

I am personally now 100% convinced they should be stored in
HKEY_CURRENT_USER.  This Current User trend shared by many
applications from screen readers to main stream
applications.

This will also solve a major problem with network users who
have "Roving Profiles".

10) Appropriate additional warnings must be given - for
example, if changing form size - where one would not require
these if setting up a new device.

Just some thoughts for now.

George.
  



-----Original Message-----
From: duxhelp-bounce@xxxxxxxxxxxxx
[mailto:duxhelp-bounce@xxxxxxxxxxxxx] On Behalf Of Peter
Sullivan
Sent: 14 March 2005 18:27
To: duxhelp@xxxxxxxxxxxxx
Subject: [duxhelp] Re: Embosser setup woes

George,

We could bring back use of the "recommended" settings; at
present DBT makes no use of them.

However:
  1. These settings are hardwired in emb.elt.  The user does
not alter them in the Global, Embosser Setup dialog.
  2. This doesn't answer the question of what to do when the
user changes embossers.

- Peter

* * *
* This message is via list duxhelp at freelists.org.
* To unsubscribe, send a blank message with
*   unsubscribe
* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may
also
* subscribe, unsubscribe, and set vacation mode and other
subscription
* options by visiting http://www.freelists.org.  The list
archive
* is also located there.
* Duxbury Systems' web site is http://www.duxburysystems.com
* * *



This Message has been scanned for viruses by McAfee Groupshield.
* * *
* This message is via list duxhelp at freelists.org.
* To unsubscribe, send a blank message with
*   unsubscribe
* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
* subscribe, unsubscribe, and set vacation mode and other subscription
* options by visiting http://www.freelists.org.  The list archive
* is also located there.
* Duxbury Systems' web site is http://www.duxburysystems.com
* * *

Other related posts: