Skip to main content

[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


Back to the top