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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Your committed changes break compatibility with Eclipse 3.1. See the other thread...
*smacks head*
do you know what it specifically breaks? perhaps there is an easy work around i can put it for now.
It does not compile because there is no class
org.eclipse.debug.ui.actions.RulerBreakpointAction
in 3.1.
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.
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).
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.
Still no go because the referenced static fields from org.eclipse.debug.internal.ui.actions.ActionMessages do not exist.
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.