EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  <19971998  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  1996  <19971998  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: Display Manager ASCII Formats
From: Kay-Uwe Kasemir <[email protected]>
Date: Fri, 24 Jan 1997 15:07:44 -0700
Hi Chip, hi all:

After hearing that EDM uses an ASCII format that is 'new', Chip wrote:
>Well, I'm rather disheartened to hear of yet-another-ascii format being
>created to describe displays.
>While you may not have liked the old
>format, the cost of incompatibility is quite high (which you probably
>cannot appreciate having not been on the project long enough). Can
>you post your reasons for creating a new format to tech-talk?

Well, I've been into this about as long as the DESY people are
and I do understand that every new format is a pain,
but what format would you pick?
I was thinking about using edd/dm, but ADL is no 'generic
display description language'. Instead it is heavily related to
the way edd/dm maintains it's internal structures.
So for edd/dm it's very easy to read/write, for my display
manager it would be a maijor effort to implement that format.

So what I use right now is a tagged printout of my
internal structures.
Implementing this _and_ a basic converter from edd/dm
into my format took only two days, so that's what I did
instead of spending much more time implementing a format
that doesn't fit my needs and isn't generic, either.

If all display tools should use the same format,
we must try to find a generic format that makes
sense, with extensions for each specific DM which
are ignored by the remaining programs.

Forcing all tools to use edd or medm or some other
format which is heavily related to a single program
seems to be no good idea to me.
Meanwhile we have to use converters.

-Kay



For what it's worth: an example:

#	Saved: Wed, Jan 15 1997, 13:05:11
#	Object Count: 18
Bitmap
{
	Object
	{
		rect=218 8 575 88
		color=0x000000
	}
	pic=WIN32.bmp
	keep_size=0
}
Label
{
	Object
	{
		rect=5 140 170 173
		color=0x000080
	}
	Font
	{
		name=Courier New
		height=33
		weight=400
		pitch=49
	}
	txt=IP-16 ADC
}
Bar
{
	Object
	{
		rect=12 193 133 218
		color=0x0000FF
		pv=ioc1:ADC0
	}
}
TextUpdate
{
	Object
	{
		rect=46 221 106 240
		color=0x000000
		pv=ioc1:ADC0
	}
	Font
	{
		name=Fixedsys
		height=19
		weight=400
		pitch=49
	}
	txt=1.7004
}


Navigate by Date:
Prev: Re: PC/WIN32 Display Options watson
Next: FWD: Display Manager ASCII Formats Matthias Clausen DESY -MKS-2/KRYK-
Index: 1994  1995  1996  <19971998  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: Joerger `VDACM' 8ch/16bit waveform generator SARKAR
Next: FWD: Display Manager ASCII Formats Matthias Clausen DESY -MKS-2/KRYK-
Index: 1994  1995  1996  <19971998  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 ·