PropHelper Introduction

This tutorial expects that you have read this section about devscr.

PropHelper is a graphical programm to access a device's properties. It is

• based on devscr and thus
• can present property data, input dialogs, etc. in a way respecting the equipment model meta data provided in the corresponding XML file.
• It can also support you when accessing properties that are not covered by devscr.
• Finally you can customize PropHelper in its data/para input mechanism and property data representation.

The intention behind PropHelper is to give you one generic interface to access all properties of each device in a common fashion, no matter if it is implemented in devscr or not and to give you the ability to tweak the input/representation of the program to fit your individual needs (for example checking a new frontend software's correctness while implementing it).

How to start PropHelper

The command prophelper brings up the main window. You may add the following command line arguments:

• vrtacc=x where x is one of 0, 1, ..., 15
• a list of nomenclatures

As an example the screenshot that you see in the next section may come from the invokation prophelper --vrtacc=7 ut1mk1.

The Main Window

PropHelper presents you

1. the choice of the virtual accelerator,
2. an input field/drop box for a device nomenclature,
3. a button to show the properties of the chosen device,
4. a default properties list,
5. a read properties list,
6. a write properties list,
7. an extra list (that displays extra functionality implemented when customizing PropHelper) and
8. a quit button.

Note that in newer versions there is also a Help button that shows a link to this page.

Indicators of how well a property is supported

For a property one can distinguish between

• read/write/call: indicated by first character of property name and backgroundcolor (write: blue background)
• implementation in devscr: indicated by text color
  • red: not implemented in devscr => no meta info available, will be executed directly using devacc
  • black: implemented in devscr (or customized in PropHelper)
• type of parentheses:
  • (): property needs parameters
  • no parentheses: property does not need parameters
  • (?): PropHelper does not know whether parameters are needed or not (for those properties not covered by devscr, that is for the ones accessed directly through devacc, PropHelper cannot tell).

Accessing a property

When double clicking a property you will be presented some dialogs, depending on

1. a property's need for parameters
2. a property's need for (write) data
3. and finally
   1. either a read data display dialog or
   2. a status dialog for write and call accesses.

Doing input

Regarding bullets 1. and 2. (para/data dialogs):

1. You will of course not be displayed any input dialogs if neither parameters nor any data is needed.
2. For the () -decorated properties, for example rmeddatai(), you will be presented a specialized dialog that asks exactly the needed parameters.
   
   That dialog can (at least) check the type of your input and tell you if you entered a value that if of incorrect type like in this example.
   
   
   Because the XML equipment model files cannot cover device specific ranges for property fields PropHelper can of course not tell you if the data you entered makes sense and if it will be accepted when accessing the device - you may thus get an error message even if the input dialog succeeded.
3. For the (?) -decorated properties you will be presented a dialog that allows for comma separated input.
   
   The single values that you input will be cast down to the most special type possible (out of float, long, str in this order).
4. For write data you will always be presented an input dialog that is either specialized or comma separated depending on whether the property is implemented in devscr (or customized in PropHelper) or neither.

Presentation of results

Regarding bullet 3.1. (read data dialogs):
A read data dialog displays

• the timestamp of the read access,
• the parameters passed to the (read) call (no parameters in the following example's screenshot) and
• the structured data as it is defined in the equipment model XMLs (and thus in devscr). The data presentation includes
  • names,
  • arrays,
  • complex types,
  • values and
  • tooltips containing descriptions given in the XMLs.

Screenshot

If the property is not covered by devscr the read data is returned and displayed as an array like this.

Regarding bullet 3.2. (status dialogs): When doing a write or call access no read data is returned. Thus you will only be presented the status messages in a dialog like this.

Configuration

Until now there are limited possibilities to configure PropHelper's look.

Config file

In your home the file ~/.prophelperrc will be parsed and executed. You can for example setup the window size or font like this:

TCLCMDS.append(['option', 'add', '*Font', 'courier 12']) # last: font family & size
TCLCMDS.append(['wm', 'geometry', '.', '700x1000']) # last: window width x height

Note that these lines may not be indented.

Notes

As devscr does not support asynchronous or connected accesses PropHelper does not, too.

See also

• Slides showing a PropHelper introduction
• Customizing PropHelper

Feature requests

• Refreshable result dialog (PKainberger)
  when changing frontend data from other programs and using PropHelper to monitor these changes a refreshable dialog would be helpful.
  DONE
• Sticky input dialogs (MWiebel)
  When playing around with read parameters or write data/parameters it can be helpful to let the dialogs open. A user is now able to change only part of the input data to get another result. This way she need not enter most of the input data over and over again.
  This needs a change of the dialogs' behaviour, i.e. if two dialogs are needed for parameterized write properties they cannot open one after the other anymore.
• Keep dialog open if access fails (MWiebel)
  Same profit and consequences as above.