[duxhelp] Re: Embosser setup woes

  • From: "Peter Sullivan" <peter@xxxxxxxxxx>
  • To: <duxhelp@xxxxxxxxxxxxx>
  • Date: Tue, 15 Mar 2005 10:48:22 -0500

George,

I won't be screaming.  Nor will I comment much on what you suggest.  We've
been through it before.  I prefer to hear what others make of your
suggestions.

One comment I will make is about your point #8.  As you know, this list is
archived.  Assuming the archives are still available for the original DBT
10.5 beta testing, you'll find plenty of evidence that people don't like
pop-up messages, at least not until "OK" is clicked.

- Peter

-----Original Message-----
From: duxhelp-bounce@xxxxxxxxxxxxx [mailto:duxhelp-bounce@xxxxxxxxxxxxx] 
Sent: Monday, March 14, 2005 6:15 PM
To: duxhelp@xxxxxxxxxxxxx
Subject: [duxhelp] Re: Embosser setup woes

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 //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 //www.freelists.org.  The list archive
* is also located there.
* Duxbury Systems' web site is http://www.duxburysystems.com
* * *

* * *
* 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 //www.freelists.org.  The list archive
* is also located there.
* Duxbury Systems' web site is http://www.duxburysystems.com
* * *

Other related posts: