I'm experimenting with some library part scripting, and would like to access the values of a Property (assigned to an instance of an object or door or window) inside the GDL script. I don't know if any of the Request statements can pick up this info.
To be perfectly clear, I'm not talking about properties such as building material, context (coordinate info) or the legacy Properties scripts, I'm referring to the Properties added into ARCHICAD in version 19 or 20, and enhanced with Expressions and Formulas in AC22.
I looked in the GDL Manual but it wasn't clear to me in a 5 minute review of options, so if someone has a clear answer (yes or no) it would save me from having to experiment and test something that may simply not be possible in current versions.
AFAIK - Only GDL Labels can obtain property info from their parent. And there's not much incentive to do that as it is already built in to the autotext part. But you may want to explore a back door?
You can create a C++ Add On which links to the GDL interface ADD ON dll. A GDL IO Example.gdx file is provided in the GDL documentation which does compile cleanly in windows studio 2017 It can them be called from your GDL object with the open command. IOW-- The C Add on fetches the data from the object, makes it available to the GDL interface, and that data is then called from the GDL object.
How this is done is beyond me as there are no examples or documentation- other than the typical "you can do it"
One needs to know how to link in the GDL utility library and how to call their functions- which is beyond me
Perhaps someone from Graphisoft would provide the example?? (Or better yet a video?)
As Gerry wrote, there are the Labels that can read properties. But additionally it is possible with zone stamps as well.
Here is an example that works for both labels and zone stamps, although the GDL manual says, the REQUEST used there only worls for labels (I tested it with zone stamps and it worked). http://gdl.graphisoft.com/tips-and-tricks/display-properties-with-labels
Graphisoft uses other REQUESTs in zone stamps which you can check if you open the actual zone stamps.
"Normal" GDL objects are not able to have access to properties.
Thanks Gerry and Joachim for answering this question so I don't spin my wheels testing things. It's frustrating that this capability (for an object to access Properties of an instance) is only available in Labels and Zones.
The specific application in which this came up was the question of how to represent a Dutch Door, in which the upper part of the door panel can rotate open while the lower part remains closed.
The approach I took was to convert a standard ornamental door leaf into a morph (actually I converted the entire door, then removed the frame) and split it into two parts (upper and lower). I was able to save these parts into two new custom door panel objects, and edit the scripts to remove the automatic resize/stretch. This allowed me to place either panel as a door leaf, without having them resize to fit the opening.
I then inserted lines into the lower custom door panel script to call the upper one (placing it at the right elevation) and rotate it to an arbitrary angle.
I wanted to give the user an option to input the angle in the actual door instance, so I added a new angle parameter into a copy of the original door object. However, I found that the standard Graphisoft door scripting calls a series of macros (about 3 or 4 intermediate ones) before actually calling the door leaf object. To pass along the new angle parameter, I created copies of each of these macros and added the new parameter to each, and edited the CALL parameter to use the new copy of the child macro. It took a while to work out, but it eventually worked.
However, as a practical matter, this is way too much effort. If I could simply add a Property to doors that allowed a user to input a rotation angle, and pull that property in the door leaf script, it would mean that just a few lines of code in the door leaf object would do the trick.
Anyway, it's all a bit frustrating at the moment, however I appreciate the information that each of you shared.
I see what your trying to do now and I have two suggestions. Not sure if you will find them workable, so take them for what they are:
Obviously properties are not available, so why not just add anther parameter in your object which I believe you already have done. Then either add that parameter as a input field in the interface or add the object to a schedule and as a field, (library parameter) and allow the user to edit it in the schedule.
Haven't tried this so I don't know if it would work But offered as a thought?
I appreciate that you're trying to figure out a way to help me out.
I did add another parameter to the object, and was able to add it to the interface (as a quick test I put it into the Description list) so it could be edited for each instance of the door.
However, as I mentioned, the parameter needs to be passed along so the Door Panel can reconfigure, and this is passed through several descendants, so I had to create new versions of each of them, adding the new parameter to each one, so the parameter value could reach the custom panel part. This is technically possible but so unwieldy that I don't want to recommend it to anyone as an "elegant and simple" workaround for creating Dutch Doors.
I think the best workaround for now is to create the custom door panel for the lower section, commenting out the automatic scaling code so it can remain just at half-height, then placing the upper panel section as a free-standing morph or object. This is relatively easy, however it does have one significant drawback: the door panel will not look correct in a schedule preview, so one might have to draw or paste in the upper section onto the layout sheet with the schedule. It's reasonably quick, but still not at all elegant.