Re: [platform-debug-dev] Two pane debug editor.

[Darin_Wright@xxxxxxxxxx]

This sounds reasonable. The debugger makes these assumptions when displaying source, which you may want to verify:

* The editor opened by the debugger is controlled by the debug model presentation (via #getEditorInput() & #getEditorId())

* If the editor opened by the debugger is an ITextEditor, "instruction pointer" arrows are displayed in the editor by adding annotiations to it (which appear in the ruler). Source code is highlighted by using the #selectAndReveal(...) API on ITextEditor.

* If the editor opened is not an ITextEditor, instruction pointer arrows are not displayed (as there is no API for adding annotations to an IEditorPart). Source code is highlighted by using the #gotoMarker(...) API

Thus, your editor will need to be able to distinguish when it is being told to scroll to a line from the debugger - via one of the two calls above.

Darin

Erin Harris/Toronto/IBM@IBMCA Sent by: platform-debug-dev-admin@xxxxxxxxxxx 01/15/2003 10:13 AM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-debug-dev] Two pane debug editor.

I have a two pane debug editor for which I need to scroll each pane
separately whenever a new stack frame is selected.  What I was considering
doing is the following:

1. Create a special editor input which contains both of the files.
2. The line number returned by the stack frame will be defined to be the
line number for the first pane.
3.  Whenever the editor is told to scroll to a line it calls a special api
on the current stack frame to get the line number for the second pane.
4.  When a user double clicks on a breakpoint in the breakpoints view the
two pane editor will not be used since the breakpoint is located in one
file only.  The editor for that individual file will be used, this means
that a separate tab will be brought up even if that file is already
displayed in one of the panes of the two pane editor.

Can anyone think of a reason why this would not work or does anyone have
any suggestions for a better way to do this?

Could an Eclipse feature be opened to support this kind of situation better
some time in the future?

Thanks.


- Erin


_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev