[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-dd-dev] RE: Force Tab Label Update
|
My mistake. I made a stupid error in my test program. This approach
works fine in AbstractTableRendering and AbstractAsyncTableRendering.
Ted, Please confirm that Traditional rendering will handle the Debug
events in the same manner. Thanks!
-----Original Message-----
From: Samantha Chan [mailto:chanskw@xxxxxxxxxx]
Sent: Monday, November 06, 2006 5:28 PM
To: Lee, Alain
Cc: Device Debugging developer discussions; Williams, Ted
Subject: RE: Force Tab Label Update
Hi Alain,
I tried this approach with my testcase and the labels are updated upon a
state change event for AbstractAsyncTableRendering. Its #updateLabels
eventually gets called after a state changed event.
If your rendering subclasses from AbstractTableRendering, the events are
handled in TableRenderingContentProvider. Look at
#doHandleDebugEvent(...)
If your rendering subclasses from AbstractAsyncTableRendering, the
events
are handled in MemoryBlockProxy. The state change debug events are
translated to model deltas, which is eventually handled in
AbstractTableRenderingUpdatePolicy. The method
#handleMemoryBlockChanged
should eventually get called after a state change event.
Thanks...
Samantha
"Lee, Alain"
<a-lee@xxxxxx>
To
11/06/2006 05:07 Samantha Chan/Toronto/IBM@IBMCA,
PM "Williams, Ted"
<ted.williams@xxxxxxxxxxxxx>
cc
"Device Debugging developer
discussions"
<dsdp-dd-dev@xxxxxxxxxxx>
Subject
RE: Force Tab Label Update
I verified that this approach works fine with AbstractTableRendering.
However, it seems that AbstractAsyncTableRendering does not handle the
Debug events. We changed HexRendering to be based on
AbstractIntegerRendering due to some issues with the Endianess. I don't
see any code in AbstractIntegerRendering or AbstractAsyncTableRendering
that listens to the debug events. Did I overlook anything?
-----Original Message-----
From: Samantha Chan [mailto:chanskw@xxxxxxxxxx]
Sent: Monday, November 06, 2006 3:59 PM
To: Williams, Ted
Cc: Lee, Alain; Device Debugging developer discussions
Subject: RE: Force Tab Label Update
Hi,
I do not think we should make a rule to update labels after #goToAddress
is
called. This behavior is too specific for a debug implementation and
should not be forced into the renderings which are shared by many
different
debuggers. In some cases, getting labels is an expensive operation and
would require conversations to the debug engine.
How "go to address" is handled is rendering specific. Some renderings
may
position the rendering to the specified address, but other renderings
may
want to handle this differently. We should not specify how labels
should
be updated in this API definition.
Alain, I think you should fire a state change event on the memory block
after the #goToAddress call. This is equivalent to calling
#updateLabels
and will force the rendering to re-get its labels.
For this to work on the traditional rendering, the traditional rendering
should honor both content and state change events from the memory block.
Upon a content change event, the rendering updates its contents and its
labels. Upon a state change event, the rendering updates all its labels
and should not re-get the content of the memory block.
Does this sound like a feasible solution?
Thanks...
Samantha
"Williams, Ted"
<ted.williams@win
driver.com>
To
"Lee, Alain" <a-lee@xxxxxx>,
11/06/2006 02:24 Samantha Chan/Toronto/IBM@IBMCA
PM
cc
"Device Debugging developer
discussions"
<dsdp-dd-dev@xxxxxxxxxxx>
Subject
RE: Force Tab Label Update
Could we make it a rule that labels are updated after gotoAddress is
called? If not, I believe the method should be included in an interface.
Requiring the debugger to contain knowledge of rendering specific
non-published APIs does not scale.
Alain, would you file the enhancement request for gotoAddress?
ted
-----Original Message-----
From: Lee, Alain [mailto:a-lee@xxxxxx]
Sent: Monday, November 06, 2006 10:57 AM
To: Samantha Chan
Cc: Device Debugging developer discussions; Williams, Ted
Subject: RE: Force Tab Label Update
Ted,
My own ILabelDecorator has been working fine to customize the label to
include extra information that is specific to our application. Right
now, we need to refresh those "extra information" in the label
immediately after AbstractTableRendering.gotoAddress(). As
AbstractTableRendering.gotoAddress() does not trigger the label to be
updated, I can always explicitly invoke
AbstractTableRendering.updateLabels() to force the label to be updated.
How can this be achieved in Traditional rendering?
-----Original Message-----
From: Samantha Chan [mailto:chanskw@xxxxxxxxxx]
Sent: Friday, November 03, 2006 4:08 PM
To: Lee, Alain
Cc: Device Debugging developer discussions; Williams, Ted
Subject: Re: Force Tab Label Update
Hi...
Sorry, I did not remember that it is a protected method. May I ask why
you need to update the label?
The labels of the renderings provided by the platform can be customized
as
follows:
1. Update to labels are driven by the following debug events:
- DebugEvent.SUSPEND
- DebugEvent.CHANGE - state change event will cause all labels to
update.
The content of the rendering will only be updated upon a content change
event.
2. The tab labels of the renderings can be customized by providing an
ILabelDecorator adapter from the Memory Block. Whenever a tab label is
needed the decorator will be consulted to allow clients to customize the
labels.
To customize the update of the label, try firing a state change event
from the memory block. To customize the label itself, please provide a
label decorator adapter from the memory block.
Ted, does the "traditional" rendering employ the same sort of strategy
to allow clients to update the tab labels? If you subclass from
AbstractMemoryRendering, then you will properly get the label decoration
for free.
Thanks...
Samantha
"Lee, Alain"
<a-lee@xxxxxx>
To
11/03/2006 03:42 Samantha Chan/Toronto/IBM@IBMCA
PM
cc
"Device Debugging developer
discussions"
<dsdp-dd-dev@xxxxxxxxxxx>,
"Williams, Ted"
<ted.williams@xxxxxxxxxxxxx>
Subject
Force Tab Label Update
I tried to fire the property change event but firePropertyChangedEvent()
is a protected interface. I could call
AbstractTableRendering.updateLabels() but I want to put the label in my
own format. Any suggestion?
-----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
