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?

[Piotr Dobrowolski]

Regarding AC doors (at last 10-12)....As I looked through the code...almost (I am not quite sure if not all) all doors call the same macro - so the all doors could be, with relatively not much effort, incorporated in one object . - I think the ease of use made the developers to make more types that call the superdoor macro...
I think that superdoor should be added to the library - and it would ease the end user modifications for the custom needs,

I hate macros as well (prefere subroutines), but when developing a big library they are the need...as editing, fixing the same string in lots of parts would take much more time (I know of, and use, and hate also the xml-ing the library which can be used for such fixing and translating, but completly useless for pure writig GDL as there is no possibility to view the results of the just written code)

Best Regards,
Piotr

[David Maudlin]

Laura wrote:
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?

Laura:

Just a continuation of the evolution of the parts, the general approach has remained the same. For example, now that version 12 has Partial Structure Display options, the windows and doors needed to account for/take advantage of this feature, so additional code has been added. I don't envy your need to modify these parts.

David

[Erika Epstein]

Laura,
As David and others noted, more parts rely on macros. For someone like me who is not as savvy and accomplished at GDL as you, finding and changing macros adds a level of complexity that I am not yet comfortable with.

One of the strengths of Archicad has been the relative ease that someone of my GDL skill-level could effectively edit parts; creating our own versions based on existing Archicad parts. This has become noticeably less true in these last few iterations of archicad.

About the only plus of this lousy economy is I now have time to work on my GDL skills along with other 'been meaning to...' tasks.

[Anonymous]

Erika wrote:
One of the strengths of Archicad has been the relative ease that someone of my GDL skill-level could effectively edit parts; creating our own versions based on existing Archicad parts. This has become noticeably less true in these last few iterations of archicad..

Erika,

You explain in few words, exactly what I think. Thanks.
Unfortunatelly, fun is gone. GDL is now for pure programmers, no more for architects. Pity.

Notice the inflation of macros, in particular for windows.
W1 Casement 12, for eg. More than 30 macros, not counting UI images.

Despite (because?) this inflation, there are still problems (wallniche tool) with windows and inclined reveals in thick walls.
For myself, I can no more fix it, too much complex and time consuming.

Yes, fun is gone. Amen.

[Anonymous]

Macros are a necessary evil as the GDL now stands. I try to avoid them but often they are the best way to get the job done.

It seems to me though that this problem could be fixed with a new GDL editor including:

1. A visual environment showing the links between the primary scripts and called macros with lists of passed parameters. (This is not the Visual GDL for graphic parameter editing - though that would be past terrific also.)

2. The ability to compile these working files into executable standalone library parts, ie macros included.

This way it is possible to use macros as they presently are for creating common code objects to be shared among similar library parts, but without having to be sure the silly things are always loaded by the user.

Of course some other great features for this fantasy editor would be:

a. Graphic editing of dimensional parameters.

b. Full featured text editing including color coding, keyword autocompletion, loop tracking with auto-indenting, and so on.

c. A running indicator of the transformation stack. ("Now was that six add statements or only five? Do you feel lucky? Well do you punk?")

d. Self documentation tools.

Oh well, we can dream...