I woke up this morning thinking about how to offer as much information as possible to you,
or anyone else that is kind enough to help. Therefore, I am sending along the Grasshopper file that I use to attempt VS debugging.
test VesselCAM2020_12.0.gh (184.5 KB)
In the file is the custom component as well as necessary input parameters with data internalized. The custom component is not enabled to allow for setting up VS debugger breakpoints before the component freezes both Rhino and Grasshopper. When using the debugger with single line code stepping, as shown yesterday, the component outputs data, and then freezes. Without the debugger, Grasshopper freezes before any data is emitted.
For context, the original code was developed in a Grasshopper C# Script component. One feature is a large datatree for visualizing the reasonableness of the code by previewing individual branches of the tree in Rhino. While using the C# Script component, by change input parameters, the code had generated in excess of 120,000 gcode blocks, written to a text panel in less than 2 minutes. Much faster than CAM software I used 20 years ago.
Yesterday, I tested if incremental saving to DropBox was the cause of the freeze, but after having removed DropBox’s file synchronization, and stopping incremental saving in Grasshopper, the component still freezes the application.
There is also another anomaly. When debugging yesterday, when starting debugging, I got an error message asking for the IronPython .pdb file. My workaround was to not load IronPython when Rhino boots up. I get an error dialog, that I acknowledge. I will attempt today to adjust settings in Visual Studio to remove this error.
Lacking a solution for the problem, I intend to rebuild the component code gradually, debugging along the way. This is allow moving the code to OOP style, versus, its current procedural coding. I don’t think this is the source of the problem, but I want to improve my meager coding skills in any case.
Thanks much for your reply,