when AC12 Libs updated will they stop relying on macros?

[Erika Epstein]

One of Archicad's strengths has been the ease with which users of many levels can customize parts because the GDL script was easily accessible.
In AC12, most doors & windows now call macros; there is no easily editable script. I understand the advantage of macros, but it's too hard to customize these parts now.

When the long overdue overhaul of at the US library finally occurs, will we get this feature back?

Or, am I the only one who doesn't prefer the macros?

[Anonymous]

Hello Erika,
One of the reasons that I do not use AC windows and doors
and exclusively use only ones I have written is because of
this macro issue. In AC 6.5 and before the only macro used
in windows and doors was a macro that made muntins.
By AC 8 GS had decided to rely heavily on macros and we
have been seeing the consequences ever since. Such things as the
notorious wa_trim_us that has been causing problems in
all it's incarnations ever since. Five versions later, GS has not
reversed them selves on this decision. I wrote once in a thread
I initiated called Learning GDL that it was now impossible to
learn GDL by studying the scripts of AC windows and doors
because of the byzantine system of deeply embedded macros.

I do not like macros and, with one exception, none of my
lib parts contain any for the reason you state, editing a lib
part that contain macro calls is impossible because it's
macros are used by many different parts and the consequence
of changing it for the sake of one part will probably be to bust
other parts that uses the same macro.

I would like GS to change their mind and reverse their AC 8
decision but I do not think it likely.
Thanks,
Peter Devlin

[David Maudlin]

Erika:

I know this is not what you want to hear, but I think removing macros is not feasible. Using Peter's example of the macro for window muntins, which is used for all the rectangular windows in a library: If a developer wants to correct or enhance this bit of code, then he has the choice of using it as a macro and making the change in one place, or needing to open each window part and alter the code within each part. From a debugging aspect, the macro should be a more efficient strategy, since a bug fix in the macro should cure the bug everywhere (assuming a consistent use of the macro for each part).

The Graphisoft library parts have just become enormously complex, with or without macros. Trying to sort through the if/then statements in some parts (like the Sect-Elev Marker Macro USA, which is, yes, a macro for the Section Marker_NCS 12) ain't easy. With this level of complexity, some other approach for making the parts user editable is needed, the macros themselves are not the heart of the problem.

Just my 2 cents. ; )

David

[vistasp]

Macros are a pain when they go AWOL. Suppose, just suppose, macros can be embedded in the parent object so that the latter are distributed to users without fear of error. Developers, on the other hand can, if they choose, change the original macro file and update all objects that call it. Something like library items in Dreamweaver. Would that be a solution to this problem?

[Laura Yanoviak]

Erika wrote:
In AC12, most doors & windows now call macros; there is no easily editable script. I understand the advantage of macros, but it's too hard to customize these parts now.

In AC10 and AC11 most doors & windows call macros -- I know, because I've customized them all -- how is this different with AC12 (I am not actively using AC12)?
We have custom 2D symbols for existing doors, custom Listing Parameters, and I've scripted double doors to list as a pair of doors in schedules. I cringe whenever a Library update is released -- will it be worse when we upgrade?

[Anonymous]

David wrote:
The Graphisoft library parts have just become enormously complex, with or without macros.

I can't agree more with David. Key word is overcomplexity, not macros.

GDL is a limited language, that's ok. Nevertheless, if you take it as it should be (simple), you can accomplish some interesting things.
Since last versions, GDL adds patches over patches, to hide it's limitations. The result is overcomplexity and bugs.

I don't think GDL can evolve, except a complete rewriting. I would like to be wrong.

[Anonymous]

Hello Olivier,
You wrote:
"if you take it as it should be (simple), you can accomplish some
interesting things." You have certainly demonstrated this over and
over in your library parts. You also wrote:
"Since last versions, GDL adds patches over patches, to hide it's limitations.
The result is overcomplexity and bugs. I don't think GDL can evolve,
except a complete rewriting."
Do you mean rewriting the library or do you mean rewriting GDL ?
Thanks,
Peter Devlin

[Anonymous]

Peter wrote:
Do you mean rewriting the library or do you mean rewriting GDL ?

Hi Peter,

GDL language, of course. Don't dream, I'm not optimistic on this one.
15 years afters, pratically nothing has changed, except adding complexity where it should not. 😉

[Anonymous]

Hello Olivier,
Do you remember about two years ago Frank Beister initiated
a dialog with GS R&D about GDL ? As I remember, GS said they
were contemplating some changes to GDL but I don't remember
the details. It was no complete rewrite as I remember but it was
some progress. I have always wondered if it is possible to rewrite
GDL and still have it work in AC. I have no idea what the implications
of a rewrite might be. I think I will ask my brother who is a software
developer what he knows about such things. Do you remember
anything about what Frank reported about what GS said ?
Thanks,
Peter Devlin

[Anonymous]

I hate macros!