SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

[Jeff Galbraith]

As has come up in many previous posts Archicad uses 'Width' for Windows, and 'Length' for Curtain Walls, causing graphical issues in Window Schedules. I was hoping to create an expression based property that returns the value for 'Width' if the object is a window, and 'Length' if the object is a curtain wall. I tried the following but it didn't work:

IF (Length > 0, Length, Width)

Unfortunately it didn't work. Any ideas of how to make this work.

[poco2013]

Your expression will not work because you are using a attribute which is not applicable to the element being evaluated.
That is you are using in the same expression, both length and width . Width can only be used for windows, etc. and length for curtain walls. -- As you have said. So, any window or curtain wall which sees both attributes will mark one or the other as not applicable and fail.

The solution is to make two separate sequences (expressions) in the same expression using the ADD button,
One which will apply only to windows and one which will apply only to curtain walls. In evaluating the expression, the program will only use the applicable sequence for the correct element.

FYI: make sure you have correctly set the classifications for both elements.

[Jeff Galbraith]

Thanks Poco, that seems to have gotten me half way there, but unexpectedly, when there are 2 windows with the same width or length the expression multiplies the length by the quantity...which is not what I want. Any Idea how to fix this?

The way I wrote the expression was super simple. I just added 2 separate entries in the expression editor, one for Length and the other for Width

[Jeff Galbraith]

It would seem as though expressions have a 'summation' quality built into them when multiple items meet the criteria, which does not appear to be readily overridable. It also does not appear that I can reference the 'quantity' of similar elements. if I could reference the quantity then it would be simple to divide the Length & width parameters by the quantity to negate the impact of the built-in summation process. Is that possible?

[poco2013]

Expressions only have knowledge of the properties of the object they are attached to. They can not sum multiple elements even if they are identical.

I'm guessing the problem is with your schedule criteria. Would need to see your expression formula(s) and the schedule criteria Screen shots

[Jeff Galbraith]

It is most definitely adding them together. I just rebuilt the scenario in a standalone file with nothing in it but a wall, 2 windows and 2 identical curtain wall elements. The schedule criteria was minimized to avoid potential conflicts. See screenshots below.

[Jeff Galbraith]

...even if you reduce the expression definition down to a single entry for either width or length it still sums up the width of all identical elements. Seems like a bug. I see no reason that the attribute 'Width' would be treated one way when used in a schedule directly, but treated quite differently when used via an expression.

[poco2013]

The expressions are being summed within the the schedule not the expressions because you have "merge uniform items checked"

You could change the ID's to be different or Just change the expression to return a string instead of a number.

STR ( {Property:General Parameters/Width} / 1 ft, 2 ) -- returning string

[Jeff Galbraith]

That's definitely progress! Is there a way to convert the string output from decimal units into feet and inches?

[poco2013]

In Calculation Units and Rules -- change length units t0 ft & fractional in -- Change STR tp STRCALCUNIT and drop units canceling

STRCALCUNIT ( {Property:General Parameters/Width} )

Unfortunately, this changes the units for all expressions and schedules -- no way around this -- for now