[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[dsdp-dd-dev] RE: Need new API in Traditional Rendering
|
We could add a similar goToAddress(BigInteger address), but I'd prefer
to use an interface. Requiring the debugger implementation to be aware
of APIs specific to individual renderings feels wrong.
Do you currently check for an instanceof Abstract*TableRendering before
calling gotoAddress()? What happens when the user installs another
rendering with a goToAddress(BigInteger address) that is not based on
Abstract*TableRendering?
ted
-----Original Message-----
From: Lee, Alain [mailto:a-lee@xxxxxx]
Sent: Friday, November 03, 2006 11:50 AM
To: Samantha Chan
Cc: Device Debugging developer discussions; Williams, Ted
Subject: RE: Need new API in Traditional Rendering
My code currently calls HexRendering.gotoAddress() to force HexRendering
to display memory for a certain address. Any suggestion for me to
achieve the same thing in Traditional Rendering?
-----Original Message-----
From: Samantha Chan [mailto:chanskw@xxxxxxxxxx]
Sent: Friday, November 03, 2006 2:46 PM
To: Lee, Alain
Cc: Device Debugging developer discussions; Williams, Ted
Subject: RE: Need new API in Traditional Rendering
Hi,
I do not think there needs to be an API to allow clients to force a tab
label update. The same can be achieved by firing a property change
event:
firePropertyChangedEvent(new PropertyChangeEvent(rendering,
IBasicPropertyConstants.P_TEXT, null, "new label"));
The tab listens for property change events and will update the tab label
for the rendering upon this event.
Regarding the #goToAddress API, my concern is that not all renderings
can perform a "go to address" operation. This is similar to the #reset
API that is provided by the IResettableMemoryRendering. If we want to
provide such API, it will most likely be another interface that a
rendering needs to implement (e.g. IGoToAddressRendering or something)
and the method will be defined in this interface.
There is another request to have a gobal "go to address bar" in the
Memory View. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=126909) The
address bar needs to be put inside the Monitors pane and will direct all
visible renderings to go to a certain address.This new interface will be
required in order to implement this global address bar.
Thanks...
Samantha
"Lee, Alain"
<a-lee@xxxxxx>
To
11/03/2006 01:54 "Williams, Ted"
PM <ted.williams@xxxxxxxxxxxxx>,
"Device Debugging developer
discussions"
<dsdp-dd-dev@xxxxxxxxxxx>,
Samantha
Chan/Toronto/IBM@IBMCA
cc
Subject
RE: Need new API in Traditional
Rendering
Currently, these two APIs, updateLabels() and gotoAddress(), are
available in AbstractTableRendering and AbstractAsyncTableRendering.
From: Williams, Ted [mailto:ted.williams@xxxxxxxxxxxxx]
Sent: Friday, November 03, 2006 1:46 PM
To: Lee, Alain; Device Debugging developer discussions; Samantha Chan
Subject: RE: Need new API in Traditional Rendering
I agree that such functionality would be useful, but I believe the APIs
should be provided by the memory view and not the individual renderings.
Samantha, do you have any thoughts on this topic?
ted
From: Lee, Alain [mailto:a-lee@xxxxxx]
Sent: Friday, November 03, 2006 10:31 AM
To: Williams, Ted
Subject: Need new API in Traditional Rendering Ted,
Is it possible to provide APIs to perform the following functions in
Traditional Rendering?
* API to update the memory view tab label?
* API to provide the similar function like
Rendering.gotoAddress(address) so that our code can call
MemoryRenderingTraditional.gotoAddress() to set the rendering to
show
the memory for a particular address.
Best regards,
Alain Lee
Texas Instruments Canada Ltd
801 - 150 John Street, Toronto ON Canada M5V 3E3
Phone: 416-340-2136 Fax: 416-599-7171
mailto:a-lee@xxxxxx