License Delivery maintenance is expected to occur on Saturday, November 30, between 8 AM and 11 AM CET. This may cause a short 3-hours outage in which license-related tasks: license key upload, download, update, SSA validation, access to the license pool and Graphisoft ID authentication may not function properly. We apologize for any inconvenience.
Collaboration with other software
About model and data exchange with 3rd party solutions: Revit, Solibri, dRofus, Bluebeam, structural analysis solutions, and IFC, BCF and DXF/DWG-based exchange, etc.

Opening orientation of double-sided doors

Anonymous
Not applicable
I am sorry, but can anyone recommend me a way for creating door schedule with quantity of Left/Right oriented doors? I want to count the quantities for doors which really have orientation, but double-sided doors are divided by this criteria too ! Can I get overall number only for such non-oriented doors from standard ArchiCAD library (AC 12) without changing GDL code for them?
21 REPLIES 21
Karl Ottenstein
Moderator
Hi Leo,

Really interesting ideas ... but maybe we're not understanding each other on the ID thing - I am not advocating using the ID field for anything but the door/window label which is seen in plan and in schedules and maybe in elevations.

I'm not sure about having each library part optionally read an xml file to update its parameters as a solution to Erika's desire. It could work of course. But, it would be extremely inefficient. The API offers the most reasonable way to do that kind of thing. (But, both techniques would require that the external editor of the xml could not modify the fields that specify the internal parameter names or object GUID, even by accident - otherwise the import could cause some really bad results when the wrong data went to the wrong objects and/or fields!)

I have wished since the ODBC driver was first introduced that it was a two-way linkage, rather than read-only data access - as that would be the ideal way to address Erika's wish: quick, attractive friendly form and report design in Microsoft Access with a live link to the project data. No need for API programming, and really opening up the data side of ArchiCAD.

Cheers,
Karl
One of the forum moderators
AC 28 USA and earlier   •   macOS Sonoma 14.7.1, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Anonymous
Not applicable
Hi Karl,

From my point of view, API is useful for creating commercial products. API have been changing from version to version, so even Cigraph has a lot to do for adopting their products. Besides that, scheduling is a very complex problem. IMHO, it is the main reason why Graphisoft, Cigraph and others aren't success in implementing good scheduling solution for ArchiCAD.

I think that we should to enforce the instruments, which ArchiCAD already has (interactive schedules in this particular case). And GDL-based approach is much more user friendly than API-based. If we have success with some GDL-based solution, other users will have capabilities to modify and adopt it for their specific needs. A good solution should be tiny, easy to create and modify (we have a lot other things to do), and helpful.

Yes, you are absolutely right, such kind of solutions may lack elegance or effectiveness. But we see, Graphisoft has so many problems to solve, what we can't wait for effective solutions. We have to use the program now. Unfortunately, a lot of topics here are about tricky solutions of well known problems.

I am going to explain the library parts driven approach to object placement and schedule creation/modification at my next post.

Cheers,
Leo