Lines Matching refs:control
67 way for an {\eclipse} side to hand over control to the external
68 side. Effectively, instead of handing over control to a single peer,
69 control is handed over repeatedly to all the peers that are participating
70 in peer multitasking. The control is shared between these peers in a
73 give up control, so that the control can be passed to the next multitasking
87 During a multitasking phase, control is handed over to a multitasking peer,
89 one of these handlers, and when the handler returns, control is handed
101 round of passing control to all the multitasking peers, i.e. control is
104 multitasking phase, then after the initial start phase, the control will be
119 given control during a multitasking phase. {\bf Multitask handlers}
128 When control is handed over to the peer during a peer multitasking
130 handler returns, control is handed back to {\eclipse} (and passed
132 that events are not processed while the peer does not have control.
134 is given control, to allow any accumulated events to be processed.
136 is given control frequently enough, then any interactions with the
186 participate further in that multitasking phase once control is
189 {\eclipse} side. The peer multitask control queue will be
212 % invoked when control is being handed to the peer (as set up in {\bf
234 \item end: a button to end interaction with {\eclipse} and return control
242 peer is given control on its own. When the peer is given control on its
249 various handlers for the handing of control between {\eclipse} and itself
258 The handlers for when control is handed back to {\eclipse}, {\tt ec_start},
259 and when control is handed over from {\eclipse}, {\tt ec_end}, are defined
281 during a peer multitasking phase, control is repeatedly handed back and
354 Otherwise, the peer has been explicitly handed control exclusively,
355 and so control is handed back to {\eclipse} in the normal way using {\bf
384 control, the peer will not participate in future multitasking phase (unless