re...
> field(VERS,DBF_DOUBLE) {
> prompt("Version Number")
> promptgroup(GUI_DISPLAY)
> special(SPC_NOMOD)
> interest(1)
> initial(<version>)
> }
>
> The record developer changes <version> whenever he/she modifies the
> record support.
> Thus the version will be available automatically. If this is done we
> can't put the field in dbCommon.
I think it would be a bad idea to set the record's version number in the .dbd
file anyway. (It might not be so bad for the .dbd file to have its own version
number, so record-support could verify that it wasn't compiled against an
outdated header file.)
Anyway, I'm in favor of every record having a VERS field. I think the device
support's version number should also be available via channel access. I don't
care whether or not version numbers are in dbCommon.
> With regards to accessing the record type via channel access, Matthais
> Clausen asked for this a long time ago. I have it on my 3.13 TODO list.
>
> 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.
It would be better, I think, to have the RSET function get_description(), which
would allow custom record support to tell clients anything it wants, including
record type and even application-specific information and on a field-by-field
basis (assuming you put extra description fields in your custom record). This
might give clients directly the information they'd otherwise have to infer from
RTYP, without forcing them to know the details of any record type, and it could
still allow an app developer to change the way things are implemented without
having to rewrite clients.
Tim Mooney
- Replies:
- Re: EPICS r3.13 fields RTYP/VERS Ralph Lange
- Navigate by Date:
- Prev:
Re: proposed RTYP field Pete Jemian
- Next:
Re: EPICS r3.13 fields RTYP/VERS Ralph Lange
- 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: EPICS r3.13 field DESC length William Lupton
- Next:
Re: EPICS r3.13 fields RTYP/VERS Ralph Lange
- 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
|