Some Third Party Libraries Have to be Updated for ArchiCAD16

[Katalin Takacs]

FYI:
Please check out this article about ArchiCAD 16 if you are using third party libraries in your projects: http://archicadwiki.com/Bugs/3rdPartyLibraryUpdateFor16

[Anonymous]

Thanks Katalin,

Wiki:

These objects use the 'values' GDL command in a way that is no longer supported in ArchiCAD 16. As a result, some parameters of already placed objects may change in an unexpected way.

I wonder what this non supported way of use is?

Thanks for info.

Best regards, Juha

[Karl Ottenstein]

Juha wrote:
I wonder what this non supported way of use is?

See Ralph's post here:
http://archicad-talk.graphisoft.com/viewtopic.php?p=205334#205334

[Anonymous]

Thanks Karl and Ralph, that clears things a lot.

I wish GS updates this documentation asap.

Changes in the interpretation of GDL

Regards, Juha

[Katalin Takacs]

Thanks for your observation, I have updated the article.

[Ralph Wessel]

Juha wrote:
I wonder what this non supported way of use is?

As an example, let's say we have a text parameter called "openingType". If you wanted to allow the user to enter a value, you would write the following:

ui_infield{2} openingType, 0, 0, 100, 18

If "openingType" was an array, i.e. it could hold more than one text item, and you wanted to allow the user to edit the second text item you could write:

ui_infield{2} openingType[2], 0, 0, 100, 18

In either case, you could constrain the opening types the user could select by adding the following:

values "openingType" "Door", "Window", "Panel"

When the user edited the item, they could only pick the specified values. It only applied when the user was editing the parameter, and only to the value they were editing. If item 1 of the array was "Frame" and item 3 was "Pane", they would remain untouched.

But this all changes in ArchiCAD 16. The new VALUES command changes all values in an array and not just when the user is editing them. Any value not matching the specified list will be automatically reset to the lowest value. So if my openingType array was in a window object and was set to:

• "Frame", "Window", "Pane"

...and the user moves the wall containing the window, the VALUES command will reset the values to:

• "Door", "Window", "Door"

This makes it quite risky to apply the VALUES command to any array. I'll be interested to see how the new command is to be used when the documentation is updated. I would have preferred to see this implemented as a VALUES{2} command as has been done in the past, and thus preserving backward compatibility.

[rocorona]

it would have been more honest to call it a bug. A bug that will not be fixed.

Very bad. This is the first time that the GDL interpreter is not fully compatible with the older scripts

[Ralph Wessel]

rocorona wrote:
it would have been more honest to call it a bug. A bug that will not be fixed.

That was my first thought too - I actually reported it as a bug initially. But it transpires that the change is in accordance with future plans for the VALUES command, and therefore not a bug. I'm not too concerned from a development point of view - changes happen all the time and this one isn't difficult to cope with - but I'm worried that this causes silent data changes that may go unnoticed for some time. It's risky from a user perspective. It would have been better if there had been perhaps 1 year's notice so their would be time for a planned migration.

[rocorona]

Ralph wrote:
but I'm worried that this causes silent data changes that may go unnoticed for some time.

Agree. That's the real bad point. Although I'm sure that use of VALUES with array variables is very rare. I think I've never used it... but I'm NOT sure. There are lots of object I've made and forgot during the years.
As you mentioned, why not create a VALUES{2}, for the future enhancements, preserving the compatibility with all the existing objects?

[jshuether]

I do know I have used the value script with arrays in a few parts that I have scripted. It seems like VALUES{2} would be a no-brainer. Another no-brainer for Graphisoft would be to be to purchase Ralph's objects outright and package them with ArchiCAD, or maybe put Ralph on the payroll so he can be a permanent adviser for the program developers. I sometimes think the most knowledgeable people are not working for Graphisoft--I guess that's kind of like most governments...