Macros vs Global Macros

[Alaskan_Son]

On 10/9/2022 at 8:51 PM, buildology said:

We have a Text Macro for wall type - to change it we need to open the Text Macro editor find the Macro edit it and close it. We have lots of different Text Marcos so doing this for every one takes quit a bit of time.

 

Just so you know, there are plenty of other solutions that haven't even been discussed.  For example, why not place all these variable assignments into a single Parent macro?  Set that macro to include nothing as its last line ("" or nil) and then wherever you want to use one of the variables you simply place both the Parent and the Child.  Example:

 

"parent" macro definition:

$a = 1

$b = 2

$c = "apples"

""

 

Placed into your desired label, note, callout, or text box:

%parent%%$a+$b% %$c%

#=>  "3 apples"

 

or one of several other optional formats;

%macros.parent; "#{$a+$b} #{$c}"%

 

All your assignments are made in a single place and because the parent macro is always placed with any child macros, the results are always accurate.

 

 

You could also define Classes and Methods like so:

"parent" macro definition:

class MyClass

  def a

  1

  end

 

  def b

  2

  end

 

  def c

  "apples"

  end

end

MyClass.new

 

Placed into your desired label, note, callout, or text box:

%macros.parent.a+macros.parent.b% %macros.parent.c%

#=>  "3 apples"

 

Again, all your assignments are made in a single place, and even though Classes and Methods are global by nature as well, they will always be accurate per the current plan because you're referencing the defining macro in every location that its being used.

[Alaskan_Son]

By the way, you can also skip the use of Globals altogether and simply use a hash:

 

Example Hash:

name:  test

value: {:a => 1, :b => 2, :c => "apples"}

 

Example Usage:

%macros.test[:a]+macros.test[:b]% %macros.test[:c]%

#=>  "3 apples"

 

 

 

[SHCanada2]

4 hours ago, Alaskan_Son said:

You place the required macro(s) into the required views in your template plan.  Once and done.

I was more thinking if he created new elevations, he would need to copy them (CAD block) around. i.e. he could not just put down a text box with $roof in it, as $roof would still be the roof from the other plan, if he came from the elevation of the other plan 

[SHCanada2]

On 10/13/2022 at 1:14 PM, buildology said:

I have been playing around with Global Variables for wall notes and elevation heights but run into issues when I have two plans open.

so i think the simplest method for you is to just change your macros to use a hash, and set a macro in the file to be the filename, manually.

 

Step 1. create a macro in your .plan file called "filepath"

Step 2. when you create the .plan file or rename it, you will have to go into that macro and set it correctly, or more importantly uniquely. For instance : "C/owner/63 pleasant Dr v0.4"

Step 3. On your cad detail page where normally you have something like $roof=label, now you would have %$configHash[[ macros.filepath,"Roof" ]] = label%

Step 4. For text box on elevations or elsewhere, put in the text box, %$configHash[[ macros.filepath ,"Roof" ]]%

 

The other ways to do it are more complex. One is to require a box on each view. If you are willing to have a box on each view, then you can eliminate the manual assignment of the macro filepath. As Michael mentions you can have it in your template file, but I think and he can correct me if I am wrong, you would have to add it to each new elevation you create.

 

I'll see if I can eliminate the box requirement, but so far no luck. 

[buildology]

5 minutes ago, SHCanada2 said:

so i think the simplest method for you is to just change your macros to use a hash, and set a macro in the file to be the filename, manually.

 

Step 1. create a macro in your .plan file called "filepath"

Step 2. when you create the .plan file or rename it, you will have to go into that macro and set it correctly, or more importantly uniquely. For instance : "C/owner/63 pleasant Dr v0.4"

Step 3. On your cad detail page where normally you have something like $roof=label, now you would have %$configHash[[ macros.filepath,"Roof" ]] = label%

Step 4. For text box on elevations or elsewhere, put in the text box, %$configHash[[ macros.filepath ,"Roof" ]]%

 

The other ways to do it are more complex. One is to require a box on each view. If you are willing to have a box on each view, then you can eliminate the manual assignment of the macro filepath. As Michael mentions you can have it in your template file, but I think and he can correct me if I am wrong, you would have to add it to each new elevation you create.

 

I'll see if I can eliminate the box requirement, but so far no luck. 

Thank you so much, I give it a try.

Adding a box to each view would not be a problem if that makes it easier. 

[Alaskan_Son]

21 hours ago, SHCanada2 said:

I was more thinking if he created new elevations, he would need to copy them (CAD block) around. i.e. he could not just put down a text box with $roof in it, as $roof would still be the roof from the other plan, if he came from the elevation of the other plan 

 

This is true, but upon creation of a new elevation that uses those variables, the user is almost certainly going to be copying other stuff anyway,  Might as well just group select that item as well.  Regardless, it only takes a matter of seconds.  Depending on the approach taken, the macro(s) could even be placed in a default label or default text box thereby alleviating the need to copy anything. 

 

Your suggested approach (using a Global hash with a unique key set by the user for each new plan) will work as well, but in large part, you're just kicking the can further down the road.  Not only does each user have to remember to change that key with each and every new plan and for each and every new plan iteration, but they may even need to change it for each and every user.  PLUS, the global hash would never even get populated until the CAD Detail were opened up.  That means for every single session for every single plan, a person would have to first open that CAD Detail if they wanted to see the appropriate values. 

 

The bottom line is that if you're going to be using Global variables, you'll get the most stable, consistent, and predictable results if the macros that define the variables can be placed in the views that are using the variables.  This isn't always possible, but when it is, I would highly recommend doing it.  All other approaches rely on shutting down and restarting Chief, shutting down and restarting plans, opening specific dialogs during various operations or during each session, opening or scrolling through specific views in each plan or session, and/or maintaining some other complex routine to ensure accuracy.

[SHCanada2]

6 hours ago, Alaskan_Son said:

The bottom line is that if you're going to be using Global variables, you'll get the most stable, consistent, and predictable results if the macros that define the variables can be placed in the views that are using the variables. 

 

 

6 hours ago, Alaskan_Son said:

That means for every single session for every single plan, a person would have to first open that CAD Detail if they wanted to see the appropriate values. 

this is a good point, but they already must do that today, so it must already be part of their workflow.

 

But then again why bother putting the graphic macro assignment on the CAD detail? One could just put it off to the side of the floor view, as small as practical which i think you pointed out earlier. The floor view would be seen every time, and the global macros populated without having to flip to the CAD detail. 

 

6 hours ago, Alaskan_Son said:

but they may even need to change it for each and every user.

I think this would only be the case if the filenames and paths were the same for two files, and if that was the case then they would have larger issues if they are sharing two files with the same name/path. 

 

 

[Joe_Carrick]

On 10/13/2022 at 6:15 PM, buildology said:

Regarding wall schedule we do use them and it works really well but how do I get that information to elevations?

I have a "Walls" macro package that labels walls in various views.  There's on macro that determines what the view type is and creates the label accordingly.  For Sections and Elevations it displays the Finish Wall Layers (exterior or interior depending on the view).

 

This will be available once X15 Public Beta is released.

[SHCanada2]

On 10/14/2022 at 3:48 PM, buildology said:

Adding a box to each view would not be a problem if that makes it easier. 

well I decided to try out some other things and did get it working such that a, lets call it "initialize filename variable" assignment box is not required on  elevations. the filename is required in order to know which roof value to get from which file

 

It does have three limitations that i can see. 1. it uses the default exterior wall label to make the assignment (actually for me I used the foundation wall label, because I always have a foundation) so it you use this label for other purposes, then this will not work (although you could use the roof label if you wanted). I assume these are wall details like Rene showed so I assume it is not applicable to interior elevations. If it was you could add it to the internal wall default label

2. backclipped sections dont have any objects (well sometimes a roof), but no wall, they look to be just cad lines. so backclipped elevations would need the assignment box copied to it if you wanted these macro details there

3. the default labels are only for plan view,, so one cannot offset the label to be lets say,  below the house on elevation. Instead one has to either i) set the colour of the label the same as the wall (which is why I put it on the foundation as its always concrete ii) make the text style tiny and transparent or iii) move it manually, but if you are going to do that, might as well copy an "assignment box" onto the elevation

 

video below shows the behaviour. The global variables are assigned on the CAD detail, and then you can switch between elevations on each plan, and the global variable which was last "set" on one does not get shown on the other.

 

It is using a global hash with the filename as the key, so there are two unique pieces of storage for the two values within the hash (essentially an array).

 

And if one ios wondering why an initialization box to set the filename is required...well, it get the roof type for that file I neede the filename, and the filename is stored in a global variable, so itself would ne incorrect when moving to the next file. This means the filename global variable is being updated by the wall label to ensure the retrieving of the values from the hash is using the correct key I thought there might be a race condition problem here where the value gets retrieved prior to the setting of the filename global variable, but so far I have not observed one