[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-debug-dev] Debug Work Items for 2.1 and Beyond
|
Please continue this discussion on the jdt-debug-dev list only. There's no
reason for this discussion to be crossposted to platform-debug-dev.
Thanks,
- Jared
On Wednesday 14 August 2002 01:09 pm, you wrote:
> Darin Swanson wrote:
> > > Here are some of the issues we've come across when wrapping the
> > > jdt debug model:
> > >
> > > 1. One issue that we have when wrappering the jdt debug model is
> > > that we have no way to override the jdt menu contributions to the
> > > launch and variable views (that we know of). Specifically the
> > > 'open on <x> type' menu items. These show the underlying java source
> > > code, which is not the language that the user is debugging. I would
> > > say that the solution would be to base the menu items on the current
> > > debug target id, but I'm not sure if this is the solution.
> >
> > This is great as it might validate my work for today ;-).
> > I reworked the "Open on" menu items to request the source element from
> > the source locator for the launch. So your source locator can be reused
> > to just do the right thing?
> > We only resort to searching the workspace if this fails. See bugs:
> > http://dev.eclipse.org/bugs/show_bug.cgi?id=5516
> > http://dev.eclipse.org/bugs/show_bug.cgi?id=4084
> >
> > Of course with actions that simply do not make sense in your context, you
> > can remove the contribution from the XML.
>
> The actions may not make sense in our context, however if the these
> menu items had a 'java' icon next to them it may solve the problem.
>
> The language is capable of calling java and vice versa, so our
> debug wrappers act as the underlying java debug elements in the
> instances where the user steps into and out of java code. When
> in the java code, we would want the user to have these menu items
> present.
>
> > > 2. Another issue that we have is that our program programmatically
> > > sets underlying java breakpoints whenever the user sets a breakpoint
> > > in their source code (which is in another language). It would be
> > > nice if these java breakpoints could be 'invisible' in the breakpoint
> > > view by default. Currently, the user has to set the 'show only
> > > supported breakpoints' option. It would be nice if there was a
> > > visibility option and the breakpoint view would not show invisible
> > > breakpoints by default (the user could override this, of course).
> >
> > I believe this is covered in our concept of registering/not registering
> > the breakpoint with the breakpoint manager?
> > For example, we programmatically set breakpoints for the "Run to Line"
> > functionality. These are not registered (part of the api on the call to
> > the debug model to create a line breakpoint) and therefore do
> > not show up in the breakpoints view.
>
> The problem is that these breakpoints are not temporary and need to
> be managed, persisted, etc. This is the job of the breakpoint manager
> right?
>
> > >4.
> >
> > Could you please log a bug report for this issue?
>
> Entered as Bug # 22435
>
>
> Thanks,
>
> David
> _______________________________________________
> jdt-debug-dev mailing list
> jdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev