This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 21784 - ToggleBreakpoint is usually ineffective
Summary: ToggleBreakpoint is usually ineffective
Alias: None
Product: obsolete
Classification: Unclassified
Component: externaleditor (show other bugs)
Version: 3.x
Hardware: Sun SunOS
: P3 blocker (vote)
Assignee: David Weatherford
Depends on: 17597
  Show dependency tree
Reported: 2002-03-21 19:01 UTC by David Weatherford
Modified: 2002-07-19 15:19 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description David Weatherford 2002-03-21 19:01:55 UTC
Shift-F8 in xemacs is supposed to behave like Shift-F8 in the built-in
editor, i.e., it should map to "Toggle Breakpoint".  It usually does
nothing but generates a message in the terminal window where you started
netbeans:  Warning: Action &Toggle Breakpoint is disabled; trying anyway.
Comment 1 David Weatherford 2002-03-21 19:13:57 UTC
The basic problem is that ToggleBreakpoint is enabled/disabled based
on the
focus being on a debuggable file in the built-in editor.  When using the
external editor, the NetBeans focus can be anywhere, and normally will not
be in the miniscule Source Editor window.

To work around this problem, we now requestFocus for the (dummy)
associated with the file which is open in the external editor whenever we
get an EVT_keyCommand.  This mostly works, but there is still a problem
when switching buffers in xemacs.  NetBeans gets no notification of buffer
switches, and there is some kind of race condition when we requestFocus()
on a pane which is not the current pane in the built-in editor that makes
the ToggleBreakpoint action happen in the *old* file.

This will all be fixed with the Actions re-work (see issue 17597).

Closing this issue and filing a new one for the "changing buffer" problem.
Comment 2 David Weatherford 2002-03-29 01:05:33 UTC
The fix is not viable, since focus behavior is dependent on
the window manager.

We need a solution that does not depend on focus behavior.
We need the new Actions framework.
Comment 3 Torbjorn Norbye 2002-03-29 20:06:41 UTC
Here's an alternative idea. (Which I don't like, but....)

Breakpoint Toggling in the editor is currently performed not
by the ToggleBreakpoint action, but by a breakpoint performer
that's written in the editor kit.

Since breakpoint toggling is critically important in usage of
the idea, for this release perhaps we can write our own breakpoint
toggler?  E.g. we add our own toggle breakpoint menu item, and
when it's run in emacs (or vim) the external editor knows which
data object this toggling is associated with (the current buffer
when the action was performed). Then we do the code
which achieves breakpoint toggling for that dataobject and line:
(This is from the java module's JavaEditor class) :

      /* This method is called when parent window of this component has focus,
        * and this component is preferred one in it. This implementation adds
        * performer to the ToggleBreakpointAction.
        protected void componentActivated () {
            try {
                final Debugger debugger = TopManager.getDefault ().getDebugger ();
                ((ToggleBreakpointAction) SystemAction.get (ToggleBreakpointAction.class)).
                setActionPerformer (new ActionPerformer () {
                                        public void performAction (SystemAction a) {
                                            int lineNumber = NbDocument.findLineNumber (
                                                        support.getDocument (),
                                                        getEditorPane ().getCaret ().getDot ()
                                            Line line = support.getLineSet ().getCurrent (lineNumber);
                                            synchronized (this) {
                                                Breakpoint breakpoint = debugger.findBreakpoint (line);
                                                if (breakpoint == null)
                                                    debugger.createBreakpoint (line);
                                                    breakpoint.remove ();
            } catch (DebuggerNotFoundException e) {

As you can see, it just looks up the Line object, checks with
the debugger if a breakpoint is located there, and if so, removes
it, otherwise adds one.
Comment 4 David Weatherford 2002-03-30 00:08:34 UTC
Good idea for the interim.  I have it almost working (it gets the line
number wrong), so
I'm hopeful that it'll work with a little more debugging.
Comment 5 David Weatherford 2002-04-01 21:12:41 UTC
Found the bug.  The hack now works.