Node to Code__Crashes Dynamo 2.0.1.555___

[EmCru]

If this issue is with Dynamo for Revit, please post your issue on the Dynamo for Revit Issues page.

If this issue is not a bug report or improvement request, please check the Dynamo forum, and start a thread there to discuss your issue.

Dynamo version

2.0.1

Operating system

windows 10

What did you do?

Placed the current doc node and tried to translate it to code.....

***Update: I thought at first this was only when translating Current Document but it is anytime I invoke node to code

What did you expect to see?

code

What did you see instead?

Crash!

[mjkkirschner]

can you post the stack trace?

[dimven]

I experienced something similar a while back when translating the Document.Current node to DS and it seemed the issue was an older version of the Rhythm package. I think it had a Document class or similar that was creating a namespace conflict...

[smangarole]

@EmCru @mjkkirschner @dimven I cannot reproduce the crash on Sandbox and in D4R 2.0.1.5055

[smangarole]

Please re-open if it's reproducible. It would be great if you can provide:

• the .dyn file
• steps to reproduce

[dimven]

Steps to reproduce:

• Have a recent version of Rhythm installed
• Place a Document.Current and any other node that needs a document as input. I use Document.FilePath in the example below.
• Select them, right click on canvas, pick Node to Code
• You get the below stack trace and then Dynamo terminates

Object reference not set to an instance of an object.

at ProtoCore.Utils.CoreUtils.CreateNodeFromString(String name)
at Dynamo.Engine.NodeToCode.ShortestQualifiedNameReplacer.CreateNodeFromShortName(String className, String qualifiedName)
at Dynamo.Engine.NodeToCode.ShortestQualifiedNameReplacer.RewriteNodeWithShortName(IdentifierListNode node)
at Dynamo.Engine.NodeToCode.ShortestQualifiedNameReplacer.VisitIdentifierListNode(IdentifierListNode node)
at ProtoCore.SyntaxAnalysis.AstReplacer.VisitBinaryExpressionNode(BinaryExpressionNode node)
at Dynamo.Engine.NodeToCode.NodeToCodeCompiler.ReplaceWithShortestQualifiedName(ClassTable classTable, IEnumerable`1 asts, ElementResolver resolver)
at Dynamo.Graph.Workspaces.WorkspaceModel.ConvertNodesToCodeInternal(EngineController engineController, INamingProvider namingProvider)
at Dynamo.Models.DynamoModel.ConvertNodesToCodeImpl(ConvertNodesToCodeCommand command)
at Dynamo.Models.DynamoModel.ExecuteCommand(RecordableCommand command)
at MS.Internal.Commands.CommandHelpers.CriticalExecuteCommandSource(ICommandSource commandSource, Boolean userInitiated)
at System.Windows.Controls.MenuItem.InvokeClickAfterRender(Object arg)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

This is all simply happening because Rhythm has a Document class and the CreateNodeFromShortName method throws a null and the following code doesn't check for null returns...

I am sure there are other similar and unpredictable cases like this one. The Solid class in Lunchbox comes to mind. You can't expect package managers to foresee these weird cases and should instead implement a more rigorous process when importing external namespaces. Maybe have a notification warns when this happens, similar to how the current notification system warns about duplicate assemblies?

[mjkkirschner]

@dimven thanks for the writeup.

[aparajit-pratap]

@smangarole I can take a look at this. Could you file a bug with the above details? Thanks.

[johnpierson]

Is there anything I can do as a package author to help mitigate this? I created my nodes following the same structure present in Dynamo. 😬

[johnpierson]

Rhythm version 2018.9.19 should resolve these issues.

I just made my categories the plural version of the word. So category became categories, etc.

Let me know if this helps with these kinds of clashes (with Rhythm at least), I cannot speak for other package authors.

[aparajit-pratap]

Tracked internally: https://jira.autodesk.com/browse/QNTM-5426

[johnpierson]

Related to #8576

[aparajit-pratap]

Fixed in #9255. Closing.