This isn’t even a fraction of a percentage of what DTX does. Conceptually you’re correct; but in reality every attempt to read/write to a file via DTX kicks of like 60 other tasks which are not exposed with direct file access such as you’re getting with Dynamo.
Dynamo works with ACC/Forma/etc. just fine. What it doesn’t work with is Desktop Connector. This is documented by desktop connector here, as Dynamo is not going to use Windows Shell for saving. In this context Windows Shell means anything which doesn’t expose the “save/open file dialog”, or use windows explorer. As the write action of the node doesn’t expose a UI asking you where to save the file, you’re not able to make use of desktop connector as you’re unable to access the Windows Shell component. As such, the fix is as I’ve noted above. I don’t like this any more than you likely do, and I’ve argued that such support is needed but the Dynamo team can’t change the way [Forma / ACC / BIM 360 / B360 Teams / whatever] works, nor can it change the way DTX works.
Adding logical reasons for such and pointing out issues isn’t going to help your or me or the community, but will likely just add to your frustration (I told that guy Jacob it should be different why isn’t it fixed yet?). I can’t escalate it for you, nor can others here. In the end this forum is not going to get the right eyes on the issue as DTX team isn’t here and won’t be and nothing on the [Forma / ACC / BIM 360 / B360 Teams / whatever] side can be changed without breaking a lot more than you’re facing now. So if you think all the above makes for a bad UX (as I do), please add your voice to the ideas portal here: Redesign from scratch Desktop Connector - Autodesk Community
Most of ACC doesn’t work without Desktop Connector, so it doesn’t make sense to claim that Dynamo works with ACC but not Desktop Connector. Can Dynamo write directly to ACC servers without being on the local cache, which is apparently not supported? Because that’s what you’re implying works but not with DC.
The Windows Shell issue doesn’t make sense to me, either. The File Path node in Dynamo uses the Windows Shell to select the file that’s going to be written. Even then, I can use the command prompt to navigate to the local cache of ACC and create a text file without issue. Desktop Connector takes that file and syncs it to ACC just fine. Is there some kind of programming going on behind the scene for the actual writing to the disc that Dynamo is using that’s different?
I mean… it’s exactly the opposite in that nearly all of ACC doesn’t require Desktop Connector. I don’t need DX to use docs. Or Issues. or Revit Cloud Worksharing. DX exists to provide a bridge for supported workflows (links in Revit, Collaboration for Civil, etc.). One of those supported workflows is saving files from a windows environment to docs using the Windows Shell.
This is correct
This is also correct in that it’s working for you, but it’s not supported by the product. It might even work 100% of the time during your testing, but eventually it has been found to fail when scaling which is why it is called out as unsupported.
This is the same reason writing the file with Dynamo (or any other tool) can work, but won’t work 100% of the time. DTX tries to do what it can in these cases, but without the added checks and balances that it puts into place with read and write you can get into a LOT of problematic situations. So… I don’t recommend this path.
At this point I’ve given you the guidance, shown you where it says ‘unsupported’ so you’re aware, attempted to explain why, told you where to redirect the feedback, and given you my recommended alternative. Best of luck.
I guess this explains why some of my graphs working on C3D drawings don’t work consistently since the project is on ACC/Forma. It apparently can’t write to the DWG properly since C3D relies completely on Desktop Connector to work.
Sure would be nice of Autodesk to make it more prominent that Dynamo doesn’t support C3D when working on ACC/Forma. Dynamo should know if a drawing is opened from ACC/Forma or an output file going to ACC/Forma and warn the user that it’s not supported.
Dynamo can’t know any more than C3D and core .NET components it runs on know.
Sadly the AutoCAD API doesn’t have a “is cloud file” API call (that I’m aware of) so that’s blocked. This would require re-writing the DWG file format so that kind of makes sense.
Also sadly, DTX doesn’t change how .NET works (that’s not possible), but instead changes the UX in Windows by way of an extension (hence why sometimes thinks look different when you’re viewing a desktop connector path vs a regular path) which means the system itself doesn’t know the difference between the two either.
This means Dynamo’s in the dark for standard nodes. It also can’t be as simple as “have the methods which use file paths call the DTX api to confirm thigs work” as many of those APIs aren’t accessible in the environments that Dyanmo runs in (think about Dynamo as a Service where it’s running in the cloud; or Dynamo CLI where it’s running without any UX; or a user (like me) who doesn’t usually even have Desktop Connector installed). The DTX team could write such as a Dynamo package, as could the ACC/Docs team, or the APS team.
Fortunately as a graph author you can take this stuff into account (there are always clues in the path that something is dtx related) and write nodes/code/scripts/graphs to handle things differently in such situations.
Well, with all that said, I switched the file path for the Excel file to my desktop. It still is causing the original corruption error to the .XLSX file, so this isn’t due to Forma/ACC/BIM360. What could be causing this problem?
Well, that’s a wrinkle!
Can you start a new topic (as this one is solved already) and include the graph, the image from exporting your workspace at a legible resolution and with the warning produced, a dataset to run it on, and a screenshot showing the error?
Otherwise we’re still guessing as to ‘why’.
Now I’m even more confused. If Dynamo doesn’t support Desktop Connector, then what does this mean?
Opening files and assuring users can open them is VERY different than writing. Comparing oranges to spaceships.
you can try to use Data Management API (APS)
- Download the file from Forma link API
- Modify the file (openpyxl or OTTB node “Data.ExportToExcel”)
- Upload the modified file as new version link API