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.
