Benjamin Franksen wrote:
On Monday 11 July 2005 14:55, Marty Kraimer wrote:
Also templates should not appear in the DBD files. This can be done
by properly defining interfaces which are implemented by "record
fragment".
Hmm. Can you explain how, for instance, an 'invalidOutput' struct can be
specified in the DBD so that it is usable as building block for
stringout as well as ao record type, without parameterizing over the
type of the value?
I did not express myself properly.
It is not the templates but the methods that should not appear in the
DBD files.
There should not be ANY language specific definitions in DBD or DB
files.
Note, in my original proposal (on the wiki), there is not a single
mentioning of a C or C++ language feature in the DBD file. If you
insist, I can write down a precise and self-contained definition of the
meaning of the angle-brackets notation I used in the DBD fragments I
posted.
Ben
The following shows a way to handle code fragments just like device support.
1)NO METHODS appear in the dbd file.
2) It uses Andrew's suggestet syntax for templates.
3) It uses a device definition
A dbd file contains the following:
menu(invalidAction) {
choice(invalidActionContinue_normally,"Continue normally")
choice(invalidActionDon_t_drive_outputs,"Don't drive outputs")
choice(invalidActionSet_output_to_IVOV,"Set output to IVOV")
}
The record.dbd file contains
record(xxx) extends iocRecord {
...
field(invalidAction,menu(menuIvoa))
field(outputValue,float64)
field(invalidOutput,device(none,processInvalidOutput))
...
}
Also in a dbd file the following appears
device(none,default,processInvalidOutput)
Some .h file contains:
class processInvalidOutput {
virtual void compute(int32 value, DbfMenu &invalid,epicsString
&status, epicsInt16 &severity);
virtual void compute(float64 value, DbfMenu
&invalid,epicsString &status, epicsInt16 &severity);
... // perhaps other types for value
}
The process routine then has a statement like
pprocessInvalidOutput->compute(outputValue,invalidOutput,,status,severity);
Thus code fragments are handled just like device suppoort that has no
direction.
For this example the device definition also has no dataStructName. Code
fragments that need additional private data could define a dataStructname.
Marty
- Replies:
- Re: Record support and user-defined fields Benjamin Franksen
- References:
- V4 iocRecord: forward linking Ralph Lange
- Re: Record support and user-defined fields Andrew Johnson
- Re: Record support and user-defined fields Marty Kraimer
- Re: Record support and user-defined fields Benjamin Franksen
- Navigate by Date:
- Prev:
Re: Record support and user-defined fields Benjamin Franksen
- Next:
Re: Record support and user-defined fields Benjamin Franksen
- 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:
Re: Record support and user-defined fields Benjamin Franksen
- Next:
Re: Record support and user-defined fields Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|