EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: dm
From: Ric Claus <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Fri, 23 Feb 1996 15:05:00 -0800 (PST)
Deb,

	[snipped my comments]

> The display list was recently modified to include formats on text_entry 
> objects.  My plan was to allow hex numbers if the format was set to do so,
> and have it be an error otherwise.  Alternatively, for DBR types that are
> not double or float, I could just allow them.  (I could even allow them
> for floats and doubles, but I'm not sure that it makes as much sense.)
> Comments?  I'm assuming that if the hex format was chosen, CA updates to the
> text_entry object would reflect that choice.  Last question: if the hex
> format is selected, do I reject input other input?  (I vote no, as long as
> it fits the %i format of scanf)
> Ditto for octal format....

By "format" do you mean scanf style formats?  My guess is that that would be
preferable.  Along with my don't do the user any favors philosophy, I would 
not check the DBR types when interpretting a number.  The user should get what
(s)he asks for if at all possible, even if (s)he gets something other than 
what (s)he intended.  So if (s)he asks for %i format for a double, an integer, 
octal or hexadecimal representation of a double should be entered.  (S)He'll 
change it when (s)he grows tired of it.  Thus reject it only if scanf does.

By the way, I would consequently suggest that "text update" objects show hex
numbers with a leading "0x" or "0X" rather than a trailing "x" to be 
consistent.  Ultimately, when drag-and-drop is implemented, a number like 13x 
won't be accepted by scanf when dropped on a "text entry" object, never mind
arguments invoking potential operator confusion.  Maybe "text update" objects 
should also be modified to accept a format specifier (perhaps as a menu choice 
so the current scheme doesn't break anything)?

> 
> > I find that in some cases undesired behavior is produced when continuously 
> > updating the .VAL field with a changing valuator.  I realize that this behavior
> > can be changed with the menu on the live valuator, but I would rather like to
> > be able to set the defaults in this menu with edd when the valuator is created
> > or modified.
> 
> Also in the display list, so you can configure it in edd.  Soon (hopefully) it
> will be implemented in dm.  I, too, hate to have to configure things every 
> time I bring up a display.
> 
> > 
> > 	Ric
> > 
> 
> Deb
> 

Great, Deb.  Thanks very much!

	Ric


Navigate by Date:
Prev: Re: dm Deb Kerstiens
Next: logging writes - 2nd round Matthias Clausen DESY -MKV2/KRYK-
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: dm Deb Kerstiens
Next: logging writes - 2nd round Matthias Clausen DESY -MKV2/KRYK-
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·