List type Output makes odd datatree type paths for a Custom Component

Happy New Year!
Still working on a CAM solution within Grasshopper whilst also learning C# in Visual Studio.

My pattern of component development is to create perhaps an excessive number of outputs to visually review the results of computations within the component itself. For me, this is preferable to debugging long iterations of data. I am trying to tidy things up with one of many custom components and would like to understand the duplication pattern of output list data. For illustration, the output “sortMeshFace” is a list of boundary polylines collected in a list within the C# code, and then outputted as a list in DA.SetDataList, and the pManager. The polyline is first collected from mesh faces and then sorted along the X_Axis by an index. It is the sorted list that is set as output.

The output looks like data tree pathing, with the complete list of polylines in one path, and followed by individual list items in separate paths. For visual evaluation of the data, I am the needing to separate off the first “branch” of the output with separate branch retrieval components for each list. As this seems like a needless requirement with corrective code, I would also like to understand what is the cause of the output pattern. Thanks for your kind advice.

The merit of continued research…
My particular problem with odd output trees has been solved with two steps.

  1. Research into multi-tasking lead me to try GH_TaskCapableComponent type and unwittingly inherit from this class. I have put off multi-tasking until later.


    Replacing the type of my Custom Component to GH_Component partially corrected the output.

    However I still had two trees branched for every list type output.

  2. The forum had a post that mentioned limiting the DA.Iteration during the SolveInstance() method. I corrected the double tree branch (2 lists) output with the following:


    The output is now a list and not a tree.

    Seems to work. Hope this helps someone else.

Thanks, Dave