[platform-debug-dev] Collapsing thread behavior for length operations

[Joe_Szurszewski@xxxxxxx]

        In the latest build (20011107), there is a problem using the 'details pane' in the VariablesView.  
If an evaluation of 'toString()' takes longer than the established timeout value for evaluations (currently
3 seconds), the stack frames of the suspended thread are collapsed (disappear) to indicate that something
lengthy is happening.  This causes a CHANGE DebugEvent to be fired, which is ultimately heard by the VariablesView,
which resets its input, which blanks out both it and the details pane.  The view stays blank until the
evaluation finishes, at which time the SUSPEND event causes the VariablesView to be repopulated, although nothing
in the view is expanded, and the previous selection is lost.  The logic for handling the 'collpase timer' 
currently resides in JDIThread, so that ALL method invocations on a thread get this behavior  This seems counterintuitive, 
since JDIThread is part of the model, not the UI.  I propose moving this logic into the UI as follows:
        -        Move timeout monitoring to the Action subclasses that need collapse behavior 
                (ex. StepIntoActionDelegate)
        -        On action invocation, the action registers for DebugEvents
        -        Action starts timer (copy std. Timer class & ITimeoutListener interface)
        -        Action invokes the appropriate method (ex. stepInto) on the IStep debug element in question
        -        Action waits for appropriate DebugEvent (STEP_END on debug element in question) or timeout, 
                whichever comes first
        -        If timeout happens first, invoke some sort of "timeout()" method on the IStep debug element.
                This cleans up the internal model state of the debug element, and fires a CHANGE DebugEvent
                so the UI (e.g., DebugView) can update
        -        If STEP_END callback happens first (on the element in question), cancel the timer.  
                The DebugView will also hear this event and update the UI accordingly
        
Making this work requires several things.  (1) New API on IStep (or a new superinterface that IStep extends) 
that defines the "timeout()" method.  There is probably a better name for this.  (2) Changes to JDIThread & 
appropriate action classes to relocate timing logic.  (3) Access to Timer & ITimeoutListener types.

Unresolved issues with this approach: (1) Do any other capability interfaces beyond IStep (ex. ISuspendResume) 
need a "timeout()" method?  (2) Current JDI stepping implementation is non-blocking.  IStep JavaDoc says 
stepping implementations may be either blocking or non-blocking.  Do we intend to stick with this?  If so,
we might need extra logic in the actions to handle blocking implementations, so that they don't block the
UI thread.  If this is the case, we would also need a method on IStep (or its superinterface) along the 
lines of "isBlocking()" so that an IStep implementation can report whether it uses a blocking implementation
of stepping, and thus actions can behave correctly.

Benefits: (1) Collapse behavior is now under UI control.  Collapsing only happens through user-initiated events that
ask for it.  Programmatic evaluation, such as the evaluation of the toString() method for the details pane, no longer gets
the collapse behavior whether it wants it or not.  (2) Cleaner model/UI separation.

Any thoughts?