topic Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE? in Collaboration with other software

SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Jeff Galbraith — Sun, 26 Apr 2020 04:51:30 GMT

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.

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

poco2013 — Sun, 26 Apr 2020 05:25:29 GMT

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.

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Jeff Galbraith — Sun, 26 Apr 2020 15:20:25 GMT

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

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Jeff Galbraith — Sun, 26 Apr 2020 16:38:08 GMT

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?

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

poco2013 — Sun, 26 Apr 2020 17:10:06 GMT

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

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Jeff Galbraith — Sun, 26 Apr 2020 21:10:33 GMT

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.

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Jeff Galbraith — Sun, 26 Apr 2020 21:14:36 GMT

...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.

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

poco2013 — Sun, 26 Apr 2020 22:40:32 GMT

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

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Jeff Galbraith — Mon, 27 Apr 2020 00:33:06 GMT

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

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

poco2013 — Mon, 27 Apr 2020 01:37:01 GMT

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

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Jeff Galbraith — Mon, 27 Apr 2020 01:56:13 GMT

I appreciate all your help Gerry. That sound like a deal breaker though...as I imagine changing the units in all tables would have unwanted consequences...

What I still don't understand is why the property values get added together for identical items when the property is an expression. The schedule clearly does NOT add together the values that are returned by the basic 'Width' and 'Length' parameters, even with the 'Merge Uniform Item' option checked. It only happens in the column driven by the expression.

I would have expected the schedule to not know the difference, and not discriminate between data returned from the basic property 'Width', and data returned from the exact same element attribute delivered through the use of an expression simply pointing to that very same property.

ie: If 'Width' = 10, and 'Expression (Width)' also = 10...why does the schedule multiply 'Expression (Width)' x 'Quantity', but not 'Width' x Quantity?

Perplexing...

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

poco2013 — Mon, 27 Apr 2020 02:34:11 GMT

Schedules are not multiplying quantity times width but simply adding similar (identical) numbers. Probably width and length were actually converted to strings internally so they would not sum.

IOW -- this is a bug -- somebody forgot about expressions and the schedule is quantifying expressions. There are many other instances in which this is desirable. A switch was probably too much trouble for the programmer or someone thought it would be too confusing?

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Jeff Galbraith — Mon, 27 Apr 2020 16:27:37 GMT

There are times when I have wanted to convert decimal numbers into Feet and inches in excel and I have done it with a series of cells and equations that look something like this:

CELL 1: 10.70833 (feet)

CELL 2: 'INT (CELL 1)' returns 10

CELL 3: '(CELL 1 - CELL 2)' returns 0.70833 (decimal feet remand to be converted into inches)

CELL 4: '(CELL 3) x 12' = 8.5

CELL 5 is a string of values from other cells and added text for expression of the units...such as:

( (CELL 2) "feet" (CELL 4) "inches") and returns: 10 feet 8.5 inches

Is it possible to script something like this into the expression editor...potentially using several co-dependent properties..where each cell noted above is a different property?

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Jeff Galbraith — Mon, 27 Apr 2020 16:28:40 GMT

...sidenote...when a bug is discovered like this, do I report it, or is that something you do as a moderator?

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Karl Ottenstein — Mon, 27 Apr 2020 18:04:08 GMT

Jeff wrote:
...sidenote...when a bug is discovered like this, do I report it, or is that something you do as a moderator?

There have been no moderators in this thread... until now 🙂 But, moderators only moderate this forum - delete spam, move posts to proper forums, merger threads, etc. At times, someone from Graphisoft may notice a bug here - but you should always report yourself through your local support.

Cheers,
Karl

PS For the decimal to FFI example, even in Excel there is no need to stretch the conversion across so many cells. One formula will suffice.

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

poco2013 — Mon, 27 Apr 2020 18:34:59 GMT

Assuming that Calculation units are set in decimal ft -- you could do the conversion and output a string in one expression. AS IN some version of:

TEXTJOIN ( " ", TRUE, STR ( ROUNDDOWN ( {Property:General Parameters/Width} / 1 ft, 0 ), 0 ), "FT", TEXTJOIN ( " ", TRUE, STR ( MOD ( {Property:General Parameters/Width} / 1 ft, 1 ) * 12, 0 ), "in" ) )

However expressions have no way of knowing what the cal units setting is -- if set on something else -- would not work.

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Barry Kelly — Tue, 28 Apr 2020 01:02:20 GMT

The only way to avoid the automatic summation of some fields, is to turn off the schedule option to "Merge Uniform Items", so they all list separately.

Barry.

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Jeff Galbraith — Wed, 29 Apr 2020 15:00:57 GMT

And yet the schedule does NOT automatically sum the values of any of the other fields / properties...just the ones that are based on expressions...inconsistent programming.

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Laszlo Nagy — Wed, 29 Apr 2020 19:55:33 GMT

Jeff wrote:
...sidenote...when a bug is discovered like this, do I report it, or is that something you do as a moderator?

I will report this to GRAPHISOFT so they are aware of it.

Re: SCHEDULE EXPRESSIONS - SOLUTION TO WINDOW WIDTH ISSUE?

Barry Kelly — Thu, 30 Apr 2020 00:48:10 GMT

Jeff wrote:
And yet the schedule does NOT automatically sum the values of any of the other fields / properties...just the ones that are based on expressions...inconsistent programming.

Not just expressions.

https://archicad-talk.graphisoft.com/viewtopic.php?f=28&t=69085&p=307003&hilit=schedule#p307003

Barry.