> > Your proposal is one way to handle the problem (yet another dbCommon
> > field???). It does, however, require that the client take a channel
> > name, strip off the field, append "RTYP", and do a search and get. Maybe
> > this is an OK interim solution. Another possibility is too see if some
> > changes to dbAccess and ca can make it possible to just ask CA directly
> > for the record type just like you can now ask for native type, native
> > count, etc.
>
> How is this simpler for the end user? Seems like this makes more
> work. Better to provide a record field, then end users can access the
> .RTYP field through a caget call.
In fact this really makes it easier for generic programs such as dm and cau
(and for the users of these programs).
- Replies:
- Re: proposed RTYP field Marty Kraimer
- Navigate by Date:
- Prev:
Re: EPICS r3.13 fields RTYP/VERS Mark Rivers
- Next:
EPICS North American Meeting in April Bob Dalesio
- Index:
1994
1995
1996
1997
<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: proposed RTYP field Pete Jemian
- Next:
Re: proposed RTYP field Marty Kraimer
- Index:
1994
1995
1996
1997
<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
|