I’ve built a script that creates elevation views of individual elements of a given category and sets the view name to match the mark value of the element for each elevation view. The script works as I intend, but I want to build in some error handling to keep the script from attempting to create views that already exist, so that it can be run multiple times in case additional elements are added. (Right now, to successfully run the script any additional times you have to delete all of the elevation views that already exist for the elements of the category you are trying to run the script for.)
Is there a way to filter out the elements that already have a view created for them?
My thought is to have Dynamo get the value of the mark parameter for the elements and check to see if there is a view that already exists with a name that matches the mark parameter of the element and then exclude those elements prior to creating any views.
That’s what I’d do. In scenarios like this you basically have two steps:
- Organize data for object creation.
- Create objects.
In order to avoid duplicates, you just add an additional step before the object creation:
Anything that already exists gets removed, then you continue creating the new objects.
Ok, sounds like I’m on the right track then. I’m having trouble implementing the data check prior to creating the objects and need help with the workflow.
The drawback for using mark for this type of data will come with renumbering.
Say on day 1 you have 10 gizmos to document, with marks from 1…10. Run the graph, no issues 10 new views.
On day two someone adds an 11th gizmo, deletes number 10, and sets the mark for the 11th gizmo to be 10 (as one should do). Run the graph and no new views are created because we have matching marks.
One possible method to prevent this:
- Gather all elements you want to document, and all the existing views documenting them.
- Then get all elements visible in the views.
- In the original views (#2), filter out any views which didn’t have one of the elements in them, and delete the view (you no longer need it as the object it was documenting doesn’t exist).
- For the original views which did have an item in them (#3), update the view based on the mark of the target object which it contains.
- Back to the list of elements(#1), filter out any elements in the list of elements to document if they exist in the list of elements in the views(#2).
- Make new views for the elements which were not found in any of the views, setting the mark accordingly.
Another option is to just delete all (appropriate) views and run as new every time. This will ensure that the views in the project always match the objects in the project. I do this with parameter values all the time, because it’s generally faster, easier, and less management. Depending on how many views you expect and how you’ll be filtering your elements, this may or may not be a time save, but it’s worth trying out.
1 Like
Only drawback is the potential for lost annotations, which I guess could be automated or may not exist. Sadly as annotations live on the respective view workset there isn’t a way to keep them as deletion of the view also deletes the workset. 
Fair point. This would only be for if everything was automated in a single graph. Annotation would become it’s own issue otherwise as you’d likely run into similar problems running a separate annotative script.
1 Like
I did consider this, just having the script delete all views prior to creating any, and having it create new views every time. My biggest concern with that though was just as @jacob.small said, losing annotations, or really any work that had been done to the views already.
Hence, why I would rather have filtered out the views already existing and ensured that only views for elements that didn’t already have them were created.
That is very true, and I’ve run into similar issues before with other scripts.
I do like the idea of the solution that you provided for this though, and will have to give it a shot. Thanks!
1 Like
Good luck! You might want to consider building dictionaries of the relevant data for each object type, as the list structure could be a bit cumbersome.
1 Like
I would be interested in the dyn file if you don’t mind sharing it. I am trying to create views for Generic Models that have a specific parameter. I believe I need to specify the value by query. The tricky part is these are project generic models and nested generic models however I would to break these out almost as individual pieces for detailing. Thanks for any time in answering my reply. I’m really new using dynamo.