eXept Software AG Logo

Smalltalk/X Webserver

Documentation of class 'DebugView':
Home

everywhere
www.exept.de
for:
[back]

Class: DebugView

Inheritance:

   Object
   |
   +--GraphicsContext
      |
      +--DeviceGraphicsContext
         |
         +--GraphicsMedium
            |
            +--DisplaySurface
               |
               +--SimpleView
                  |
                  +--View
                     |
                     +--TopView
                        |
                        +--StandardSystemView
                           |
                           +--DebugView
Package:
stx:libtool
Category:
Interface-Debugger
Version:
rev: 1.498 date: 2010/04/27 17:04:56
user: cg
file: DebugView.st directory: libtool
module: stx stc-classLibrary: libtool
Author:
Claus Gittinger

Description:


This class implements a graphical debugger interface.
The debugger usually sits on top of the faulting process,
taking over its event processing. 
(this is different from other Smalltalk debuggers, which control
 the debuggee as a separate process. Consider this an historic
 leftover - the debugger was one of the first applications written for
 ST/X; however, why should we change it without a particular need ...).

Only the 'stopped' debugged process is affected;
other processes continue to respond to events.

The one exception is when an error occurs within the dispatcher process
or in one of the eventhandler processes - in this case, the debugger
will sit on an exclusive display connection.

The whole debugging will be changed, once the required process primitives
are available, which allow control of another processes execution
(i.e. single-step, restart & return). The setup will be changed then,
to have the debugger control the debuggee (i.e. two processes)

See additional information in 'doc/misc/debugger.doc'.

Notice: 
    the DebugView class caches the last used debugger in a class
    variable. It may happen, that a malfunctioning debugger (for example,
    a halfway destroyed one) is kept there. You will notice this, if a
    debugger comes up without showing any contents. In this case, close
    (or destroy) the broken debugView, and execute
        Debugger newDebugger
    which removes the cached debugger and forces creation of a new one the
    next time. This is a temporary workaround - the debugger will be fixed to
    avoid this problem.
    You also have to remove the cached debugger, if you change the debugger's 
    initialization code (buttons, menu, etc.) and you want the new code to become
    effective.

Related information:

    Exception
    Signal
    Process

Class protocol:

cleanup
o  lowSpaceCleanup
in low memory situations, give up cached debuggers

o  newDebugger
force creation of a new debugger (give up cached debuggers)

defaults
o  defaultIcon
return the browsers default window icon

o  defaultIconForAboutBox

o  defaultVerboseBacktrace

** This is an obsolete interface - do not use it (it may vanish in future versions) **

o  defaultVerboseBacktrace: aBoolean

** This is an obsolete interface - do not use it (it may vanish in future versions) **

o  updateStyleCache
extract values from the styleSheet and cache them in class variables

ignoring halts
o  haltIgnoreInformationFor: haltingMethod atLineNr: lineNrInHaltingMethod
the information (if any) about the ignore-state of a halt

o  hasIgnoredHalts

o  ignoreHaltIn: haltingMethod at: lineNrOfHalt forCount: countOrNil orTimeDuration: dTOrNil
remember to ignore a halt in some method for some number of invocations
or until some time has elapsed.
With nil count and time arguments, such an ignored halt is reactivated

o  isHaltToBeIgnoredIn: haltingMethod atLineNr: lineNrInHaltingMethod

o  isHaltToBeIgnoredIn: haltingMethod atLineNr: lineNrInHaltingMethod modifyEntryCount: modifyCount
should a halt be ignored ?

o  removeInactiveIgnores

o  stopIgnoringHalts
forget about all ignored halts

initialization
o  initialize

o  reinitialize
reinitialize after an image-restart

instance creation
o  enter
enter a debugger

o  enter: aContext withMessage: aString
enter a debugger

o  enter: aContext withMessage: aString mayProceed: mayProceed
enter a debugger; if this is a recursive invocation, enter
a MiniDebugger instead.
This is the standard way of entering the debugger;
sent from error- and halt messages.

o  enterException: ex
enter a debugger; if this is a recursive invocation, enter
a MiniDebugger instead.
This is the standard way of entering the debugger;
sent from error- and halt messages.

o  enterUnconditional: aContext withMessage: aString mayProceed: mayProceed
enter a debugger - do not check for recursive invocation

o  enterWithMessage: message
enter a debugger

o  new
return a new DebugView.
- return a cached debugger if it already exists.
Also, care for remote displays on which no debugger is wanted
(ask with mayOpenDebugger) - if so, open on the default screen.

o  newExclusive
return a debugger for exclusive display access

o  openOn: aProcess
start a debugger on aProcess
(actually not more than a good-looking inspector)

menu specs
o  menuSpec
This resource specification was automatically generated
by the MenuEditor of ST/X.

misc
o  interestingContextFrom: aContext
return an interesting context to be shown in an error notifier.
We move up the calling chain, skipping intermediate Signal
and Exception contexts, to present the context in which the error
actually occured.
Just for your convenience :-)

o  interestingContextIndexIn: aContextArray
return an interesting contexts offset, or nil.
This is the context initially shown in the walkback.
We move up the calling chain, skipping all intermediate Signal
and Exception contexts, to present the context in which the error
actually occured.
Just for your convenience :-)

Instance protocol:

basic
o  enableDisableActions

o  enter: aContext select: initialSelectionOrNil
enter the debugger - get and display the context, then start an
exclusive event loop on top of eveything else

o  exit_abort
cannot simply raise an abort here, because if there is an abortHandler somewhere,

o  exit_abortAll
cannot simply raise an abort here, because if there is an abortHandler somewhere,

o  exit_quickTerminate

o  exit_restart

o  exit_return

o  exit_terminate
have to catch errors occuring in unwind-blocks

o  exit_unwindThenDo: aBlock

o  initialSelectionOnEntry: initialSelectionOrNil context: aContext

o  isInspecting

o  isNotInspecting

o  openOn: aProcess
enter the debugger on a process -
in this case, we are just inspecting the context chain of the process,
not running on top of the debugged process, but as a separate
one. (think of it as an inspector showing more detail, and offering
some more control operations)

o  setInitialSelectionOnEntry: initialSelectionOrNil context: aContext

o  turnOffAllButtons

help
o  flyByHelpDependsOnPositionIn: aView
subclasses where the help-text depends upon the pointer position might
want to redefine this

o  flyByHelpTextFor: aComponent

o  flyByHelpTextFor: aComponent at: aPointOrNil

o  helpTextFor: aComponent

initialization & release
o  addToCurrentProject
ignored here

o  destroy
closing the debugger implies an abort or continue

o  initialize

o  initializeAbortButtonIn: bpanel

o  initializeButtons1In: bpanel
creates the top button row, consisting of 'continue', 'abort', 'terminate'...

o  initializeButtons2In: bpanel
creates the second button row, consisting of 'next', 'step', 'return'...

o  initializeButtonsIn: bpanel

o  initializeCodeViewIn: panel

o  initializeContextListViewIn: panel

o  initializeContextViewsMiddleButtonMenu

o  initializeContinueButtonIn: bpanel

o  initializeDefineButtonIn: bpanel

o  initializeInspectorViewsIn: panel

o  initializeNextButtonIn: bpanel

o  initializeReportButtonIn: bpanel

o  initializeRestartButtonIn: bpanel

o  initializeReturnButtonIn: bpanel

o  initializeSendButtonIn: bpanel

o  initializeStepButtonIn: bpanel

o  initializeTerminateButtonIn: bpanel

o  postRealize

o  reinitialize
redefined - since the debugView runs on top of

o  setLabelFor: aMessage in: aProcess

interrupt handling
o  contextInterrupt

o  stepInterrupt

o  stepOrNext

menu & button actions
o  addBreakpoint
add a breakpoint on the selected contexts method - if any

o  addBrowserBookmark
add a browser-bookmark for the selected contexts method

o  allowBreakPointsInDebugger

o  allowBreakPointsInDebugger: aBoolean

o  autoRaiseView

