[DrJava] [ drjava-Ease of use Issues-779032 ] Breakpoints Reached by Non-Interactions Window Threads

[SourceForge.net <no...@so...>]

Ease of use Issues item #779032, was opened at 2003-07-28 10:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=460211&aid=779032&group_id=44253

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Breakpoints Reached by Non-Interactions Window Threads

Initial Comment:
Hi.
I've noticed that breakpoints which are reached by
threads other than the single thread that manages
control flow for the  interactions window are not
respected and do not allow the user to pause execution
and step.  Is this by design? 

For instance, consider a breakpoint within a method
baker()  inside class Jones.  If the interactions
window creates an instance of Jones and invokes baker()
the breakpoint is reached, execution pauses, and the
user may step.  However,  if the interactions window
creates a new thread Wiess and Weiss's run method
creates an instance of Jones and invokes baker(), the
breakpoint is not reached, execution does not pause,
and the user may not step.

I'm a printf debugger by heart, so I don't use
breakpoints and such very often in other IDEs--so this
may very well be standard operating procedure in
general for a debugger, but I thought I would ask.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=460211&aid=779032&group_id=44253