Browse Prior Art Database

Views Synchronization in Eclipse

IP.com Disclosure Number: IPCOM000124069D
Original Publication Date: 2005-Apr-07
Included in the Prior Art Database: 2005-Apr-07
Document File: 7 page(s) / 183K

Publishing Venue

IBM

Abstract

This article dicusses the design of memory views synchronization in Eclipse. Although the design is tailored for synchronizing views that are displaying the same memory monitor, the design can be generalized to enhance views syncrhonization in Eclipse.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 22% of the total text.

Page 1 of 7

Views Synchronization in Eclipse

Disclosed is the design of UI synchronization for views in Eclipse. When debugging an application, it is often useful to be able to examine the memory being used by an application. Two Eclipse views have been developed for this purpose:

Memory View - For monitoring blocks of raw memory from a program. The memory block is presented in a table and in hexidecimal format. The user can examine multiple blocks of memory at the same time. Content of the memory block is monitored and will be updated when it is altered.

Memory Rendering View - For rendering the memory that is currently displayed in the Memory View. The Memory Rendering View displays the raw memory in a selection of data formats. The default data formats include the following: ASCII, EBCDIC, Signed Integer and Unsigned Integer. This view needs to be extensible to allow third-party plugins to provide additional rendering formats suitable for their debug environments (additional rendering formats would not be provided ahead of time because they and their optimal memory block presentation cannot be anticipated).

The following is a screen capture of of the two views:

Figure 1 - Screen captures for the memory View and Memory Rendering View

    As shown in the screen capture in Figure 1, each tab in the Memory View represents a memory block being used by a program. On the other hand, each tab in the Memory Rendering View represents a rendering of a memory block. More than one memory block can be monitored at a time by both views, and each memory block can be rendered to multiple formats at the same time. For example, memory block "i" at 0x12FF98 is displayed in four different formats on the right.

    Since the Memory View and the Memory Rendering View are actually displaying the same thing (same memory block from a program), the tab contents in the two views need to be synchronized at all times. Synchronization allows the user to see what a

1

[This page contains 2 pictures or other non-text objects]

Page 2 of 7

block of raw memory looks like in different data formats. The following items are to be synchronized in the tab contents:

Highlighted cell in the table - When a cell is highlighted in one view, the other view highlights the cell at the corresponding location.

Scroll bar movements - When the user scrolls a view, the scroll bar in the other view is repositioned to display the same range of memory.

Column size of the table - This represents the number of bytes displayed per column. When the column size of one view is changed, the other view is updated accordingly.

    In the Eclipse workbench, views are often synchronized by employing an event listening strategy. Take the example where View B wishes to be synchronized with View
A. View B would register as an event listener to View A. When something has changed in View A, the view would fire an event to notifiy its listeners about the changes. View B would then receive the event from View A and updates it...