o  autoRaiseView: aBoolean

o  autoUpdateOff
stop the update process

o  autoUpdateOn
fork a subprocess which updates the contextList in regular intervals

o  browseClass
browse the receiver's class (of the selected context's message)

o  browseClassHierarchy
browse the receiver's classHierarchy (of the selected context's message)

o  browseFullClassProtocol
browse the receiver's full protocol (of the selected context's message)

o  browseImplementingClass
browse the implementing class (of the selected context's message)

o  browseImplementors
open a browser on the implementors of the selected method's selector

o  browseImplementorsOf
open a browser on the implementors of some selector

o  browseProcessesApplication
browse the application class (of the process, if it is a GUI process)

o  browseReceiversClass
browse the receiver's class (of the selected context's message)

o  browseSenders
open a browser on the senders of the selected method's selector

o  browseSendersOf
open a browser on the senders of some selector

o  copyWalkbackText
place the contents of the walkback view into the copy-paste buffer.
This allows pasting it into some other view for printing ...

o  doAbort
abort - send Object>>abortSignal, which is usually caught
at save places (for example: in the event loop) and returns back
from whatever the process is doing, but does not terminate it.

o  doAbortAll
abortAll - send Object>>abortAllSignal, which is usually caught
at save places (for example: in the event loop) and returns back
from whatever the process is doing, but does not terminate it.

o  doContinue
continue from menu

o  doDefine

o  doIgnoreBreakpoints

o  doMicroSend
single send; reenter with next message send

o  doNext
skip for next source-code line; entering blocks

o  doNextOut
skip for next source-code line; leaving blocks

o  doNextOver
skip for next source-code line; skip over blocks

o  doNoTrace

o  doNotIgnoreBreakpoints

o  doOpenReportMailApp
open a mail report tool

o  doRestart
restart - the selected context will be restarted

o  doReturn
return - the selected context will do a ^nil

o  doSend
single send; reenter with next message send

o  doStep
skip for next send in selected method

o  doStep: lineNr
common helper for step, skip & next.
Arrange for single-steppping until we pass lineNr (if nonNil)
or to next line (if nil) or to next send (if -1)

o  doStop
stop the process (if its running, otherwise this is a no-op)

o  doTerminate
terminate - the process has a chance for cleanup

o  doTrace
tracing - not really implemented ...

o  doTraceStep
tracestep - not implemented yet

o  exit
exit from menu: immediate exit from smalltalk

o  hasHaltsToIgnore

o  ignoreHaltForever

o  inspectContext
launch an inspector on the currently selected context

o  isStoppedAtHaltOrBreakPoint

o  middleButtonMenu

o  openAboutThisApplication
opens an about box for this application.

o  openIgnoreHaltNTimesDialog

o  openIgnoreHaltUntilTimeElapsedDialog

o  openSettingsDialog

o  quickTerminate
quick terminate - the process will get no chance for cleanup actions

o  removeAllBreakpoints
remove all trace & breakpoints - if any

o  removeBreakpoint
remove breakpoint on the selected contexts method - if any

o  showDenseWalkback

o  showMore
double the number of contexts shown

o  showVerboseWalkback

o  showingDenseWalkback

o  showingVerboseWalkback

o  skip
skip for cursor line in selected method

o  skipForReturn
skip until the selected context is left.

o  skipUntilEntering
skip until some particular method is invoked.

o  stopIgnoringHalts

o  toggleVerboseWalkback

private
o  abortAllIsHandled

o  addIgnoredHaltForCount: countOrNil orTimeDuration: dTOrNil

o  busy

o  canAddBreakpoint

o  canBrowseClassHierarchy

o  canBrowseFullClassProtocol

o  canBrowseImplementingClass

o  canBrowseProcessesApplication

o  canBrowseReceiversClass

o  canDefineMethod

o  canRemoveBreakpoint

o  canRestart

o  canReturn

o  canShowMore

o  contextListEntryFor: aContext

o  exclusive: aBoolean

o  explainSelection

o  findHaltingContext

o  findNodeForInterval: interval

