[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] Extending filtering for CallStackView
|
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