+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Summary of XRTF Trigger scheme (should extend this to all trigger types)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

New scheme (*1) is based on creating (and saving) a default response entry
when a TL study is made an XRTF hunter by clicking
the "Enable XRT Flare Trigger" (radio) button. The code for all this
is in the method "eis_mk_plan_gui::toggleXRTFlare". The newly created
response DB entry id is saved to the TL DB in the tag;
    sc.xrt_flare_response.response_study_id
Toggling this button (on/off) will reset the TL DB xrt flags to
unity/zero (*2).

This scheme relies on the fact that there is a one-to-one relationship
between the TL and response DB entries. The "keys" of this are;
a. seq_id of TL (hunter) study (stored in response DB entry)
b. id of newly created response study (stored in TL entry; 
       sc.xrt_flare_response.response_study_id)

So when a TL study is toggled to be an XRT Flare hunter study for the
first time it is assigned a response study entry (*3). It will retain
this correspondence - even when the XRT Flare trigger (radio) button is 
switched off. The TL entry tag "sc.xrt_flare_response.response_study_id"
will not be reset to zero. This way, if toggled on, off and on again 
the correspondence will be maintained. Also, it would be wasteful to
create a response DB entry and then not use it again if the TL study
is toggled on an XRT flare hunter and off again.

Remember, however, that trigger studies are defined by the TL xrt flare
flags (described below (*2)), and so even if a response study is created
in association with a TL study, but the XRT Flare hunter property was
toggled off, it won't actually be used.

1. Method: "eis_mk_plan_gui::toggleXRTFlare"

   When clicking "Enable XRT Flare Trigger" (radio) button to make a TL
   entry an XRTF hunter (trigger) study (or not).
   (a) Insist the study is already saved. This is because the TL and 
       response DB entries are linked by the former's seq_id and the
       latter's id value. So the hunter's study seq_id must be non-zero.
       
   (b) Check whether "sc.xrt_flare_response.response_study_id" is zero. 
       This is the response entry id stored in the TL DB. If it is zero
       then this study was not previously a hunter study. Hence,
       create a new response DB entry (*3). Default values include
       the seq_id of the hunter study, the response type, the default
       values for x0 and y0 (36,-18: get from routine 
       "/utilities/eis_get_default_x0y0.pro") and verify_fov (default
       value = 1). Also, the new response entry inherits the pointing
       parameters of the hunter (TL) entry.
              
       Hence, the hunter study contains a record of the response study,
       and vice versa.

2. Method: "eis_mk_plan_gui::invoke_xrt_flare_gui"

   This method instantiates and realises the xrt_flare properties GUI.
   It takes as inputs; Self (parent of "eis_mk_plan_gui" object) and
   "resp_id" from the hunter study's TL DB, viz: 
      sc.xrt_flare_response.response_study_id



Notes:

(*1) The previous scheme involved inadequately defined databases and
     structures. Also, moving (hard-wired) engineering parameters
     (specifically, x0 and y0) to planner control.

(*2) Don't use TL DB trigger parameters anymore (specifically the
     tags in the structure "sc.xrt_flare_response"). Instead create,
     update and use these parameters exclusively from the response DB.
     However, still uses the (binary) TL DB entries indicating whether
     this is a trigger study;

           tc.respond_to_xrt_flare [0/1B]
           sc.xrt_flare_response.respond_to_xrt_flare [0/1B]
           sc.xrt_flare_response.response_study_id [resp_id]
           sc.studyRasters[index].xrt_flare_props.xrt_flag [0/1B]

(*3) The id for a new response DB entry is calculated by incrementing
     the current number of entries which already exist in the response DB)