o  findNodeIn: tree forInterval: interval

** This is an obsolete interface - do not use it (it may vanish in future versions) **

o  goodSkipUntilSelector

o  haltSelectors

o  hasContextSelected

o  ignoreBreakpoints

o  inspectedProcess

o  interruptProcessWith: aBlock
let inspected process do something, then update the context list

o  mayProceed: aBoolean

o  openHTMLDocument: anHTMLFilename
open a HTMLDocumentView on anHTMLFilename

o  processPerform: aMessage
do something, then update the context list

o  redisplayBacktrace
force redisplay of the walkBack list; invoked when the
verbose-flag setting is changed

o  selectedInterval

o  showError: message

o  showTerminated

o  showValue: aValue
TODO: show value in info field

o  stepping

o  unstep

o  updateContext

o  withNodeValueAtInterval: interval do: aBlock

private queries
o  isAborting

o  isHaltToBeIgnored

o  setOfHiddenCallingSelectors

o  setOfHiddenCallingSelectors: aCollectionOfSymbols

private-cache handling
o  cacheMyself
remember myself for next debug session

o  isCached
tell wether we are a cached debugger

o  releaseDebuggee
We have to be careful to release all refs to the debuggee,
because we may be in the cache.
Otherwise, the GC will not be able to release it

o  uncacheMyself
do not remember myself any longer for next debug session

private-context handling
o  setContext: aContext
show calling chain from aContext in the walk-back listview

o  setContext: aContext releaseInspectors: releaseInspectors
show calling chain from aContext in the walk-back listview.
Most complications here arise from filtering less-interesting contexts
if not in verbose-context mode.

o  setContextSkippingInterruptContexts: aContext
show calling chain from aContext in the walk-back listview.
Ignore any non-interesting interrupt-context.

o  showingContext1: aContext calling: calledContext
return false, if this (top) context is to be skipped.
Here, we hide some well known methods, which are usually not too interesting;
the set of methods which are suppressed is my (claus's) own choice.

o  showingContext2: aContext nesting: nesting
return false, if this (intermediate) context is to be skipped.
Here, we hide some well known methods, which are usually
not too interesting;
the set of methods which are suppressed is my (claus's) own choice.

private-control loop
o  controlLoop
this is a kludge:
start a dispatchloop which exits when
either continue, return or step is pressed

o  controlLoopCatchingErrors
this is the debuggers own private event handling loop;
errors are caught, to prevent recursive debugger-invocations.

user interaction
o  checkIfCodeIsReallyModified

o  checkSelectionChangeAllowed

o  checkSelectionChangeAllowed: newSelection

o  codeAccept: someCode
user wants some code to be recompiled - must unwind stack since everything above
and including selected method cannot be continued.

o  codeAccept: someCode inClass: aClass unwind: doUnwind category: category onCancel: cancelAction
user wants some code to be recompiled - must unwind stack since everything above
and including selected method cannot be continued.

o  codeAccept: someCode unwind: doUnwind category: givenCategoryOrNil onCancel: cancelAction
user wants some code to be recompiled - must unwind stack since everything above
and including selected method cannot be continued.

o  codeCompletion

o  confirm: aString
open a modal yes-no dialog.
Redefined here, to answer true, if exclusice Debugger, which cannot handle popup boxes

o  doShowSelection: lineNr
user clicked on a header line - show selected code in textView.
Also sent to autoselect an interesting context on entry.

o  hideStackInspector

o  processEvent: anEvent
filter keyboard events for popUp variable value display.
Return true, if I have eaten the event

o  setCurrentMethod: aMethodOrNil

o  showSelection: lineNr
user clicked on a header line - show selected code in textView.
Also sent to autoselect an interesting context on entry.

o  showStackInspectorFor: con

o  updateForContext: lineNr
show selected code for lineNr in contextList in textView.
Also used to autoselect an interesting context on entry.

o  updateMenuItems

Private classes:

    IgnoredHalt

ST/X 6.1.1; WebServer 1.620 at exept:8081; Mon, 21 May 2012 15:56:08 GMT