Communicating with an external program.

[MADheikki]

I need an external stand-alone program to be able to communicate with Archicad, specifically to get information about walls and slabs, and send back data to create materials with.

Currently I have written an add-on that packs the necessary data into an .xml that the standalone can read, and the standalone creates material attributes as an .xml that Archicad can read. This works, but is horribly tedious to the user, who should be ideally able to click a button in the standalone to perform these actions automatically.

I've tried to make a named pipe connection, but I'm presented with 2 bad options: either the process runs on the AC main thread and blocks user interaction, or runs on the background in a separate thread, but cannot access the element database because AC hasn't been built with multi-threading in mind.

So, what to do? I know Grasshopper manages to do this somehow, but don't have a clue how. Implementing the whole standalone program as an Archicad add-on isn't viable: it would require rewriting the whole program in C++, and the user interface itself is rather complicated.

- Heikki Malkki / M.A.D.

[Joe Putnam]

I absolutely love these kinds of tools for this kind of thing but a Remote Procedure Call in general is what I prefer. XML, json etc are in my opinion garbage unless you need this to work over http and even then personally I would use this.

https://grpc.io/

https://thrift.apache.org/

I think you could also use web-sockets and find the right library for your particular language case.

Joel

[leilei · Accepted solution]

Hi,
You can see this function with no crash in multi-threading: ACAPI_Command_CallFromEventLoop.
You can omit this function if you don't need to operate the AC database.

[MADheikki]

Thanks, ACAPI_Command_CallFromEventLoop did the trick. I made a thread that creates a pipe and listens for connections, and when connected, uses ACAPI_Command_CallFromEventLoop to call a function that returns element data.

XML might be garbage, but since I've already got it for file-based transfers and have C++ on the one end and C# on the other, anything more sophisticated at this point would be wasted effort. "It does the job."

[gavinNZz]

Hi,

Just a question..... Would this functionality you talk of work in the case of a live connection with the parameters of a selected object? I struggle with the limited scope of the default UI in the selection setting dialog box. I would love to have an external program running that could read & write into the parameters of a GDL object. The UI layout could then be whatever you wanted it to be. I'm not concerned about archicads base elements (walls/roofs etc) but rather the presentation and adjustments of parameters within custom GDL objects. Thanks

[Ralph Wessel]

gavinNZz wrote:
Would this functionality you talk of work in the case of a live connection with the parameters of a selected object?

Could you clarify the context in which you would like to modify parameters, i.e. broadly the application within a specific workflow? That function will be applicable to many workflows, but not all.

[gavinNZz]

Ralph wrote:

gavinNZz wrote:
Would this functionality you talk of work in the case of a live connection with the parameters of a selected object?

Could you clarify the context in which you would like to modify parameters, i.e. broadly the application within a specific workflow? That function will be applicable to many workflows, but not all.

Basically when a custom object is selected at any point in a workflow it would, through an AC add-on, expose its parameters to a xml file which would be read and written to by the external software which in turn would feed updated parameters back into the XML and, through the AC add-on, the object would be updated.

Grasshopper achieves this functionality but uses it more to create/edit elements within archicad as opposed to just being a parameter control mechanism.

As with the grasshopper connection there would need to be a parameter that notifies the external software that it is required and what it is looking at. This would allow the external software to supply a specific UI for the selected object.

I struggle to understand how in 2019 we are still restricted to the tiny UI in the archicad selection setting dialog box. It is not conducive to supplying a good user experience especially given the complexities of some of the objects we are now using in our BIM models.

Thanks

[Ralph Wessel]

Yes, that should work. Use this in conjunction with notifications from ARCHICAD of a selection change (and possibly editing if relevant).

[gavinNZz]

Ralph wrote:
Yes, that should work. Use this in conjunction with notifications from ARCHICAD of a selection change (and possibly editing if relevant).

Thanks Ralph, good to know, just have to learn C++ now......ummmmm.....might be sometime!

[Ralph Wessel]

Modern C++ doesn't need to be harder than any other current language, but the potentially for complexity is there if you really need it. The biggest obstacle will be some parts of the API, because they demand a strong understanding of manual memory management and access. This is purely historical, based on the early underpinnings of ARCHICAD, and GS is slowly but steadily working on improvements.

But if your task isn't demanding, the new Python API might be an easier option.