Hi David
Great to hear that you had progress. Just to let you know that
Patrick is on vacation this week. If you have more questions he
will be back early next week.
Bernd
On 08/16/2016 01:16 PM, David Wootton
wrote:
Patrick
I figured out my problem with child Nodes in the tree at the
left side of the view. The hasChildren and getChildren methods
were only checking for children for TraceEntry and ProcessEntry
objects. The corresponding methods in the content provider in
CallStackView were checking for 'instanceof TraceEntry'. Since I
don't have access to the internal TraceEntry, ProcessEntry or
ThreadEntry classes, I needed to make the same check by getting
the class name and checking that, where I missed checking for
ThreadEntry.
Dave
David Wootton---08/16/2016 12:45:00
PM---Patrick I did most of what you suggested. I could not
override getFunctionName(),
From: David
Wootton/Poughkeepsie/Contr/IBM@IBMUS
To: tracecompass
developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 08/16/2016
12:45 PM
Subject: Re:
[tracecompass-dev] Extending filtering for CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx
Patrick
I did most of what you suggested. I could not override
getFunctionName(), by which I assumed you meant
CallStackView.getFunctionName() since it's access is
package-private and not visible to my class extending
CallStackView. I don't think this matters since I'm not doing
anything in my implementation with function names at this point.
Once I did this, I am able to open a trace, then switch between
analysis 'A' and analysis 'B' as well as load a second trace and
switch between its analysis 'A' and analysis 'B' without
problems.
If I apply a filter to analysis 'A', switch to analysis 'B' and
then switch back to analysis 'A' the filtering for analysis 'A'
is preserved.
However, if I switch to analysis 'B' again, set a filter for
analysis 'B', then filtering is applied to analysis 'B'
correctly. However, when I switch back to analysis 'A', its
filtering is reset and all threads are visible. If I set a new
filter for analysis 'A' then switch to analysis 'B', the
filtering for analysis 'B' is reset.
I did set a breakpoint at the point in getElements() where I
return the array of TraceEntry objects (a single object) and
walk thru the tree from the TraceEntry object down to the
ThreadEntry objects, noting the object id (id=nnn) in the
debugger. It looks like the tree is not being modified as te
object ids remain the same at that point. Maybe a tree elsewhere
is being reconstructed, clearing the filtering?
The other problem I'm still seeing is that the tree on the left
side of the view that shows the trace, process and thread
entries shows no child elements for the thread elements, so a
thread element is not expandable/collabsible even though the
timeline showing the intervals for the ThreadEntry object are
always shown. So there's something else I'm missing that causes
the tree to be incorrectly constructed.
Dave
Patrick Tasse ---08/10/2016 03:25:48 PM---> The
wrappers could just be a subclass of TmfTrace that have the
original trace as a private field,
From: Patrick Tasse <patrick.tasse@xxxxxxxxx>
To: tracecompass developer discussions
<tracecompass-dev@xxxxxxxxxxx>
Date: 08/10/2016 03:25 PM
Subject: Re: [tracecompass-dev] Extending filtering for
CallStackView
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx
> The wrappers could just be a subclass of TmfTrace that have
the original trace as a private field, and another field to
indicate which analysis it should use.
Probably simpler:
Call TmfTraceUtils.getAnalysisModulesOfClass(trace,
AbstractCallStackAnalysis.class) on your trace, and for each
returned call stack analysis, create a different wrapper and
store the analysis as a field in the wrapper. Then each wrapper
can return that single analysis in its overridden
getAnalysisModules().
Patrick
On Wed, Aug 10, 2016 at 3:18 PM, Patrick Tasse <patrick.tasse@xxxxxxxxx> wrote:
I have figured out how to run multiple analyses
extended from AbstractCallStackAnalysis for the same trace. I've
also figured out how to set a content provider extending
TimeGraphContentProvider to my class extending CallStackView so
I can make timelines for individual threads visible or not
visible like the existing ability to make an entire process
visible or not visible using the TimeGraphFilterDialog. I
potentially have a lot of threads per process, so this helps the
user reduce clutter.
The problem is that the filtering to hide or show threads does
not persist when I switch between analyses for the same thread.
If I invoke the TimeGraphFilterDialog to pick a set of threads
to hide, the view is updated when I close that dialog.
I invoke CallStackView.rebuild() when I switch between analyses.
It seems that this method and CallStackView.refresh() use a
private (AbstractTimeGraphView.fFiltersMap) map to track the
specified filter active for each trace when multiple traces are
open.
Since I don't seem to have access to this map, I can't update
it, so whatever I set using the TimeGraphFilterDialog gets
overwritten when I switch analyses.
If I had a way to update this map via getter and setter methods
then I think what I am trying will work. Alternatively, if I had
access to the actual RawViewerFilter object then I could update
the set of objects filtered in or out. However, that is a
private class defined in ShowFiulterDialogAction so I don't see
any way to get access to it.
Is there any way to get access to these objects? Is there
another way I could make this work?
Thanks
Dave
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
|