AddingObject with a RubyMacro to the library

[BrownTiger]

I would like to have labels [like RoomLabels] to display different information based on the layer set. The concept is useful to display floor finish,

but only for intended layer set, or ceiling height again only on requested layers, vent requirements, etc. See pictures

 

 

Same macro displays different data based on the presence of Show Requirements Label in the layer

 

 

[update]

Below are two projects provided two show how this is done. One is using two layers for toggle/ two macros, other simple using one layer.

This also works well for walls where you can display wall sq ft -> for drywall estimating, or displaying roof plane sq ft on special "Roof Layerset Sq Ft"

- to help a builder estimate the cost. Displaying header information in the framing layerset etc.

 

 

[Original text]

The premise is simple, create an object  "Show Requirements" label is visible. Layerset 2 will hide this label, show object  "Show Requirements" -> Label will execute macro to set some global e.g. $RequirementsShow = true, screen refreshes room label displays different information.

 

Now I would like to add my objects: show requirements and hide requirements to User Library.. No problem.

However the macros associated with these labels are not added with them to the library.

 

example

Main Test Macro

if $RequirementsShow == true

result = "TOTAL SF - " + internal_area.to_s + "\n"

result += "VENT REQD - " + (internal_area * 0.04).round(0).to_s + "\n"

result += "DLO REQD - " + (internal_area * 0.08 ).round(0).to_s + "\n"

result += "FINISH: " + owner.floor_finish_name + "\n"

end

result

 

Children Label macro

$RequirementsShow=true

"Show Requirements"

 

Other

$RequirementsShow=false

"Hide Requirements"

 

Sooo, HOW CAN I ADD OBJECT CONTAINING A MACRO TO THE LIBRARY? 

[Alaskan_Son]

I haven't really studied your macros but I have accomplished this type of thing in at least a couple different ways...

1. Place the necessary macros into the object's label and if necessary simply set one or more to .clear or to return "".

2. Place the macros into one or more text boxes, block it/them, and add to the library. Again, you can set one or more macros to return "" or to .clear if necessary, OR you can set the text color to white or the text height to zero so the macro doesn't even show (if necessary).

It totally depends on exactly what you're trying to accomplish but hopefully one of those will work for you.

 

NOTE:  You can actually even simply use a place holder object.  A cabinet for example with the macros in the label.  Add the cabinet to your plan and then simply delete it and the macros will load.  Same thing with a text box or anything else for that matter.  Also, you can right click on any symbol or architectural block that's already in the library and then click on text macro management to either write or import any macro you want.  Any and all macros you add will automatically load with that object whether they're actually being used with that object or not. 

[Joe_Carrick]

The problem with this is that Labels are on separate Layers from the Object and you can't change the Label's Layer.  What's really needed is something like this:

 

Main Test Macro

if $RequirementsShow == true

  result = "TOTAL SF - " + owner.internal_area.to_s + "\n"

  result += "VENT REQD - " + (owner.internal_area * 0.04).round(0).to_s + "\n"

  result += "DLO REQD - " + (owner.internal_area * 0.08 ).round(0).to_s + "\n"

  result += "FINISH: " + owner.floor_finish_name + "\n"

else

  result = ""

end

result

 

It needs to be placed in the Room Label.

 

You will need two other objects (with labels) located on the specific layers to set the $RequirementsShow variable. 

 

There's no guarantee which macro will execute first, so to get it to work you may need to refresh the display (pan/zoom).  Architectural Blocks have Labels and the Labels will only be displayed if the Block Layer is displayed.

[BrownTiger]

I am going to post a plan I did in CA [ vs HA], may be someone else could benefit from it. [CA is my Lego Minecraft hobby, I like to create ala Breckenridge plans that could never afford to build]. 

 

Feel free to switch from "Default LayerSet to Default Layerset 2" to see it in action. Room Labels change as well as Windows labels.

[Really cool as I can display or hide windows/doors dimensions, headers, etc]

 

1) How can I create a library objects containing macros.

 

(obsolete) see No2

DemoMacro.plan

 

Thank you

[BrownTiger]

Same trick with No hide labels... No need to have two sets of toggle layers and two sets of labels (hide and show)

 

DemoMacro2.plan

 

"Toggle*" layers control what labels display 

[Joe_Carrick]

It would be even better if there was a LayerSetName available to Ruby.  Then the Room Macro could just check that to determine what to display.  We wouldn't need the extra macros on the Plan to determine what to show.

[Joe_Carrick]

BT,

 

Try this:

 

1.  Create a PSolid

2.  Marque Select and Block it (Architectural Block)

3.  Assign the macros to the Block Label

4.  Change the Layer of the Block

5.  Add to the User Library and name the Library Object.

 

Now whenever you place that Library Object on a Plan and that Layer is displayed the macro will execute.

[BrownTiger]

It would be even better if there was a LayerSetName available to Ruby.  Then the Room Macro could just check that to determine what to display.  We wouldn't need the extra macros on the Plan to determine what to show.

 

No dispute there. Also second plan "DemoMacro2.plan" has a lot less macros and pretty easy to use.

But do You think ChiefArchitect will be improving Ruby integration in X9?

 

Have you by any chance seen Sketchup Ruby addons? FULLY functional powerful plugins and third party library. 

[BrownTiger]

I figured out new Ruby trick. CA displays objects based on order of creation.

 

So if you create "Layer Set Options" object first, macro in it could initialize (refresh all ruby values).

Followed by "Show Labels" that will set the values.

 

Alternatively reset macro can be placed into Living Area Label.

[Joe_Carrick]

But do You think ChiefArchitect will be improving Ruby integration in X9?

 

 

I hope so - only time will tell.  There a lot of things I've asked for but I have no idea when they might decide to work on Ruby.

[Alaskan_Son]

BT,

 

Haven't spent a lot of time on it and I'm probably done playing around with this for today, but just a little side note for whatever it might be worth to you.  I remember now why I stopped using global ($) macros as any sort of toggle...it can be very finicky.  Macros will execute in unwanted fashions simply by opening or closing text macro management, and switching a layer set in plan can affect the view in layout even if the view in layout hasn't changed layer sets.  Anyway, you have to be EXTREMELY careful with the way you set up and execute your global macros to avoid unwanted results. It can be more of a hassle than its worth in many situations. 

[BrownTiger]

BT,

 

Haven't spent a lot of time on it and I'm probably done playing around with this for today, but just a little side note for whatever it might be worth to you.  I remember now why I stopped using global ($) macros as any sort of toggle...it can be very finicky.  Macros will execute in unwanted fashions simply by opening or closing text macro management, and switching a layer set in plan can affect the view in layout even if the view in layout hasn't changed layer sets.  Anyway, you have to be EXTREMELY careful with the way you set up and execute your global macros to avoid unwanted results. It can be more of a hassle than its worth in many situations. 

 

Not in my experience. First these are global values, but they are set/reset @current view. 

I would never be simply using a value set  by a macro on the floor 1 and read by a macro on floor 2. Because clearly IF you open another plan, mistakenly re-execute macro or had it set by a prior

loaded plan the value will not be correct. However, if your global value is set while viewing floor 1 and used immediately, it will be file. 

 

Macros execute

1) In the order of object creation. Thus I recommend if you creating new plan always place psolid (with an initialize) macro, prior to any walls created.

2) It matters not if an object is outside of the viewport

3) RoomLabels always refreshed when you change layerSet

4) windows / door labels are not redrawn. [They are redrawn if you roll back and force mouse zoom wheel.]

 

See if you can break my project. In fact you can open two projects at the same time and reset macro works correctly, besides side-effect are little. Change layerset again and it will be reexecuted.

[Alaskan_Son]

Not in my experience. First these are global values, but they are set/reset @current view. 

I would never be simply using a value set  by a macro on the floor 1 and read by a macro on floor 2. Because clearly IF you open another plan, mistakenly re-execute macro or had it set by a prior

loaded plan the value will not be correct. However, if your global value is set while viewing floor 1 and used immediately, it will be file. 

 

Macros execute

1) In the order of object creation. Thus I recommend if you creating new plan always place psolid (with an initialize) macro, prior to any walls created.

2) It matters not if an object is outside of the viewport

3) RoomLabels always refreshed when you change layerSet

4) windows / door labels are not redrawn. [They are redrawn if you roll back and force mouse zoom wheel.]

 

See if you can break my project. In fact you can open two projects at the same time and reset macro works correctly, besides side-effect are little. Change layerset again and it will be reexecuted.

 

I was only offering a side note because I've experienced problems in the past although I can't exactly place my finger on when and how those problems did or might manifest themselves.  At the very least it can be annoying if you have multiple viewports open and changing the layer set in one view (plan maybe) affects what you see in the other view (layout maybe).  Sure the problem will likely correct itself but its annoying nonetheless.

 

Anyway, having said all that, I still really like your idea and think it has quite a bit of potential.  I've been using a similar technique to toggle labels using layer names that are not the same in all layer sets...a feature Chief has stated that are doing away with.  I'm thinking that the method you've brought up may help replace at least some of what I am doing with that method now. 

 

I am thinking I would do things slightly differently than you are though.  Namely, I personally find it easier and a little more intuitive to just toggle the various label display options by placing a single toggle control into a polyline label and then using the line weight for that polyline as the toggle (0 = no label, 1 = automatic label, 2 = header, 3 = schedule number, or whatever). The line weight could easily be changed on a layer set by layer set basis. 

 

You could even block a Rich Text box with that polyline that may include not only all the necessary macros but also a description of which numbers mean what and they could even be made to display which label type is currently active in that view.  Not the same thing exactly but the box could have a reactive display like I did with this Kitchen Triangle tool I made a little while back...

 

https://chieftalk.chiefarchitect.com/index.php?/topic/10386-kitchen-work-triangle/

 

At any rate, I really appreciate you sharing, its a technique that seems worth exploring further. 

 

P.S.  I sent you a PM

[SHCanada2]

On 10/15/2016 at 5:24 PM, BrownTiger said:

Not in my experience. First these are global values, but they are set/reset @current view. 

I would never be simply using a value set  by a macro on the floor 1 and read by a macro on floor 2. Because clearly IF you open another plan, mistakenly re-execute macro or had it set by a prior

loaded plan the value will not be correct. However, if your global value is set while viewing floor 1 and used immediately, it will be file. 

 

Macros execute

1) In the order of object creation. Thus I recommend if you creating new plan always place psolid (with an initialize) macro, prior to any walls created.

2) It matters not if an object is outside of the viewport

3) RoomLabels always refreshed when you change layerSet

4) windows / door labels are not redrawn. [They are redrawn if you roll back and force mouse zoom wheel.]

 

 

On a layout I've been testing two layouts which create the same global variable, lets call it $layoutglobal, which is set by a macro, lets call it globalmacro. This macro sets the value to "Layout14". I create a read macro which is called readlayoutglobal and it has in it macros.globalmacro

 

If I create a textbox on my layout, lets suppose my layout file is called Layout 14, and put in %readlayoutglobal%. The text box will update to show "Layout14", as one would think.

 

 I save as my layout to Layout 15 and reopen Layout 14 as well (two layouts open)

I then change globalmacro in Layout 15 to have $layoutglobal="Layout 15". the textbox in Layout 15 changes to "Layout 15"

 

If i click back on layout 14, the textbox is still showing "layout 14". If i goto another layout page and add a text box and add the macro, it shows "Layout 14", if I go back to Layout 15 and do the same thing, it shows "layout 15".

 

I also created this global variable in a plan, and set it to "plan 15", but "plan 15" would not show up in either of my labels

 

This would imply one of two things, when clicking on a layout, the macros always fire, or if there are two global variables with the same name in two different layouts, there are two instances (effectively not global between layouts)

 

Either way this seems to guarantee one can depend on the global variable in the layout to not be overwritten? or am i missing a use case?

 

where I am going with this is:

The plan file layout box object in layout contains the "Referenced file". I could put in a macro in the label for the layout box which then retrieves all values of interest from the layout plan, and stick them in global variables, for use in the layou, with no fear of being overwritten from somewhere else

 

 

[Joe_Carrick]

Jason,

 

You keep trying to use global variables in the Layout.  You will be far more successful if you just use a macro in the Plan.  It can be in a Label - or in the case of rooms it can be in a text box placed in the room.  You really need to study what attributes are available for the different object types.  If you need a comprehensive way to do that let me know.  I have some macros that you can use within TMM that list them in detail - arrainged alphabetically.

 

I do use globals in some cases but only when I need to be able to retrieve a lot of data that may not be otherwise available.  In some cases I've used such macros to provide code compliance, engineering analysis, site area analysis, etc.  The objects in Chief's Plan files are full of useful information - but you need to understand how to use it effectively.

[SH_Canada]

i was testing global variables in the plan and it looks like they can overwrite each other if there are two plans open. If I may ask, how are you moving data from a text box on the plan to, for instance the CAD detail, to send to layout?

 

yes, I might be abandoning the global variables in layout. I'm trying something a little different at the moment.

 

[Joe_Carrick]

Global variables are persistent to the current instance of Chief.

Any file (plan or layout) that is open and sets a value to a specifically named global variable will change that global.

 

I have a very limited set of macros in my Layout file - just those that are Layout specific.

 

My Plan files have many more macros and are mostly relative only to the objects in the Plan. 

 

 

[SHCanada2]

also, thanks to @Alaskan_Son

 

for explaining a few things about macros:

1. macros fire when the text macro management box is opened

2. global variables instances on one view and used on that view should always be correct, as long as the macro which creates the global variable is called on that view (which seems to be my layout test above)