Thanks all for the help.
I guess the consensus is: No need for
generic DSF target state change event.
I’ll make my own event and override all
my DMVM providers to handle it properly.
Regards
Dobrin
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: April 6, 2010 7:29 PM
To: CDT
General developers list.; CDT
General developers list.
Subject: Re: [cdt-dev] RE: generic
refresh event in DSF
Not to mention DebugEvent.CHANGE ;-) ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=258549
)
John
At 06:15 PM 4/6/2010, Pawel Piech wrote:
In Wind River's product we have a
generic "State changed event" for an execution context, it's only
handled in the Debug view and other views get refreshed due to a debug context
changed event.
However, I'm not sure if it makes a lot of sense to make this an API.
Because the details in how such event would be used by different debuggers
would likely create contradicting requirements in the future. I think
this is what happened to DebugEvent.CONTENT, but there the solution to any
conflict was that it worked in the way that best fit the needs of JDT.
The intent in DSF was that if you have model specific events, then you should
extend the VM Provider and handle that event.
Cheers,
Pawel
Alexiev, Dobrin wrote:
Marc,
If there was generic Refresh event would you rather use that one or you still
prefer introducing the trace specific - event just for view updates?
Initially I was thinking about overriding my DMVMProviders but then I thought
that having a generic refresh even might be beneficial for everybody.
It makes sense the back end to request all views to update - it knows its state
best and makes a decision that the data in all views is out of date.
I think the default DMVMProviders already handle the suspend event that way. I
was thinking expanding that case beyond the running -> halted transition.
May be there is a drawback with using generic event over specific events.
DefaultRefreshAllTarget is UI code. Using it looks more like a workaround to
me.
I would think that code that the back end requests the model to refresh
(invalidate) should be non UI.
Thanks
Dobrin
From: cdt-dev-bounces@xxxxxxxxxxx [
mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Marc Khouzam
Sent: April 6, 2010 12:35 PM
To: 'CDT
General developers list.'
Subject: [cdt-dev] RE: generic
refresh event in DSF
Hi Dobrin,
I have a
similar use case for Tracepoints. When looking at a new tracepoints, the
different views must refresh. It is not a ISuspended event though.
The approach I took was to create a new event for this case. It is
IGDBTraceControl.ITraceRecordSelectedChangedDMEvent, which is in HEAD, but
not used yet. I will be implementing it usage soon though.
Pawel might
have a better answer, but I would suggest implementing an event for your
situation and having the different classes extending
AbstractDMVMProvider, listen for that event and take action. Most of
these classes implement ICachingVMProvider.refresh() which causes
the view to refresh completely. This may be a little drastic though, and
you may want an more intelligent update when your event is
received.
You can also
look at DefaultRefreshAllTarget, which causes all views to refresh (not that
some views don't support this yet, like the memory view)
Marc
From: cdt-dev-bounces@xxxxxxxxxxx [
mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alexiev, Dobrin
Sent: Tuesday, April 06, 2010 12:08
PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] generic refresh
event in DSF
Hello,
I was wandering if there is a generic DSF event that I
can fire to trigger updates in all debug views - registers, variables,
expressions, memory, debug, etc.
I think that ISuspendedDMEvent triggers all view
updates but that is related to changing the state of the target from running to
suspended. In my case the target running state is unchanged.
Our debugger back end has more states than just
running and suspended and Id like to trigger updates in all views for any
of these state transitions.
The target may or may not have a stack in these
states.
Does anyone else have these use cases in their debuggers?
Does it make sense to introduce such an event?
Thanks
Dobrin
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev