[wingide-users] Missing breakpoints & projects
tms at zeetix.com
Mon Sep 3 11:19:56 MDT 2007
----- Original Message -----
From: "Martijn Pieters" <mj at zopatista.com>
To: "Tom Stambaugh" <tms at zeetix.com>
Cc: <wingide-users at wingware.com>
Sent: Monday, September 03, 2007 12:22 PM
Subject: Re: [wingide-users] Missing breakpoints & projects
>> This is particularly true given the ease with which one can open and
>> various project files while debugging. Does the "Breakpoints" tab of the
>> "Wing Tool Box" show what is actually happening, or does it show the
>> definitions in whatever project is open? When I have a file open, does
>> change the definition list in the project that created it, or does it
>> instead change the currently-open project?
> I am not entirely sure what you are saying here. The breakpoints tab
> shows project-wide breakpoints, so the list should change when you change
> projects, regardless of whether a file is shared between different
> Different use cases have different needs.
Here are at least two use cases to consider.
Suppose the debugger is active, with a debugging thread open, halted at a
breakpoint (the "Stop" icon is lit), and with the breakpoint definitions in
some "projectA" in place. Suppose some "ClassB" is a class in some
"projectB". I discover, in looking at the current code, that a bug is likely
to be in some method "ClassB.foo". Suppose ClassB.foo will be executed with
the thread is continued.
Use case 1. I use the file menu to open the source of ClassB. Note that it
is not in the active project ("projectA"). I navigate to ClassB.foo and set
a breakpoint. I now open projectB, making projectB the active project.
Use case 2. I use the project menu to open projectB. I navigate to the
"Project" tab and open ClassB from it. I navigate to ClassB.foo and set a
For each use case:
A: What should happen to the screen when I change projects (what windows
open, what windows close, etc)
B: What should happen when I click the "Debug" button (ie, should the thread
stop at the new breakpoint)
C: What should appear when I open the "Breakpoint" tab of projectB?
> You use projects in quite a different way from what I use, you use it to
> look at subsets of a larger project, and expect your breakpoints to
> persist in that context.
> I use projects to define a discrete set of code that forms one
> application (usually a particular site for a customer), where a large
> body of code is reused between projects. I expect breakpoints to not
> pollute my other projects.
When you have two projects, each including the shared code, do you include
the shared code in those projects?
When you are debugging one customer's application and find a problem in the
shared code, what process do you follow to determine whether that same bug
also affects other customer applications? Have you tried actually changing
the projects on the fly? I ask because, at least on my v2.1.4-2, the
breakpoints leak from project to project anyway. The project seems to
attempt to remember whatever files are open, the breakpoints come with those
files, and that creates a leak when changing from project to project for an
More information about the wingide-users