Difference between revisions of "Special viewer for both components"
(New page: '''''The Viewer Model'''''<br> The proposed viewer implementation is based on the ''SourceViewer'' and ''Document'' classes. Both classes are extended to support the model that consists ...)
|Line 1:||Line 1:|
'''''The Viewer Model'''''<br>
'''''The Viewer Model'''''<br>
Revision as of 08:43, 31 December 2007
The Viewer Model
The proposed viewer implementation is based on the SourceViewer and Document classes. Both classes are extended to support the model that consists of the following elements:
Root: maps to the current disassembly context.
Current Base: an object that represents the starting point of the disassembly presentation. It is calculated from the current debug context or underlying memory block (in case of the memory rendering). The client provided content adapters are responsible for this conversion.
Line: represents a line in the disassembly presentation. Depending on the backend model it can be a disassembly instruction, source line, label, etc. Lines are referred by the offset (positive or negative) from the current base element.
For example, for the CDI based models, the IDisassembly objects can be mapped to the root elements, the IDisassemblyBlock objects to base elements and the IASMSourceLine and IASMInstruction objects to line elements.
How It Works
The document associated with the viewer provides the textual content and is responsible for the conversion of the model elements into the text presentation and vice versa. The viewer notifies the document when it is refreshed, scrolled or resized. The document generates content requests to the content provider based on the number of lines required and their offsets from the base element. The content provider uses content adapters contributed by clients to get the “real” content. When the content is received the content provider requests the labels and annotations for each line. Label and annotation adapters are also contributed by clients. The content provider also maintains the set of the model proxies required to convert the backend model notifications into the viewer updates. Clients can provide model proxy adapters for these purposes. All content adapter calls include the presentation context as a parameter.
1. A stack frame is selected in the Debug view. As a result the “setInput” method of the viewer is called.
2. The viewer informs the document that the current input is changed.
3. The document requests the base element update from the content provider.,br> 4. The content provider passes the request to the content adapter. If the current base element is not valid anymore the content adapter provides a new base element and the full content update is required. If the base element remains the same, the annotation request is issued to update the instruction pointer positions.
Following is the description of the main classes and interfaces required for these proposals.
Provides the underlying viewer with input. Listens to the debug context changes and converts the current debug context into an input.
Extends AbstractMemoryRendering. Provides the underlying viewer with input.
Used in the control part of DisassemblyEditor and DisassemblyMemoryRendering. Contains the editor specific classes common for both parents.
Used in the control part of DisassemblyPane. Extends SourceViewer. Notifies the associated document when the viewer is refreshed, scrolled or resized.
Extends Document. Converts the model elements into the text content.
Manages the mapping between the viewer model and the underlying debug model through the content, label and annotation adapters. Maintains the list of model proxies and reacts to the debug model changes.
Responsible for the label updates.
Responsible for the annotation updates.
The clients are required to implement the following interfaces: