topic US Library Door Problem in Libraries & objects

US Library Door Problem

Anonymous — Wed, 24 May 2023 10:38:41 GMT

Is it just me or are the US library doors and windows simply hopeless?

The main problem I am having is that when I select "custom" as the door panel type I am not able to enter anything into the custom field. I have tried in both the AC13 and AC12 libraries.

I had the Cadimage tools installed earlier to test them, and they had inserted their own (uneditable) panel type. Perhaps this is a residual problem?

Is this working for other folks? Do I have to do a more aggressive removal of Door and Window Builder?

BTW: Have others noticed that the GS door and window parts are now script locked? I understand that they don't want to get support calls about parts someone has modified, but it prevents me from investigating the issue

Re: US Library Door Problem

Erika Epstein — Thu, 11 Feb 2010 17:01:25 GMT

All

Re: US Library Door Problem

Karl Ottenstein — Thu, 11 Feb 2010 17:27:29 GMT

Matthew wrote:
The main problem I am having is that when I select "custom" as the door panel type I am not able to enter anything into the custom field. I have tried in both the AC13 and AC12 libraries.

This is a new feature, which is actually a very good one - other than a bit of name/term mismatching.

The text box for the Custom Panel Name is no longer a free-text entry field as in earlier versions. As you know, that led to various errors with users making typos and wondering why their door panels did not appear.

Instead, it provides a drop-down list of all loaded custom panels (called 'door leafs' in the Save Custom Component dialog) in your library - loaded or (in 13) embedded.

Thus, you can simply select form the available panels/leafs. If none are defined - which seems to be the problem you're having - then none show up. If you have "old" panels, you'll have to change their subtype so that they appear in the list.

The scripts are not locked AFAIK - they are just more obtuse than ever before. If you look at the Master Script, you'll see that the D1 Entrance door has this:

call "gs_general_door_macro_USA" parameters all gs_doorcode = "D1 Entrance"

So, you have to open the everything-including-the-kitchen-sink macro to see what is happening... and then you'll discover all of the other macros being called and wonder if it is possible for any human to sort any of it out! 😞

Cheers,
Karl

Re: US Library Door Problem

Laura Yanoviak — Thu, 11 Feb 2010 19:56:31 GMT

Matthew wrote:
The main problem I am having is that when I select "custom" as the door panel type I am not able to enter anything into the custom field. I have tried in both the AC13 and AC12 libraries

We had this problem in an AC12 TW file -- the recently created component was not in the drop down list -- tried reloading libraries but this did not help -- only after sending and receiving did the component show up in the dialog.

Karl wrote:
So, you have to open the everything-including-the-kitchen-sink macro to see what is happening...

Yes -- talk about putting all of your eggs in one basket! I have to customize ALL of the AC doors (primarily because we needed a unique symbol for existing openings, and we MUST have pairs of doors list correctly: PR 3'-0" x 7'-0" NOT 6'-0" x 7'-0"). It would be a disaster if GS begins to lock the scripts -- I hope this is not the case.

Re: US Library Door Problem

Anonymous — Thu, 11 Feb 2010 21:52:06 GMT

Talking about door panels, why are all the frame widths, panes, etc grayed out? I may be missing something, but currently I have alot of custom panels for a matter of a 6" stile vs 5" etc. Crazy.

BTW, Did you notice that they re-wrote many, but not all of the variable names from 12 to 13? Talk about code management issues! It seriously boogles the mind.

As proof of the madness: Door panel "Glass Framed" is upside down! The glass in the lower half and the wood panel is the upper half. Code is rewritten for items that haven't changed - what a great waste of resources and an obvious source of error. I'd call that an "unforced error". Grabbing defeat from the jaws of success, oh, did I get that backwards??

Recently I posted "AC13 - traditional window issues", lacking a full response I emailed my vendor. Her entire response, "I have forwarded your request to Support @ Graphisoft as we can not assist with the answer to this. The settings of the windows have become very detailed."

Oh really?

Snapped
PS To Laura: instead of rewriting all the doors, just write a new marker style. See this thread: http://archicad-talk.graphisoft.com/viewtopic.php?p=153685&highlight=#153685

Re: US Library Door Problem

Laura Yanoviak — Thu, 11 Feb 2010 21:57:29 GMT

snapcrackle wrote:
BTW, Did you notice that they re-wrote many, but not all of the variable names from 12 to 13? Talk about code management issues! It seriously boogles the mind.

I suspect this may have to do with some future functionality (e.g. the hidden "New" and "Demolition" parameters in the AC12 doors).

Re: US Library Door Problem

Anonymous — Thu, 11 Feb 2010 23:24:28 GMT

Thanks guys. I haven't used the standard parts in so long this is the first time I've seen this. Definitely an improvement now that I know.

Re: US Library Door Problem

Laura Yanoviak — Thu, 11 Feb 2010 23:28:51 GMT

snapcrackle wrote:
PS To Laura: instead of rewriting all the doors, just write a new marker style.

Sorry -- doesn't work for me -- in commercial architecture, we follow the National CAD Standard -- the door is identified by the room it secures and the size is scheduled.

Re: US Library Door Problem

Anonymous — Fri, 12 Feb 2010 13:47:27 GMT

Karl wrote:
The scripts are not locked AFAIK - they are just more obtuse than ever before. If you look at the Master Script, you'll see that the D1 Entrance door has this...

When I open the "D1 13.gsm" part (or others) there is nothing visible in either the 2D or 3D script windows. The macros are editable, but as far as I can tell the main parts are no longer open code. Is there something else I am missing here?

Re: US Library Door Problem

Anonymous — Fri, 12 Feb 2010 15:27:23 GMT

Matthew wrote:
Karl wrote:
The scripts are not locked AFAIK - they are just more obtuse than ever before. If you look at the Master Script, you'll see that the D1 Entrance door has this...
When I open the "D1 13.gsm" part (or others) there is nothing visible in either the 2D or 3D script windows. The macros are editable, but as far as I can tell the main parts are no longer open code. Is there something else I am missing here?

The whole object is controlled by the gs_general_door_macro. The other scripts are empty! The only job it does is to specify which gs_doorcode to use.

As an exercise I analysed the one of the simplest windows in the library - W1 Casement 13, and mapped out all the macros that were called from each script and how they interacted with other macros. I counted approx 37 individual macros possibly involved just for a window! It is difficult to give a definitive list as some macros are only called when certain windows are chosen, but it certainly highlights the complexity. It's amazing that there are so few bugs, and it's understandable why they can slip through occasionally.

Re: US Library Door Problem

Laura Yanoviak — Fri, 12 Feb 2010 15:44:47 GMT

Peter wrote:
The whole object is controlled by the gs_general_door_macro. The other scripts are empty! The only job it does is to specify which gs_doorcode to use.

This is similar to what they did with the S/E Markers in AC11 -- the scripts for all Markers are in a single macro. And the gs_general_door_macro came about in AC12.

Re: US Library Door Problem

Karl Ottenstein — Fri, 12 Feb 2010 20:17:03 GMT

Hi Peter,

Very interesting (scary) diagram. The US library uses different macros ... and a different tree. But mind-boggling complexity that makes modification or debugging a challenge I think.

Matthew,

No, nothing is hidden - there is only that call in the Master Script. It is not possible to truly hide GDL code BTW... you can always get to it in one way or another.

Cheers,
Karl

PS After opening macros quite deeply, I went back to the Master Script of gs_general_door_macro_USA which is where each door has its name mapped to an integer code. These integers are then used in all of the other macros to 'do the right thing'. Keeping these 'door type' codes straight seems insane to me ... take a look, or otherwise just imagine the number of IF statements doing different things based on these code numbers. Think of how things would break when a new door is added, or an old one deleted!

gs_door_type = 0
if gs_doorcode = "D1 Entrance"				then gs_door_type = 1
if gs_doorcode = "D1 Entrance Side1"		then gs_door_type = 2
if gs_doorcode = "D1 Entrance Side2"		then gs_door_type = 3
if gs_doorcode = "D1"						then gs_door_type = 4
if gs_doorcode = "D1 Int Door"				then gs_door_type = 5
if gs_doorcode = "D1 Transom"				then gs_door_type = 6
if gs_doorcode = "D1 1Sidelight"			then gs_door_type = 7
if gs_doorcode = "D1 1Sidelight Transom"	then gs_door_type = 8
if gs_doorcode = "D1 2Sidelight"			then gs_door_type = 9
if gs_doorcode = "D1 2Sidelight Transom"	then gs_door_type = 10
if gs_doorcode = "D1 Double Acting"			then gs_door_type = 11
if gs_doorcode = "D1 Int Asymmetric Door"	then gs_door_type = 12
if gs_doorcode = "D2"						then gs_door_type = 13
if gs_doorcode = "D2 Int Doubledoor"		then gs_door_type = 14
if gs_doorcode = "D2 Transom"				then gs_door_type = 15
if gs_doorcode = "D2 1Sidelight"			then gs_door_type = 16
if gs_doorcode = "D2 1Sidelight Transom"	then gs_door_type = 17
if gs_doorcode = "D2 2Sidelight"			then gs_door_type = 18
if gs_doorcode = "D2 2Sidelight Transom"	then gs_door_type = 19
if gs_doorcode = "D2 Double Acting"			then gs_door_type = 20
if gs_doorcode = "D2 Double Egress"			then gs_door_type = 21
if gs_doorcode = "D1 Segmented"				then gs_door_type = 22
if gs_doorcode = "D1 Segmented Transom"		then gs_door_type = 23
if gs_doorcode = "D2 Segmented"				then gs_door_type = 24
if gs_doorcode = "D2 Segmented Transom"		then gs_door_type = 25
if gs_doorcode = "D1 Bifold"				then gs_door_type = 26
if gs_doorcode = "D2 Bifold"				then gs_door_type = 27
if gs_doorcode = "D1 Garage 1"				then gs_door_type = 28
if gs_doorcode = "D1 Garage 2"				then gs_door_type = 29
if gs_doorcode = "D1 Garage 3"				then gs_door_type = 30
if gs_doorcode = "D1 Garage 4"				then gs_door_type = 31
if gs_doorcode = "D1 Segmented Garage 1"	then gs_door_type = 32
if gs_doorcode = "D1 Segmented Garage 2"	then gs_door_type = 33
if gs_doorcode = "D1 Segmented Garage 3"	then gs_door_type = 34
if gs_doorcode = "D2 Sliding"				then gs_door_type = 35
if gs_doorcode = "D3 Sliding 1"				then gs_door_type = 36
if gs_doorcode = "D3 Sliding 2"				then gs_door_type = 37
if gs_doorcode = "D4 Sliding"				then gs_door_type = 38
if gs_doorcode = "D1 Pocket"				then gs_door_type = 39
if gs_doorcode = "D2 Pocket"				then gs_door_type = 40
if gs_doorcode = "D1 Sliding Ext"			then gs_door_type = 41
if gs_doorcode = "D2 Sliding Ext"			then gs_door_type = 42
if gs_doorcode = "D1 Commercial"			then gs_door_type = 43
if gs_doorcode = "D2 Commercial"			then gs_door_type = 44
if gs_doorcode = "D1 Combi Commercial"		then gs_door_type = 45
if gs_doorcode = "D Empty"					then gs_door_type = 46
if gs_doorcode = "D1 Metal"					then gs_door_type = 47
if gs_doorcode = "D2 Metal"					then gs_door_type = 48

Re: US Library Door Problem

Karl Ottenstein — Fri, 12 Feb 2010 20:34:03 GMT

OMG. I just traced one snippet of code and don't think I can bear to look any more.

Inside gs_general_door_macro_USA there is an IF block for segmented garage doors that calls "dp_segm_gar_usa" with the following parameter assignment:

gs_optype_m					= 1*(gs_door_type=34)+10*(gs_door_type=32)+11*(gs_door_type=33)

The gs_opttype_m parameter will either be 1, 10 or 11 because a gs_door_type can only be one of 32, 33 or 34 (type of garage door - see list in PS of last post). So, they are doing this decimal multiplication and complex formula simply to make 33 become 11, 32 become 10 and 34 become 1... An expensive (multiplication) and confusing (by a 1 line formula) way of mapping one set of integers to another.

Then, inside the gs_sgem_gar_usa macro, they have this:

IF gs_optype_m=1 THEN
...
ENDIF
IF gs_optype_m=10 OR gs_optype_m=11 THEN
...
ENDIF

Which is the same as doing the first block for a door_type of 34 and the second for types 32 or 33. Is the mapping confusion necessary? Maybe if some other doors call this macro and the optype (operation type?) code is required for them as well. But, then document it for goodness sake. I should mention that no code - door type, optype - nothing - is ever documented with comment lines in these obscure macros.

This is not code that lends itself to modification and maintenance, especially the addition of new library parts or modification of old ones. It is the antithesis of software as a "kit of reusable parts", much less any object oriented thinking. I'm impressed that people like Laura and Peter have even ventured to modify these things. Good for you two! 🙂

Cheers,
Karl

Re: US Library Door Problem

Anonymous — Fri, 12 Feb 2010 21:59:04 GMT

Karl wrote:
.....I'm impressed that people like Laura and Peter have even ventured to modify these things. Good for you two! 🙂

To be honest, I have never 'successfully' modified any of the doors or windows They are a little beyond my abilities! I can only say I have done a little probing to try to see how they work.

I did manage to get the hidden demolition parameters to semi-work by editing 3 submacros to unlock the necessary parameters. It's difficult to tell if I was completely successful because the feature I guess is still only partially implemented in the script and doesn't seem to work properly yet.

I also found this library developer guide quite useful in helping work out what the different parameters in each macro actually control -

http://www.graphisoft.com/ftp/techsupport/documentation/developer_docs/BasicLibraryDoc/13/

Re: US Library Door Problem

Erich — Sat, 13 Feb 2010 02:13:22 GMT

Peter wrote:
As an exercise I analysed the one of the simplest windows in the library

Quite an impressive diagram Peter. You are a very patient person to have tackled this. I started down that road awhile ago and ultimately decided that it was much easier and more effective to just write my own doors (windows to eventually).

Re: US Library Door Problem

Anonymous — Sat, 13 Feb 2010 07:38:41 GMT

Wow. I didn't expect my little questions to lead to so much interesting discussion. I'm reminded why I gave up modifying the standard parts a long time ago.

Re: US Library Door Problem

Barry Kelly — Mon, 15 Feb 2010 02:14:00 GMT

These library parts are getting so complex and convoluted that it would be impossible for the average (even advanced) user to make any modifications or bug fixes themselves.
Which means anyone using these parts has to rely on GS to modify and bug fix them and hopefully release a library hotfix (that doesn't break something else).
Then how many times have you heard GS say that it will be fixed in the next version - I saw this mentioned just a little while ago though I can't remember what library part it was refering to.
If there is a problem with a library part we need it fixed in this version and now.
Don't wait for a whole library hotfix - just issue the amended part and necessary macros.
Or keep the whole library up to date on a server that can be downloaded at any time.

And with scripts this complex am I crazy in thinking that GS have a much more advanced GDL editing system than they give us in Archicad?
How do they keep track of all the parameters and macro calls and if, when,while, etc. routines?
And all without explanitory comments in the scripts.

There, I've had my Monday morning rant.
I feel much better now - until next time I have to deal with a GS object.

Barry.

Re: US Library Door Problem

Frank Beister — Tue, 07 Sep 2010 07:25:58 GMT

Doors an windows are the king class of GDL programing. MHO.

I have modified a lot of original GS objects. The last window I changed was in ArchiCAD 6.5. The actual versions are really to complex.

Which is the same as doing the first block for a door_type of 34 and the second for types 32 or 33. Is the mapping confusion necessary?

I think much of the confusing code is, that the macros are extended version by version for new functions, but they have to work with older d/w versions because of the migration libraries. I think this is a possible reason for doing remapping of indices. Sometimes its easier to to a remapping instead of crawling through the whole code.

When GS started to standardize the general parameter names (AC 8?) most objects have been adapted by a large mapping table in master script. Quick and ... dirty.

And with scripts this complex am I crazy in thinking that GS have a much more advanced GDL editing system than they give us in Archicad?
How do they keep track of all the parameters and macro calls and if, when,while, etc. routines?

And additional multilingual! Much objects and macros exist in localised versions!

Once I asked GS for a better IDE for GDL development. They told me, that GS develops a new internal system for their standard library development. But nothing for the great unwashed.

How amazing, if it would give a plugin for eclipse or ...