| 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: dataAccess V4 Ca client propertyId questions |
| From: | Andrew Johnson <[email protected]> |
| To: | EPICS Core Talk <[email protected]> |
| Date: | Mon, 27 Jun 2005 16:23:15 -0500 |
Kay-Uwe Kasemir wrote:
I forgot the circumstances, but one point at the SLAC meeting was that we might have to abandon the idea of "fred" == "fred.VAL".
True, and from that I developed the idea of supporting named views of the record. The dot now separates the record name from the view name, and some views will take simple parameters in parentheses.
If you want the default value, you'll have to use "fred.value" in the new command-line 'caget' or the 'probe' GUI. If you use "fred", you will get _all_ properties of fred.
Not quite. There should still be a default view for each record type, so you can still say "fred" and you'll get something analogous to the V3 "fred.VAL" default, but in V4 the record type has more control over what you will actually get back, and you will probably *not* get _all_ the properties, just the ones appropriate to the record's main value.
It'll be consistent for the whole hierarchy: In case "fred.limits" is a structure, "fred.limits" will get all structure elements. "fred.limits.display.high" might drill down to a structure element.
Ammend that slightly: your "fred.limits" becomes "fred.field(limits)" to view the complete "limits" field structure, although if the record type defines a "limits" view then "fred.limits" would be correct. To drill down though you would have to use something like "fred.field(limits.display.high)"
- Andrew -- Podiabombastic: The tendency to shoot oneself in the foot.