An idea for a small to medium size project which may be of interest
to someone who has lamented the limitations of mbbi/o. I don't
have bandwidth to pursue this at present.
I think it would be possible, and maybe even relatively easy, to
extend the number of states for mbbi/o records from 16 to 32,
and lengthen the state strings from 24 to 40 characters.
This change would only by visible through PVA (with QSRV), but
not CA where the additional states/characters would be hidden.
I think this project would involve.
* Lengthening *ST fields of mbbi/o from size(26) to size(40).
The DBRenumStrs macro already uses MAX_STRING_SIZE, so the
longer fields will be immediately visible through QSRV.
* Change DB_MAX_CHOICES from 30 to 32.
* Add 16x3 new fields to mbbi/o (and come up with 16 new
two letter abbreviations...)
* Adjust mbbi/o record support to use the new fields.
Unfortunately, this code has a magic number 16 spread around.
It would be good to consolidate this in a eg. macro definition.
Testing would first need to check that CA/RSRV truncates correctly
when the number and/or length of strings exceed the 16x26
limits of DBR_GR_ENUM. And secondly that QSRV shows everything.
Also, a "literature" search (eg. w/ google and github) for
support modules use DBRenumStrs or the record support enum
functions (eg. rset::get_enum_strs()) to look for potential
regressions in external code.
- Navigate by Date:
- Prev:
mbbi/o more/longer states Michael Davidsaver via Core-talk
- Next:
Build failed: EPICS Base 7 base-7.0-413 AppVeyor via Core-talk
- Index:
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:
mbbi/o more/longer states Michael Davidsaver via Core-talk
- Next:
Build failed: EPICS Base 7 base-7.0-413 AppVeyor via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|