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.
Note: The above is an archived snapshot of a forum thread. Use the original thread at sf.net to post comments.