Ambiguity in structs/classes ZTN development

Hi guys!

I get a weird error when running my newly developed Dynamo package. It seems Dynamo doesn’t like it when I include these code lines:

public static IEnumerable<Dlubal.RFEM5.Line> Line(IEnumerable<Autodesk.DesignScript.Geometry.Curve> DynamoCurveList)
{
    //Do stuff
    return RFEM_Lines;
}

When this is deleted, the code in the code block will run just fine. It doesn’t help to include “Autodesk.DesignScript.Geometry.Line.Bystart…etc” in the code block, the Dynamo node will then just turn grey as if all is well but it will do nothing.

Might it be that there is some kind of ambiguity in the structs/classes in the code lines? ie. Dynamo gets confused on which one is to be used of the following:

  • Autodesk.DesignScript.Geometry.Line
  • Dlubal.RFEM.Line

Does anyone have an idea on how to solve that problem?

Looks like you have a namespace conflict as a result of loading the dlls associated with your ZT node. Add a Line.ByStartPointEndPoint node to your workspace, wire in some inputs, select it, right click the background and choose node to code. The new namespace required to call the line functions in code blocks. This will may extend to curves, and other geometry types so check other geometry functions as well.

Good idea! But here is the rather unfortunate result:


So the code

Autodesk.DesignScript.Geometry.Line.ByStartPointEndPoint

in the block works for a single line, but not while within a ‘for’ loop.

The model should do this (for this screenshot, I removed the problematic code from the package to be able to snap this image):


Could it be something that this problem directly affects code in loops?

The results of the node to code need to replace the Line.ByStartPointEndPoint. That is add the name space prefix Autodesk.DesignScript.Geometry. before the Line.ByStartPointEndPoint in your imperative code.

I did replace it, see marked in colors:


Therefore I think it may have to do with code within the ‘for’ loop :slight_smile:

Hard to say without an indication of what the input lists are. Can you upload a full export of the graph or the dyn and required source files?

This is a known bug with imperative nodes and namespaces - it should be fixed in master now.

Hi guys,

Good to know this is fixed in the latest Dynamo build.

Eventually I decided to work around the problem and use my own classes with constructors to move data around, which also happened to make my code work a lot easier.

Cheers! Michael