Home › Forums › Problems and solutions in GDL › Documentation elements, text handling › Parse a string or call a macro?
- This topic has 4 replies, 2 voices, and was last updated 9 years, 1 month ago by James Murray.
-
AuthorPosts
-
-
October 7, 2015 at 18:42 #1666James MurrayParticipant
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?
James M
-
October 7, 2015 at 18:58 #1667Gergely FehérKeymaster
Hi James,
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…Gergely Fehér
Team Leader, Library Team
GRAPHISOFT SE -
October 7, 2015 at 19:13 #1668James MurrayParticipant
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!
James M
-
October 8, 2015 at 08:30 #1670Gergely FehérKeymaster
Maybe there is an easier solution if you add 2 more hidden parameters to your object, for example
shortCode, longCode
and 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
shortCode
andlongCode
, and you don’t need to split up strings.Gergely Fehér
Team Leader, Library Team
GRAPHISOFT SE -
October 9, 2015 at 12:05 #1694James MurrayParticipant
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.
James M
-
-
AuthorPosts
- The forum ‘Documentation elements, text handling’ is closed to new topics and replies.