eXept Software AG Logo

Smalltalk/X Webserver

Documentation of class 'DebugView':

Home

Documentation
www.exept.de
Everywhere
for:
[back]

Class: DebugView


Inheritance:

   Object
   |
   +--GraphicsMedium
      |
      +--DisplaySurface
         |
         +--SimpleView
            |
            +--View
               |
               +--TopView
                  |
                  +--StandardSystemView
                     |
                     +--DebugView

Package:
stx:libtool
Category:
Interface-Debugger
Version:
rev: 1.770 date: 2018/05/17 19:58:26
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.

 The whole setup might 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).
 However, as it works as it is, and is reliable enough,
 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 to this 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.

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

Notice & Warning (attention when changing things like menus, window spec etc. here):
    the DebugView class caches the last used debugger in a class variable,
    and hides/shows this window without recreating one from scratch. This is done to make
    the debugger come up faster when single stepping, or hopping from breakpoint to breakpoint.

    It may happen, that a malfunctioning debugger (for example, a halfway created/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 should be fixed to avoid this situation.

    You must also flush the cached debugger, if you change the debugger's
    initialization code (buttons, menu, etc.) or the debugger's class layout,
    and you want the new code to become effective 
    (otherwise, the already instantiated, cached debugger will be reused).


Related information:

    Exception
    Signal
    Process

Class protocol:

cleanup
o  lowSpaceCleanup
in low memory situations, give up cached debuggers
usage example(s):
     DebugView lowSpaceCleanup

o  newDebugger
force creation of a new debugger (give up cached debuggers).
Call this, if you changed the debugger heavily, and you want to avoid
that an old, cached debugger gets reused when the next error comes around.
usage example(s):
     DebugView newDebugger

defaults
o  debuggerOnMainDisplayOnly

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

o  maxNumberOfDebuggers
to prevent debuggers from flooding the screen,
in case of an error in an ever-forked background process
(such as tooltip process)

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  ignoreBreakpointWithParameter: parameterOrNil forCount: countOrNil orTimeDuration: dTOrNil orUntilShiftKey: untilShiftKey orReceiverClass: receiverClassOrNil orProcess: processOrNil
remember to ignore a breakpoint with a parameter (i.e. breakpoint:#cg) for some number of invocations
or until some time has elapsed.
With nil count and time arguments, such an ignored breakpoint is reactivated

o  ignoreHaltIn: haltingMethod at: lineNrOfHalt forCount: countOrNil orTimeDuration: dTOrNil orUntilShiftKey: untilShiftKey orReceiverClass: receiverClassOrNil orProcess: processOrNil
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  ignoreHaltIn: haltingMethod at: lineNrOfHalt forCount: countOrNil orTimeDuration: dTOrNil orUntilShiftKey: untilShiftKey orReceiverClass: receiverClassOrNil orProcess: processOrNil orIfCalledFromMethod: ifCalledForMethodOrNil
remember to ignore a halt in some method for some number of invocations
or until some time has elapsed.
With a count of -1, it is ignored forever (i.e. until reenabled via the
settings).
With nil count and time arguments, such an ignored halt is reactivated

o  ignoreHaltOrBreakpoint: type method: methodOrNil line: lineNrOfHaltOrNil parameter: parameterOrNil forCount: countOrNil orTimeDuration: dTOrNil orUntilShiftKey: untilShiftKey orReceiverClass: receiverClassOrNil orProcess: processOrNil
remember to ignore a breakpoint with a parameter (i.e. breakpoint:#cg) for some number of invocations
or until some time has elapsed.
With nil count and time arguments, such an ignored breakpoint is reactivated

o  ignoreHaltOrBreakpoint: type method: methodOrNil line: lineNrOfHaltOrNil parameter: parameterOrNil forCount: countOrNil orTimeDuration: dTOrNil orUntilShiftKey: untilShiftKey orReceiverClass: receiverClassOrNil orProcess: processOrNil orIfCalledFromMethod: ifCalledFromMethodOrNil
remember to ignore a breakpoint with a parameter (i.e. breakpoint:#cg) for some number of invocations
or until some time has elapsed.
With nil count and time arguments, such an ignored breakpoint is reactivated

o  isBreakpointToBeIgnoredForParameter: parameter context: aContext modifyEntryCount: modifyCount
should a breakpoint be ignored ?

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

o  removeInactiveIgnores

o  stopIgnoringHalts
forget about all ignored halts

o  stopIgnoringHaltsFor: haltingMethod atLineNr: lineNrInHaltingMethod
remove the information (if any) about the ignore-state of a halt;
effectively reenables the breakpoint/halt

initialization
o  initialize
DefaultDebuggerBackgroundColor := nil.

o  reinitialize
reinitialize after an image-restart

instance creation / entering
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  openDebuggerForActiveProcess
return an already open debugger for the active process, or nil, if there is none.
Open debuggers exist when stepping only, as then, the debugger is left open until the step
is reached, to avoid too much flickering and redrawing on the screen

o  openDebuggerForProcess: aProcess
if aProcess is being debugged and has an open debugger on it,
then return it, or nil, if there is none.
Open debuggers also exist as unmapped windows when single-stepping

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

menu specs
o  breakPointMenuSpec
This resource specification was automatically generated
by the MenuEditor of ST/X.
usage example(s):
     MenuEditor new openOnClass:DebugView andSelector:#breakPointMenuSpec
     (Menu new fromLiteralArrayEncoding:(DebugView breakPointMenuSpec)) startUp

o  classMenuSpec
This resource specification was automatically generated
by the MenuEditor of ST/X.

o  contextMenuSpec
This resource specification was automatically generated
by the MenuEditor of ST/X.
usage example(s):
     MenuEditor new openOnClass:DebugView andSelector:#contextMenuSpec
     (Menu new fromLiteralArrayEncoding:(DebugView contextMenuSpec)) startUp

o  fileMenuSpec
This resource specification was automatically generated
by the MenuEditor of ST/X.
usage example(s):
     MenuEditor new openOnClass:DebugView andSelector:#fileMenuSpec
     (Menu new fromLiteralArrayEncoding:(DebugView fileMenuSpec)) startUp

o  helpMenuSpec
This resource specification was automatically generated
by the MenuEditor of ST/X.
usage example(s):
     MenuEditor new openOnClass:DebugView andSelector:#helpMenuSpec
     (Menu new fromLiteralArrayEncoding:(DebugView helpMenuSpec)) startUp

o  menuSpec
This resource specification was automatically generated
by the MenuEditor of ST/X.
usage example(s):
     MenuEditor new openOnClass:DebugView andSelector:#menuSpec
     (Menu new fromLiteralArrayEncoding:(DebugView menuSpec)) startUp

o  processMenuSpec
This resource specification was automatically generated
by the MenuEditor of ST/X.
usage example(s):
     MenuEditor new openOnClass:DebugView andSelector:#processMenuSpec
     (Menu new fromLiteralArrayEncoding:(DebugView processMenuSpec)) startUp

o  selectorMenuSpec
This resource specification was automatically generated
by the MenuEditor of ST/X.
usage example(s):
     MenuEditor new openOnClass:DebugView andSelector:#selectorMenuSpec
     (Menu new fromLiteralArrayEncoding:(DebugView selectorMenuSpec)) startUp

o  viewMenuSpec
This resource specification was automatically generated
by the MenuEditor of ST/X.
usage example(s):
     MenuEditor new openOnClass:DebugView andSelector:#viewMenuSpec
     (Menu new fromLiteralArrayEncoding:(DebugView viewMenuSpec)) startUp

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 occurred.
Just for your convenience :-)

o  interestingContextIndexIn: aContextArray
return an interesting context's index, or nil.
This is the context initially shown (selected) 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 occurred.
Just for your (my) convenience :-)

o  withDebuggingFlagSetDo: aBlock
mark this process as a process executing a debugger.
This can be used to not delay on certain operations (e.g. Lazy and Bridge proxies.

utilities
o  withOptionToIgnoreException: exceptionOrHandlerSet do: aBlock
execute aBlock;
if any from exceptionOrHandlerSet is raised during the execution,
open a confitmation dialog, asking if the debugger should be entered.
For halts/breakpoints, honors the ignored halt/break list;
also, two checkboxes are added, to also ignore them in the future


Instance protocol:

accessing
o  contextInspector

o  inspectedProcess

aspects
o  verboseBacktraceHolder

basic
o  enableDisableActions

o  enter
enter a debugger

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_resend
have to catch errors occuring in unwind-blocks

o  exit_restart
have to catch errors occuring in unwind-blocks

o  exit_return
if there is a selection in the codeView,
evaluate it and use the result as return value

o  exit_terminate
have to catch errors occuring in unwind-blocks

o  exit_unwindThenDo: aBlock
cannot simply raise an abort here, because if there is an abortHandler somewhere,

o  initialSelectionOnEntry: initialSelectionOrNil context: aContext
and find the one context to show initially
- if we came here by a send (single step), its the top context;
- if we came here by a step (i.e. bigStep), its the top context
(for ifs and whiles) or the sender (for regular sends).
- otherwise, we came here by some signal raise, and we are interested
in the context where the raise actually occurred.

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  selectContextWithIndex: index

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.
In the codeView, we follow the token under the mouse pointer...

o  helpTextFor: aComponent
s := 'Abort (unwind to eventLoop)'

o  helpTextFor: aComponent at: aPointOrNil
some heuristics as when to show the class name (a purely subjective preference)

initialization & release
o  addToCurrentProject
ignored here

o  destroy
closing the debugger implies an abort or continue

o  destroyWithConfirmation: withConfirmation
closing the debugger implies an abort or continue

o  initialize
panel showHandle:true.

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
cg:

o  initializeCodeViewIn: panel
for active help

o  initializeContextListViewIn: panel

o  initializeContextViewsMiddleButtonMenu

o  initializeContinueButtonIn: bpanel

o  initializeDefineButtonIn: bpanel

o  initializeFlags
ignore halts/breakpoints in doIts of

o  initializeGotoApplicationActionMethodButtonIn: bpanel

o  initializeGotoDialogOpenerButtonIn: bpanel

o  initializeGotoRaisingMethodButtonIn: bpanel

o  initializeInspectorViewsIn: panel

o  initializeNextButtonIn: bpanel

o  initializeReportButtonIn: bpanel

o  initializeResendButtonIn: bpanel
if we have this, we do not need the restart button

o  initializeRestartButtonIn: bpanel

o  initializeReturnButtonIn: bpanel

o  initializeSendButtonIn: bpanel

o  initializeStepButtonIn: bpanel

o  initializeStepInButtonIn: bpanel

o  initializeTerminateButtonIn: bpanel
terminateButton foregroundColor:Color red.

o  postRealize
set prio somewhat higher (by 2, to allow walkBack-update process
to run between mine and the debugged processes prio)

o  reinitialize
redefined - since the debugView runs on top of

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  setLabelFor: errorDescriptionMessage in: aProcess

interrupt handling
o  contextInterrupt

o  stepInterrupt
' in ' print. thisContext sender fullPrint.

o  stepOrNext
DebuggingDebugger := true

menu & button actions
o  addBrowserBookmark
add a browser-bookmark for the selected contexts method

o  autoRaiseView

o  autoRaiseView: aBoolean

o  autoUpdateOff
stop the update process

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

o  browseBlocksHome
browse the receiver block's home method (if a value-like send is selected)

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  clearRememberedCallchain
clear the remembered callchain.

o  closeAllDebuggers

o  configureX: x y: y width: newWidth height: newHeight
(comment from inherited method)
my size has changed by window manager action

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

Show the full verbose context without filtering.

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

Show the full verbose context without filtering.

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

Show the full verbose context without filtering.

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  doAbortWithoutConfirmation
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  doChangeProcessPriority
ask for and change the process's priority

o  doContinue
continue from menu

o  doContinueAfterDelay

o  doDefine
when we hit an unimplemented message, the define button becomes visible.
This is the action of it, when clicked.
Define a new halting method in the faulting class,
and restart the context so we end up in the halt of the new method

o  doGotoApplicationActionMethod
select the first application-model context.
This is another great helper, when you hit an exception,
to quickly navigate to the responsible code of you application

o  doGotoDialogOpener
select the context where the dialog was opened.
This is a great helper, when you press interrupt while a modal dialog is open,
to quickly navigate to the corresponding opening code of your application

o  doGotoRaisingMethod
select the (next) context where the exception was raised.
This is a great helper, when you press interrupt while a modal dialog is open,
to quickly navigate to the corresponding opening code of your application

o  doInspectProcess

o  doMicroSend
single send; reenter with next message send

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

o  doNextAfterDelay

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

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

o  doNoTrace

o  doOpenReportMailApp
open a mail report tool

o  doRedefineMethodInReceiverClass

o  doResend
resend - the selected context is unwound and its message resent.
To be done after a cde change, to get nto the new method

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: lineNrOrNilOrMinus1
common helper for step, skip & next.
Arrange for single-stepping until we pass lineNr (if nonNil)
or to next line (if nil) or to next send (if -1)

o  doStepAfterDelay

o  doStepIn
skip for next send in selected method

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

o  doStop
stop the process (if it's 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  findContextForWhich: aBlock thenDo: additionalAction

o  findContextWithStringInSource

o  findContextWithValueInVariable

o  findHandlerFor

o  findHomeContext
still have to find it - home could be elsewhere (another process)

o  findNextExceptionHandlerContext

o  inspectContext
launch an inspector on the currently selected context

o  inspectContextsMethod
launch an inspector on the currently selected context's method

o  inspectProcessesApplication
inspect the application (of the process, if it is a GUI process)

o  inspectWidgetHierarchy

o  middleButtonMenu
('Continue' doContinue )
('Terminate' doTerminate )
('Abort' doAbort )
('-' )
('Step' doStep )
('Send' doSend )
('-' )
('Return' doReturn )
('Restart' doRestart )
('-' )

o  notShowingDenseWalkbackHolder

o  notShowingSupportCode

o  openAboutThisApplication
opens an about box for this application.

o  openSettingsDialog

o  processesApplication
if the debugged process is a GUI process,
AND it has an applicaiton, return it.
Otherwise, return nil

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

o  rememberCallchain
remember the callchain in a classvar.
When entered the next time, highlight already entered contexts.
This makes it possible to identitfy the caller as the first common context
along the chain (i.e. the context which is responsible for the debugger to be entered)

o  selectContext: aContext
some contexts hidden?

o  selectedContext

o  showFullWalkback
double the number of contexts shown

o  showMore
double the number of contexts shown

o  showSupportCode

o  showingDenseWalkback

o  showingDenseWalkback: aBoolean

o  showingDenseWalkbackHolder

o  showingSupportCode

o  showingSupportCode: aBoolean

o  showingVerboseWalkback

o  sizeChanged: how
(comment from inherited method)
tell subviews that I changed size.
How is either #smaller, #larger or nil, and is used to control the order,
in which subviews are notified (possibly reducing redraw activity)

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  toggleShowSupportCode

o  toggleVerboseWalkback

o  updateMenuItems
enable/disable some menu items, depending on the current selected context

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

o  allowBreakPointsInDebugger

o  allowBreakPointsInDebugger: aBoolean

o  doIgnoreBreakpoints

o  doNotIgnoreBreakpoints

o  ignoreAllHaltsForCurrentProcess

o  ignoreAllHaltsForThisReceiverClass

o  ignoreAllHaltsForever

o  ignoreAllHaltsIfCalledFromMethod: aMethod

o  ignoreAllHaltsUntilShiftKeyIsPressed

o  ignoreBreakpointsWithThisParameterForever
self addIgnoredHaltForCount:-1 orTimeDuration:nil orUntilShiftKey:false forAll:false.

o  ignoreBreakpointsWithThisParameterUntilShiftKeyIsPressed

o  ignoreHaltForCurrentProcess

o  ignoreHaltForThisReceiverClass

o  ignoreHaltForever

o  ignoreHaltIfCalledFromMethod: aMethod

o  ignoreHaltUntilShiftKeyIsPressed

o  menuForIgnoreAllBreakpointsIfCalledFromAnyOf

o  menuForIgnoreBreakpointIfCalledFromAnyOf

o  menuForIgnoreBreakpointIfCalledFromAnyOfForAll: forAllHaltsBoolean

o  openBreakPointBrowser

o  openIgnoreAllHaltsUntilTimeElapsedDialog

o  openIgnoreBreakpointsWithThisParameterNTimesDialog

o  openIgnoreBreakpointsWithThisParameterUntilTimeElapsedDialog

o  openIgnoreHaltNTimesDialog

o  openIgnoreHaltUntilTimeElapsedDialog

o  removeAllBreakpoints
remove all trace & breakpoints - if any

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

o  stopIgnoringHalts

private
o  abortAllIsHandled

o  busy

o  exclusive: aBoolean

o  explainSelection

o  findNodeForInterval: interval
source := currentMethod notNil
usage example(s):
^ DoWhatIMeanSupport findNodeForInterval:interval in:(source string).

o  findNodeIn: tree forInterval: interval
|node|

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

o  goodSkipUntilSelector

o  haltSelectors
Modified (format): / 27-01-2012 / 11:10:00 / cg

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
consider this a kludge:

o  showTerminated

o  showValue: aValue
TODO: show value in info field

o  stepping

o  unstep

o  updateButtonsAndMenuItemsForContext: aContext

o  updateContext

o  withNodeValueAtInterval: interval do: aBlock
helper for tooltops and explan-selection

private queries
o  canBrowseClassHierarchy

o  canBrowseFullClassProtocol

o  canBrowseImplementingClass

o  canBrowseProcessesApplication

o  canBrowseReceiversClass

o  canCloseAllDebuggers

o  canDefineMethod

o  canInspectWidgetHierarchy

o  canRedefineMethodInReceiverClass
true if a context is selected, where an inherited method was called.
Used to enable the redefine menu option

o  canRestart

o  canReturn

o  canSendEmail

o  canShowMore

o  hasBlockContextSelected

o  hasContextSelected

o  hasHaltsToIgnore

o  isAborting

o  isStoppedAtBreakPointWithParameter

o  isStoppedAtHaltOrBreakPoint

o  isStoppedAtHaltOrBreakPointOrSelectedContextIsWrapped

o  selectedContextIsWrapped

o  setOfHiddenCallingSelectors

o  setOfHiddenCallingSelectors: aCollectionOfSymbols

private-breakpoints
o  addIgnoredHaltForCount: countOrNil orTimeDuration: dTOrNil orUntilShiftKey: untilShiftKey orThisReceiverClass: forThisReceiverClass orCurrentProcess: forCurrentProcess orIfCalledFromMethod: ifCalledForMethodOrNil forAll: aBoolean

o  canAddBreakpoint

o  canRemoveBreakpoint

o  findHaltingContext

o  ignoreBreakpoints

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

o  isCached
tell whether we are a cached debugger

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

private-code generation helpers
o  argumentNamesForNewMethodOfContext: context
generate argument names for a prototypeMethod for the message in context.
Used by doDefine and doRedefine

private-code view
o  codeAspect

private-context handling
o  contextListEntryFor: aContext

o  is: aHomeContext inCallingChainOf: aContext

o  isEnteredDueToBreakpointOrHalt
see if we came here due to a step interrupt

o  isHaltToBeIgnored
see if the current halt (if any) is in the ignore-list

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 or when hiding implementation contexts.
There is a lot of heuristic magic here, to make the debugger as useful
as possible for the user (but not particularly for the debugger-developer).
On the fly, as we move along the contexts, update the isStoppedAtXXX booleans.

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.

queries
o  canDefineForCallee: callee
again, pure heuristics here

o  showingAlreadyModifiedCode

testing
o  isDebugView

user interaction
o  checkIfCodeIsReallyModified

o  checkIfCodeIsReallyModifiedAndConfirmWith: questionString
if code was not modified or confirmation answered with 'ok',
return true (i.e. whatever user wants to do should be done).
Otherwise, return false

o  checkSelectionChangeAllowed

o  checkSelectionChangeAllowed: newSelection

o  codeAccept: someCode
user wants some code to be recompiled

o  codeAccept: someCode inClass: aClass unwind: doUnwind category: category onCancel: cancelAction
user wants some code to be recompiled.
Optionally unwind stack to right above the changed method.
This undwind option is a leftover from times, when the debugger had no chance to
show the original code.
Now, it can, and got a choice-field to select between original and changed code.
So the undwind option is not longer used and probably completely obsolete now
(aka: this method is always called with doUnwind==false, these days)

o  codeAccept: someCode unwind: doUnwind category: givenCategoryOrNil onCancel: cancelAction
user wants some code to be recompiled

o  codeCompletion
I found this code 3 times (CodeView2, NewSystemBrowser and DebugView) - smell?

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  methodCodeToggleChanged

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  updateContextInfoFor: aContext
additional info as-per selected context;
for now:
update:with:from: - show who was responsible

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


Private classes:

    IgnoredBreakpoint
    IgnoredHalt
    IgnoredHaltOrBreakpoint


ST/X 7.1.0.0; WebServer 1.663 at exept.de:8081; Mon, 19 Nov 2018 01:28:51 GMT