Run Command With Previous User Input

[rvtquestions]

Dear Community,

My question pertains to the idea of running a custom command utilizing a previously stored value or global variable without the need of repeatedly requesting the user to provide the input value each time it is rerun. For example, say there is an addin command "A" which would require the name of a RVT Linked File to collect room names from. Is there a way to prompt the user once to input the RVT link, so that each time the command is rerun afterwards it would automatically utilize that input?

There is a half baked workaround idea that comes into mind: Perhaps natively there is a custom project parameter "X" of some sort that would hold a string, in this case a RVT link name like : 000-ARCH, in which the user can input and change at any time. And thus within command "A" the code would get the parameter value of this custom parameter "X" to collect a RVT Link whose name == (Parameter "X"). Would this work? Has anyone tried something like this or similar? Or is there is a way to do all of this without a workaround straight in a single addin? 

[jeremytammik · Accepted solution]

If you implement an add-in, you decide yourself how it will prompt for input and where it should come from.

Therefore, it is perfectly possible (and quite easy) for you to implement your own scheme to handle what you need.

This reminds me of some implementation I implemented in the past to store add-in settings.

The add-ins I created them for provided one main button to launch the command using the current default settings, and another button that was generally hidden to launch a Windows form enabling the user to modify these default settings if so desired.

One of them is the HoloLens Escape Path Waypoint JSON Exporter:

http://thebuildingcoder.typepad.com/blog/2016/09/hololens-escape-path-waypoint-json-exporter.html#2 

https://github.com/jeremytammik/ExportWaypointsJson

It makes use of a stacked ribbon button, with various implementation options:

http://thebuildingcoder.typepad.com/blog/2016/09/stacked-ribbon-button-panel-options.html

I also implemented two different solutions for storing the settings:

• Store add-in option settings in XML using the .NET System.Configuration.ApplicationSettingsBase class
• Store add-in option settings in JSON using custom solution and JavaScriptSerializerclass

I hope this helps.

Cheers,

Jeremy

[RPTHOMAS108 · Accepted solution]

Either extensible storage or Revit parameters would work fine for this.

Perhaps review these within the RevitAPI.chm file and online. If anything is unclear then further specific help can be obtained here.

The important thing to remember about extensible storage is that once you create a version of a schema and use it, you can't change it. You have to manage it's replacement if you want to change it. So you create a legacy in your project files once a version of a schema is used.

Parameters are more straightforward in this respect, for simple storage.

Regardless of the benefits of eStorage such as ElementID tracking, I often just create a simple field and stick a serialised XML/Binary string in it. Tend to store UniqueIDs instead and verify their continued existence when bringing the information out of storage. I'm probably missing the full benefits of it in some other way.

[rvtquestions]

Thank you @jeremytammik

What you've suggested sounds like something I can really explore and make use of. I will take a look.

 @RPTHOMAS108

Good to know you've also done something similar. I appreciate the feedback.

Out of curiosity, is there a term/keyword for this type of coding or use of an application with different schemes (in this case, being able to run with a defined setting or run with a prompt)?

[RPTHOMAS108]

The general programming term I believe is 'persistence' i.e persisting data.