|
A refreshEvent was discussed but I felt it was too generic
an event. Normally, you would create a new event or events, and would
update the VM node. But I realize it is a lot of work and it would be
much nicer to simply issue an event that will refresh the
views.
Maybe someone more knowledgeable about the VM nodes
can give their input? Pawel maybe :-)
I've done something not as cleanly as I should have
for tracepoint visualiztion that you can look at, which
refreshes the Debug view on an couple of Trace
events. Look at LaunchVMProvider and event
ITracingStartedDMEvent. It does not use the deltas
but simply refreshes the view. I would like
to clean that up in the next release
though.
You can also look at MITracepointSelectedEvent which
pretends to be a breakpointHitEvent to trigger
a SuspendedEvent and refresh the views.
Marc
Thank
you, Marc. I tried a SuspendedEvent (similar to ContainerSuspendedEvent)
and it did not work. It would be nice to have a RefreshEvent, although I
can certainly see arguments against it. I’ll have to play with this a
bit to see how the event is interpreted by the various handlers so I can
figure out what they’re expecting.
Unless,
of course, this is documented somewhere… although I suspect the documentation
is the code itself.
Thanks
again,
-- Steve G.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf
Of Marc Khouzam
Sent: Tuesday, June 14, 2011 2:04
PM
To: 'CDT General developers list.'
Subject: Re:
[cdt-dev] DSF/GDB: How can I refresh the debug
context?
The
success of your monitor command should trigger a DSF event that the view
should listen for.
When
getting that event, they will then need to trigger the correct
delta.
You
can look at how we handle ISuspendedDMEvent for example.
I hope
this helps
Marc
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Steve Goodrich
Sent: Tuesday, June 14, 2011 3:40
PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] DSF/GDB:
How can I refresh the debug context?
I’ve
got a custom “monitor” command for our stub that causes a fundamental change
to the target system (similar to what would happen if you reset the target
or encountered an interrupt/exception). If the debug session is
paused/suspended (e.g. after a Single Step) and I send this command, the
target behaves correctly. However, I have to Single Step to get the
windows (registers, disassembly, etc.) to update.
Is
there a way to programmatically force a refresh/update of the debug
context? I’ve beat my head against this for a while; I’m hoping that
someone on here might already have the answer.
Thanks,
-- Steve G.
|
