Testing for D_​iSlidingType in LibraryGlobals13

[Bruce Walker]

I’m having trouble getting an accurate return value to test the “Line Shape – Sliding Doors” MVO. I’ve used the code:
success = LIBRARYGLOBAL ("LibraryGlobals13", "D_iSlidingType", bOplinesTemp)

Success will return 1, but bOplinesTemp will always be 0, regardless of what the actual value is. This code works fine (using parameter name “D_showBOpLine3D”) for the “Show Opening Lines in 3D Projections,” so I’m not sure what I’m doing wrong.

Attachments:

1. 

   2016-09-12_6-29-46.jpg
   

www.brucepwalker.com
https://www.mindmeister.com/65450406

AC20 6005 AUS Full & AC 21 3009 NZE Full | Win 10 Pro 64 | Intel i7-7700HQ 2.80GHz | 16 Gb RAM
NVIDIA GeForce GTX 1060 8Mb

[Bruce Walker]

This is happening to quite a lot of LIBRARYGLOBAL requests e.g. minimal space (on/off; pen; line type). I have copied the code directly out of the GS door macro to ensure I have it correct…but it still doesn’t work. I cannot figure out why.

Have tested in AC19 and AC20, next to a GS door. The GS door will work, but mine won’t.

Any help would be appreciated.

www.brucepwalker.com
https://www.mindmeister.com/65450406

AC20 6005 AUS Full & AC 21 3009 NZE Full | Win 10 Pro 64 | Intel i7-7700HQ 2.80GHz | 16 Gb RAM
NVIDIA GeForce GTX 1060 8Mb

[Bruce Walker]

Figured it out: for some reason there are two LibraryGlobals13 loaded in the library: one for AC19, the other for AC17.

Still doesn’t answer the question why the GS door worked though.

www.brucepwalker.com
https://www.mindmeister.com/65450406

AC20 6005 AUS Full & AC 21 3009 NZE Full | Win 10 Pro 64 | Intel i7-7700HQ 2.80GHz | 16 Gb RAM
NVIDIA GeForce GTX 1060 8Mb

[Barry Kelly]

Bruce Walker wrote:

Still doesn’t answer the question why the GS door worked though.

I am guessing the GS door knew to use the LibraryGlobals13 file for the 19 library and your doors would have been using the other one.
You will probably see two GDL options in your MVO dialogue.

I know when you CALL a macro by name it actually compiles the GUID into the script (although we only see the name).
Once saved you can rename the call macro file in your operating system and the object will still find the correct macro even though it is calling the old name.

So I am assuming the same is happening with the LIBRARYGLOBAL command – each was linked to the GUID for their respective macro file.
I may be wrong.

Barry.

Versions 6.5 to 22
Dell XPS- i7-6700 @ 3.4Ghz, 16GB ram, GeForce GTX 960 (2GB), Windows 10
Dell Precision M6800 - i7 4700MQ @ 2.40GHz, 16GB RAM, AMD FirePro M6100 (2GB), Windows 7 64bit

[Bruce Walker]

Sounds good. I saw the second MVO tab and removed it from the library – works fine now.

Regarding the GS door – further clarification: it would turn ON the minimal space no trouble, but to turn it back off I had to select a MVO Combination. I couldn’t just open the MVO and turn off the minimal space, as that would have no effect.

So it could be a combination of both GUID, and order of ‘scrolling’ through the LIBRARYGLOBAL calls.

Anyway – lesson is don’t have two LibraryGlobals13 loaded!

www.brucepwalker.com
https://www.mindmeister.com/65450406

AC20 6005 AUS Full & AC 21 3009 NZE Full | Win 10 Pro 64 | Intel i7-7700HQ 2.80GHz | 16 Gb RAM
NVIDIA GeForce GTX 1060 8Mb

[Gergely Fehér]

Hi Guys,

Barry got it right: GDL scripts contains the name of macros, and when you save an object then AC looks for that by it’s name, and saves the macro’s GUID to the caller object. If you have more than one macros loaded with the same name, then the behaviour will be unpredictable: AC will use the first object with the name – and store it’s GUID to the caller. And yes, it can change save by save, depending on million things.

So the proper way of developing any libraries is to do not have duplicate names with libparts/macros loaded together…

Gergely Fehér
Team Leader, Library Team
GRAPHISOFT SE

[Author]

Posts