[wingide-users] Missing breakpoints & projects
tms at zeetix.com
Mon Sep 3 09:39:04 MDT 2007
>> The bug/feature/phenomena occurs when I do the following:
>> 1. Open projectA.
>> 2. During debugging, open class B.Foo, contained in projectB.
>> 3. Set a breakpoint somewhere in B.Foo
>> 4. Save projectA.
>> 5. Terminate the current debugging thread
>> 6. Open projectB.
>> 7. Start a new thread, hoping to stop on the breakpoint created at step
>> To my surprise, the thread created in step 7 will NOT stop. This is
>> it appears that the breakpoint I created is visible only to projectA.
> This is because breakpoint definitions are stored in the project file.
> Switching projects clears the breakpoint list and replaces it with the
> ones defined in the newly loaded project file.
> Project files are text files, containing python code. The structure
> defining breakpoints is called 'debug.breakpoints', at least in my
> current Wing 3 project files.
Aha. As nearly as I can tell, this is not mentioned in any of the
documentation. I just read through section 3.3 "Project Manager" and section
3.6 "Debugger", and found no discussion of this. Surely this is at least a
Further, I think that this "per-project" breakpoint behavior, if desired at
all, should surely be optional and should surely NOT be the default. A
"breakpoint" is all about a particular method in a particular *file*.
Fortunately, there is not one file per project. In my view, the most
intuitive (and therefore useful) decision is to have one breakpoint
definition per file. When I click in the margin to set a breakpoint, I'm
surely don't want to think about what project contains it, do I?
This is particularly true given the ease with which one can open and close
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 it
change the definition list in the project that created it, or does it
instead change the currently-open project?
It seems to me that per-project breakpoint definitions create a host of
user-interface and useability problems, with little corresponding
More information about the wingide-users