October 7, 2015 at 18:42 #1666
In my library I have moulding objects that can create standard shapes that we use frequently. This is done by storing the shape data in macro files which the various moulding objects can call.
Now I am making a label to automatically name the moulding shapes. The label uses ASSOCLP_PARAVALUE to get the names of the mouldings. These are of course strings.
The names have the form: “Crown SM-38”. This is how they appear in the parameters of the moulding objects, and how the macro files are named. For the label, we would prefer the text to say “SM-38” or “SM-38 Crown”.
From a performance standpoint, which method is better:
1. Use string parsing within the label to cut up the ‘words’ and rearrange or eliminate them.
2. Put the modified names in the shape macros, and call the macros from the label to look up the names.
Or, does it not matter, since there will only be a few labels in a typical viewpoint?
October 7, 2015 at 18:58 #1667
In your moulding object, how do you select which macro to use? Is there a string parameter for that, and you added a “values” command and a value list in the parameter script?
Anyway, I think I wouldn’t call the macros from a label…
Team Leader, Library Team
October 7, 2015 at 19:13 #1668
Yes, string parameter from a values list. The macro is called by variable, which is discouraged in 19+ but I don’t see a way around it.
I will try the parsing approach. Thanks for the quick reply!
October 8, 2015 at 08:30 #1670
Maybe there is an easier solution if you add 2 more hidden parameters to your object, for example
shortCode, longCodeand then fill them in the paramscript by the user chosen type:
values “type” “Crown A-01”, “Crown A-02”, “Crown A-03” if type = “Crown A-01” then parameters shortCode = “A-01”, longCode = “A-01 Crown” if type = “Crown A-02” then parameters shortCode = “A-02”, longCode = “A-02 Crown” if type = “Crown A-03” then parameters shortCode = “A-03”, longCode = “A-03 Crown”
After you made this, your label could easily ask the values of
longCode, and you don’t need to split up strings.
Team Leader, Library Team
October 9, 2015 at 12:05 #1694
That’s a good solution that I considered as well, but the trouble is that it sort of doesn’t scale because I have dozens of shapes implemented in numerous objects. That’s why I keep as much data as possible in the shape macros themselves. Then it is just a matter of creating a new shape and adding to the appropriate vales lists.
I went ahead with the parsing solution with a long and short option, working fine. Thanks again for your help.
You must be logged in to reply to this topic.