One 'solution' would be as follows:
- The same application that "can be manually prompted to reload it's configuration" could also write to a PV to reflect "TheMenuChanged". This PV could cause the medm menu(s) to disappear (or use Channel Access Security to disable writing ) if "TheMenuChanged" PV is active.
- A procedure to reset "TheMenuChanged" PV could include restarting any screens with the menu, which will reload the enum strings.
- If you really want to get 'hacky', there is a field in the all records that is NULL only when no monitors are set on that record (I forget the details). One could write a subroutine record that only allows the "TheMenuChanged" PV to get reset when there are no monitors (which means all screens have been closed). This exercise is left to the reader.
Ned
________________________________________
From: [email protected] [[email protected]] on behalf of Jameson Graef Rollins [[email protected]]
Sent: Wednesday, April 01, 2015 11:53 AM
To: EPICS tech-talk
Subject: EPICS UIs in the context of changing enum record identifiers
Hi, all. We have an application that employs an enum record as a
control interface (for submitting a request to the program). The
application can be manually prompted to reload it's configuration, which
can occasionally cause the elements of the control enum to change
(desired behavior).
The problem is that our operator interfaces (primarily MEDM at the
moment) do not behave well in the context of these enum change. All
MEDM enum controller objects retrieve enum identifiers only once at
startup. This means they become stale after the enum changes, and more
dangerously, allow the user to select one element that is actually
mapped to another. This has created quite a few headaches for us.
I've been trying to find a way around this problem, but haven't come up
with anything. The best solution I have so far involves creating a
screen on the fly that creates a shell command menu with a bunch of
"caput" commands for the strings of enum. This of course doesn't get
updated on application reload either, but it at least doesn't allow for
selecting a mislabeled element.
I'm soliciting for suggestions about how to create operator interfaces
that behave better in the face of changing enum records. All operator
interfaces that I've looked at (MEDM, EDM, QTDM) don't behave well. Any
suggestions of what we could do that don't involve patching MEDM or
creating our own operator interface?
jamie.
- References:
- EPICS UIs in the context of changing enum record identifiers Jameson Graef Rollins
- Navigate by Date:
- Prev:
Re: EPICS UIs in the context of changing enum record identifiers Pete Jemian
- Next:
Re: Registration Open for the Spring 2015 EPICS Collaboration Meeting Eric Berryman
- 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 UIs in the context of changing enum record identifiers Pete Jemian
- Next:
RE: EPICS UIs in the context of changing enum record identifiers Mooney, Tim M.
- 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
|