Smalltalk/X Webserver

Documentation of class 'DebugView':

Class: DebugView

Inheritance
Description
Related information
Class protocol
Instance protocol
Private classes

Inheritance:

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

Package:: stx:libtool

Category:: Interface-Debugger

Version:: rev: 1.810 date: 2019/07/02 19:52:58; 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

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
     DebugView withAllSubclassesDo:#newDebugger

defaults

debuggerOnMainDisplayOnly
defaultIcon: return the browsers default window icon
defaultIconForAboutBox
defaultVerboseBacktrace: ** This is an obsolete interface - do not use it (it may vanish in future versions) **
defaultVerboseBacktrace: aBoolean
maxNumberOfDebuggers: to prevent debuggers from flooding the screen,
in case of an error in an ever-forked background process
(such as tooltip process)
updateStyleCache: extract values from the styleSheet and cache them in class variables

ignoring halts

haltIgnoreInformationFor: haltingMethod atLineNr: lineNrInHaltingMethod: the information (if any) about the ignore-state of a halt
hasIgnoredHalts
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
ignoreErrorIn: methodOrNil line: lineNrOrNil forCount: countOrNil orTimeDuration: dTOrNil orUntilShiftKey: untilShiftKey orReceiverClass: receiverClassOrNil orProcess: processOrNil orIfCalledFromMethod: ifCalledFromMethodOrNil: remember to ignore an error, either forEver, for some number of invocations
or until some time has elapsed.
With nil count and time arguments, such an ignored error is reactivated
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
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
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
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
isBreakpointToBeIgnoredForParameter: parameter context: aContext modifyEntryCount: modifyCount: should a breakpoint be ignored ?
isErrorToBeIgnoredIn: errorMethod atLineNr: lineNrInErrorMethod context: aContext modifyEntryCount: modifyCount: should an error be ignored ?
isHaltToBeIgnoredIn: haltingMethod atLineNr: lineNrInHaltingMethod context: aContext modifyEntryCount: modifyCount: should a halt be ignored ?
removeInactiveErrors: removes ignores for methods which are no longer present
removeInactiveIgnores: removes ignores for methods which are no longer present
stopIgnoringHalts: forget about all ignored halts
stopIgnoringHaltsFor: haltingMethod atLineNr: lineNrInHaltingMethod: remove the information (if any) about the ignore-state of a halt;
effectively reenables the breakpoint/halt

initialization

initialize: DefaultDebuggerBackgroundColor := nil.
reinitialize: reinitialize after an image-restart

instance creation / entering

enter: enter a debugger
enter: aContext withMessage: aString: enter a debugger
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.
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.
enterUnconditional: aContext withMessage: aString mayProceed: mayProceed: enter a debugger - do not check for recursive invocation
enterWithMessage: message: enter a debugger
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.
newExclusive: return a debugger for exclusive display access
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
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
openOn: aProcess: start a debugger on aProcess
(actually not more than a good-looking inspector)

menu specs

breakPointMenuSpec