Automatic result view creation

We have specified that we wish to open a view by necessity to display the result environment. This problem relates to Sophtalk since results from Typol are transmitted by the result signal. We must therefore insert an stnode in the network to listen for this signal and open a result view. However, we only want to open one view, and this view should be updated by listening to subsequent result signals.

The result signal carries two values: the name of the result and its value. The name of the result is the variable name as it is returned by an exported clause. When an exported premise returns several results, each is sent to the tool network by a separate result signal. In our case, we have only one result (whose Le-Lisp name is '|env$| for an evaluation without initial environment and '|env$$| otherwise): an environment tree.

To open a window when a signal arrives, we make use of the function st-automatic-create. This function creates a spy in a principal network that listens to a given signal. When the signal arrives, the spy performs some action such as opening a new view. The spy sees to it that the action is performed only once, even if the same signal arrives later. The action must return a Sophtalk network, which then ``depends'' on the principal network. When the primary network dies (here, the tool network), the dependent network also dies automatically (here, a result view).

The function st-automatic-create takes a signal name to listen for, a callback function name, and initial data. When the signal arrives, the callback function is called with the following arguments: the signal name, the intial data, and any data carried by the signal. The initial data is any data known when st-automatic-create was called but which will not be available when the trigger signal arrives.

Here is the code necessary to open the result environment view automatically when the first result signal arrives:

;;;;;;;;;;;;;;;;
;;Result view
;;;;;;;;;;;;;;;;
(de :create-result-view-spy (tool network)
  ;;The tool and network are known at creation time,
  ;;but not easily available when the run signal arrives! 
  ;;Thus, we pass them on as initial data.
  (st-automatic-create network 'result ':result-view-callback
                       tool network))

(de :result-view-callback (port tool network name env-tree)
  (lets ((view (with 
                ((current-manager #:gfxobj:look:ctview:plain-manager))
                    (map-ctview "Result view" env-tree 
                                () () () () () ())))
         (ctedit (send 'object view))
         (view-network ({ctedit}:network ctedit))
         )
        ;;This function MUST return a network.
        view-network
       ))

The function map-ctview opens a view given a Vtp tree and view title.

According to the semantics of st-automatic-create, the second function is only called once to open the view. Subsequent result signals are not handled in any special way, so the result view will not be updated after later evaluations. To accomplish this, we must add an stnode to the tool network that listens to the second and all succeeding result signals. Below we define a new stnode class Exp-result-spy, create an instance which encapsulates the result ctedit, and include it in the tool network.

(st-declare Exp-result-spy (result) ())

(de :result-view-callback (port tool network name env-tree)
  (lets ((view (with 
                ((current-manager #:gfxobj:look:ctview:plain-manager))
                    (map-ctview "Result view" env-tree 
                                () () () () () ())))
         (ctedit (send 'object view))
         (view-network ({ctedit}:network ctedit))
         (stnode (st-create 'Exp-result-spy))
         )
       ;;Create stnode to listen to 'result signal
       (st-store-and-set-action stnode ctedit 
                                ':result-view-callback)
       ;;Include in tool network.
       (st-include network stnode)
       ;;Make stnode dependent on view network
       (st-dependent-stnode view-network stnode)
       ;;This function MUST return a network.
       view-network
       ))

(de :result-view-callback:result (stnode port name env-tree)
    (lets ((ctedit (st-object stnode))
           (var ({ctedit}:subject ctedit))
           )
        ;;This call redisplays result view.
        ({variable}:change var ({variable}:root var) env-tree)
        ))

Note the call to st-dependent-stnode. The result stnode listens for signals in the tool network, but depends on the life of the view network. If the view is closed, the result stnode must be removed from the primary network. Otherwise the result stnode would continue to receive the result signal and try to update a view that no longer exists. Using st-dependend-stnode ensures that the result stnode will be removed from the primary network should the secondary network die.

We still lack the ability to clear the result view by signal. We have already added a button to the popup to emit the clear-views signal, so we need only encapsulate the result view to heed it. Since we have already encapsulated the result view in the tool network, we will simply add another input signal to the stnode class and define an appropriate callback function.

(st-declare Exp-result-spy (result clear-views) ())

(de :result-view-callback:clear-views (stnode port)
    (lets ((ctedit (st-object stnode))  
           (var ({ctedit}:subject ctedit))
           )
       ;;Redisplay automatic.
       ({variable}:change var ({variable}:root var) ())
       ))

Figure shows the stnodes that we have added for to the standard tool network for the interpreter. This diagram does not show the message display, which communicates with the tool in a separate network.