Copy reference planes when copying legends to other docs

[bitsy]

I've made some changes to ensure that reference planes get copied properly with legend views. The previous code copies all reference planes in legends to the model space (yikes!). This update basically recreates each reference plane in each new legend in the target doc, and it also creates new subcategories and line patterns IF they don't already exist in the target doc.

I'm not familiar with the pyrevit libraries yet, so there may be some less verbose ways to accomplish the same thing. Please feel free to nitpick and suggest changes. :)

@sanzoghenzo, thanks for responding to the issue! Here's the code.

I do have one issue: creating reference plane subcategories through the API causes these new subcategories to be subject to the scale of the view. Typically, a reference plane line weight/pattern is constant scale (scaled to the display rather than the paper space). However, when I create subcategories with the API, the new subcategory line weights/patterns are scaled to the paper space:

Expected Results (Left) -> Actual Results (Right)

[sanzoghenzo]

I didn't test it, but for now I suggest some code style changes for better readability

[sanzoghenzo]

Instead of creating the objects directly inside the dictionaries, use variables to hold them and add them to the dictionaries only at the end.
If you combine this with the comment above, you can create a function that returns the two objects, and the if branch only adds them to the dictionaries:

if src_subcat.Name nor in dest_subcats:
    subcat, pat = create_dest_subcat(....)
    dest_subcats[src_subcat.Name] = subcat
    dest_pats[src_pat.Name] = pat

[bitsy]

I reworked this bit of code a bit differently than you suggested. The weird thing about this construct is that if the function returns a solid line pattern, it would get added to the dictionary, which is not desirable. Committing the changes soon...

[bitsy]

@sanzoghenzo - I made the suggested changes. I think overall it's a net positive for readability, but my function match_subcategory could still use some clarity when creating line patterns...I'll review this again.

What's a good convention for passing arguments into the function vs. just modifying variables directly from the parent scope? While readable, the functions assumes that variables like dest_subcats and dest_pats already exist, which seems like it makes the code less editable in the future. Having started my programming journey in C++ years ago, I find the "squishiness" of scope in python baffling at times. 😅

[sanzoghenzo]

Hi @bitsy, sorry for not getting back to you sooner, busy with the revit2025/pyrevit5 thing 😅

As you can see @jmcouffin changed the branch to which merge the change to develop, since we got to a point that version 5 (beta) is somewhat usable; unfortunately this introduced a ton of junk on your PR.
If you don’t want to spend too much time resolving the merge conflict, I suggest you to:

• backup the files you edited somewhere outside the pyrevit folder
• Fetch the latest changes from the pyrevitlabs repo (if you didn't do already, add the repo to your remotes as "upstream" or "pyrevitlabs")
• reset your branch to the latest commit on upstream develop
• re-add your files
• commit and force push your edits.

What's a good convention for passing arguments into the function vs. just modifying variables directly from the parent scope?

Generally it is a code smell to modify parent scope variables, as it result in highly coupled code instead of reusable functions.
You could add the variables as function parameters, but this will introduce side effects, that is, you're modifying an input instead of returning a value and avoid touching the input parameters. This is forbidden in functional programming, but allowed (and misused) in a flexible language like python. It's doing object oriented programming without objects (your entire module is your class).

Instead of doing it all in a function, just extract the portions that create and set the attributes of an object (like the dest_subcat) and return that object; the "parent" function will do the existence checks on the dictionary, call the function and insert the resulting object if it isn't already there.

[bitsy]

@sanzoghenzo, thank you for your thorough response, and no worries! I myself am neck deep studying for the ARE on top of work... And I super appreciate y'all working on pyRevit 5. I'll do as you suggest: copy my work and reset. I'll also do a little refactoring of those functions to make things cleaner.

[jmcouffin]

I shall close this one then. Thanks @bitsy