NamedValues and passing data to a script

[carloquinonez]

Is there an example of using NamedValues to pass data from a script to another command?

[p.seem]

Carlo,

The only time I've seen the use of named value pairs shown was in the answer to this forum post.  Even that one named value pair was valuable to me.  I'm with you -- it would certainly be helpful if someone from the Autodesk team could share other commons pairs, even if only on an unofficial don't-blame-us-if-it-breaks-in-the-next-release basis.

PS

[carloquinonez]

Thank you sending that link. I hadn't seen it before. That part of my code is essentially identical, but what is still missing is accessing those named values from a 3rd party script/plugin. For example, how would I access the 'executeImediately' value from inside the 'AlignComponentsCmd' command using the API - assuming the AlignComponentsCmd was not a native command?

[p.seem]

Carlos,

I'm afraid I don't know how you'd get access to the NamedValue pairs in your on command execute handler. I went down that road myself in the past, hoping that they would be exposed as part of the commandEventArgs, but no luck.  Hopefully someone more knowledgeable will chime in?

One other thought, in case it helps as a workaround:  if AlignComponentsCmd isn't native, and presumably the script/add-in from which you are executing it is also non-native, then you have access to the source code for both?  Maybe you could call AlignComponentsCmd's run method as a java/python call directly instead of routing it through the API's execute layer.  In that case you could, presumably, pass any arguments you'd like?  That's what I ended up doing -- it's messy, because it means I had to drop another developer's add-in code inside my own add-in, but at least that way I could call it programatically, and without their UI layer popping up.

Good luck,

PS

[carloquinonez]

I've done exactly what you describe before. Unfortunately, this time I have to call a script written in a different language.
(calling js script from python), so that's not going to work this time.

So the reason I'm doing that is to workaround another limitation of Fusion360 - the js API only exposes a subset of the application events. I've written a bridge script in python that listens to onOpeningFromURL events, passes the privateInfp to a js script (in my case, but could be any arbitrary script actually). I wrote a also nodeJS app that uses fusion360 urls to control fusion programmatically. Ultimately, I want build web- and REST-interfaces to load data and run scripts remotely. This is the last piece of the puzzle...

[ekinsb]

the "executeImmediately" option is all that's currently supported. This was added to be able to add functionality for a few commands in the future but we've not taken advantage of it yet. Even if we choose to in the future I expect it to be very limited to a handful of commands. It's not intended to be a way to fully drive commands via the API.  I don't expect that to ever happen.

[carloquinonez]

Thanks for the reply. So is there any way to pass in data to another script or command via the Fusion API?

[ekinsb]

I guess we need to first define some terms to make sure we're talking about the same thing.

A "command" is what's created and executed when a user clicks a button in the user-interface or you get a specific CommandDefinition and call the execute method. Commands are designed to interact with the user and most of them have a command dialog to gather the required input from the user. They're not designed to be interacted with through the API. There are a few commands that will use the current selections as their initial input so you can take advantage of that by pre-selecting entities and then executing the command.  The user still typically has to do some interaction and do the final command execution.

Where it really makes sense it's possible to modify a command so that it can use provided input and either reduce the amount of input needed from the user or skip it all together.  This was done in Inventor in a handful of cases.  Primarily for commands that required the user to select a file.  It was possible to provide the filename so the command would use that instead of prompting the user and then continue in it's normal way.  For example, inserting a new part into an assembly when you already knew the name of the file to insert but wanted to take advantage of the rest of the command that allows the user to position the part into the assembly.  It's possible that we could do something like this in Fusion too but it would have to be implemented on a command-by-command basis.

I would consider the term "script" as referring to any script or add-in for Fusion written in any of the three languages supported.  There are some workarounds for Python, but in general  they can only run by the user through the Scripts and Add-ins dialog, or by Fusion when it automatically runs add-ins at start-up. I think we need to provide an API around these to let you essentially do the equivalent of the Scripts and Add-Ins dialog through the API.

If there are two add-ins that know about each other and want to communicate for some reason, there isn't anything in place for that today.  However we're working on something that we're adding to support multiple threads that allows a worker thread to fire an event back to the primary thread. This event can include data that the worker wants to send.  This same event can potentially be used to fire an event from one add-in to another. 

[carloquinonez]

Ok, that does clarify things. So at the moment, there's no way to have two scripts to exchange any data (primitives or otherwise) via the API, correct?

I'm glad to hear there might be a solution in the pipeline. What you described at the end sounds perfect (and really useful!), but I'm curious where it falls on the roadmap? Assuming this coming out in the next couple of months, I have to decide how to move forward. I could either:

(1) scrap my current approach and just write everything in Python (so I pass data like described in the first reply), or

(2) hack my way through this problem by storing my data (just a big JSON really) as an attribute on the root component or something.

Any suggestions or anything else come to mind?

Thank you Brian!

PS Are you going to AU?

[ekinsb · Accepted solution]

Most of the work is done for the event I talked about. Now some testing and writing documentation. Assuming we don't run into any unexpected problems I expect it to be available in January.

Yes, I will be at AU. Let's be sure and connect there.