toggle breakpoint support added

jgangemi wrote on Sat Aug  5 04:56:26 MEST 2006:

i've commited basic toggle breakpoint functionality to the 'testing' branch,
with  additional features/functionality already planned for later.

regexp breakpoints have also been disabled for the time being, see for further
details:
 http://sourceforge.net/forum/forum.php?thread_id=1532633&forum_id=258688).

that functionality will come back in some reincarnated form at a later date.

there are TODO tags in the code documenting where further features and/or
functionality needs to be added, should anyone feel adventureous. i used
the jdt code as a working example and reference point.

jploski wrote on Sat Aug  5 17:21:38 MEST 2006:

Your committed changes break compatibility with Eclipse 3.1. See the other
thread...

jgangemi wrote on Sat Aug  5 18:55:23 MEST 2006:

*smacks head*

do you know what it specifically breaks? perhaps there is an easy work around
i can put it for now. 

jploski wrote on Sat Aug  5 19:30:01 MEST 2006:

It does not compile because there is no class
org.eclipse.debug.ui.actions.RulerBreakpointAction
in 3.1.

jgangemi wrote on Sat Aug  5 19:58:48 MEST 2006:

ok - i just did a direct cut and paste of the class, so hopefully that will
work as a temporary stop gap until 3.1 support is decided.

i will pay better attention to classes i may interact w/ and/or subclass
going forward.

jploski wrote on Sat Aug  5 20:27:32 MEST 2006:

This solves the compilation problem and the double-click toggle works well.
However, I can still see some other issues:

1. The action Enable/Disable Breakpoint (from the popup menu) is no longer
working, throws exceptions instead. It seems that you removed this action's
implementation?

2. The disabled content of the breakpoint Properties dialog is misleading.
The options that are not implemented should not appear in the UI at all.

3. You added a few "auto-generated catch blocks" around the code. These
will certainly not handle exceptions, so I wonder about their intent. Can
these exceptions occur? If so, they should be logged and the client should
be notified about the failure. If not, it should be pointed out in a comment
explicitly (logging just in case is also worth considering).

4. You added an uncommented class PerlDebugModel with two static methods.
As it stands, the name of this class seems strange (could be that you intend
to evolve it into something in the future).

jgangemi wrote on Sat Aug  5 21:09:23 MEST 2006:

1) *sigh* and *smack* - classes that exist in 3.2 but do not exist in 3.1.
i didn't notice the @since 3.2 tags when i switched over to using them,
replacing the same implementations we already had (this is definately a
developer arguement for moving to 3.2)

2) i will disable the rendering of that portion of the properties.

3) these exceptions all come from accesing line marker information. i was
being lazy w/ those auto inserted try/catches and they will be cleaned up
- in the mean time, they shouldn't cause any harm.

4) again, i was being lazy and i do intend to document the class and have
it evolve over time.

1 & 2 are fixed, give that a whirl.

3 & 4 will be dealt w/ before the next release.

jploski wrote on Sat Aug  5 21:53:49 MEST 2006:

Still no go because the referenced static fields from org.eclipse.debug.internal.ui.actions.ActionMessages
do not exist.

jgangemi wrote on Sat Aug  5 22:20:07 MEST 2006:

fixed - i hope that should be everything. i'm off to a concert, so if there
are any other issues, i'll fix them when i get home.

applogies over any grief this may have caused.