Porting legacy Archicad 9 add-on (custom file I/O helpers & .dat configs) to Archicad 29 equivalents

[Steve Sunny]

Hi everyone,

I’m in the process of porting an old Archicad 9 add-on to Archicad 29, and I’m looking for guidance on how to modernize its file-handling layer.

In the legacy codebase, there’s a small utility library (ACFileUtils.cpp/.h) that implements a set of helpers such as:

ArchiCad_fopen(...) ArchiCad_fclose(...) ArchiCad_ReadQuoteString(...) ArchiCad_ReadNumber(...) ArchiCad_ReadToNewLine(...) ArchiCad_GetCommaDelimetedString(...) ArchiCad_getc(...)

These functions were used to read and parse external .dat files (for example TWElementSpecific.dat), which define object-specific settings for the add-on.

From what I can tell, these helpers were custom wrappers around older GSRoot I/O calls (not official Archicad API).
Now that I’m targeting Archicad 29, I’d like to confirm:

1. Are there any current Archicad API equivalents for this low-level file I/O (e.g., ACAPI_File_* or similar)?

2. If not, is the recommended modern approach to use standard C++ file streams (std::ifstream) or the GSRoot IO::File / IO::Location classes?

3. Are there any API restrictions or preferred practices for add-ons reading their own config files at runtime?

4. Is there a newer way to embed or package configuration data (instead of .dat files), such as using .grc resources or add-on preferences?

Any official recommendations, migration examples, or pointers to relevant SDK docs (AC28/29) would be much appreciated.

Thanks in advance for any insights!

[Ralph Wessel]

I can't answer all these questions, but the following might help:

1. I don't know enough about the original functions you're referring to or the content/structure of the files you want to read (e.g. whether the content is formally serialised, e.g. XML, CSV, etc or binary). Certainly the API (and C++) has functions for reading/writing files, but I'm guessing you're after very specific functionality.
2. You can take either approach. Which is easier depends on the context. I personally prefer to use standard C++ or open source libraries where possible because it can also be used outside of Archicad, often has much better documentation, isn't subject to as many changes as the API and dovetails better with other C++ libraries. But you might find it easier to work with the API if Archicad is your only target.
3. Not that I can think of.
4. Configuration files can easily be embedded in the add-on as a 'FILE' resource - but you may already be familiar with that. You can use any file extension or content/structure for this purpose.

Migrating forward 20 versions in one jump is unusual, so I can't offer any specific guidance. The fundamental design of the API is essentially the same, but many functions and data structures have changed a lot over time. Later dev-kits seems to be embracing standard C++ more, so I wouldn't be so concerned about using modern C++ functionality where possible.

[Steve Sunny]

Thanks a lot for your reply — really appreciate it.

Our company used to rely on add-ons quite a bit in the past, but everything stopped working around Archicad 12 or 13. After that, we couldn’t find a developer who understood both Archicad and C++, since most of the old add-ons involved very specific, custom calculations and layer manipulations.

Because of that, they were never ported. Now with AI assistance it’s much easier to work on the migration, but one of the big issues is that only have partial knowledge of the old APIs, and the documentation wasn’t publicly available, so Ai doesn't know much about old Api's. I’ve managed to get about half of the work done, but there’s still a lot left.

As for the external files used — I checked their structure.
The file appears to be REDABLE text in format DAT File (.dat).even though the file has a .dat extension, in this case it’s not a binary file but a plain, human-readable text file.

[Ralph Wessel]

---

@Steve Sunny wrote:

…we couldn’t find a developer who understood both Archicad and C++…

---

Contact me if you want this kind of work done professionally - Central Innovation can provide this service, including consultation, quoting, development and deployment.

[BerndSchwarzenbacher]

Hi Steve,

To add my 2 cents to Ralph's very good answer:

1. & 2. I'm using mostly IO::File/Location functionality and have been happy with it so far.

4. Additionally to embedding into .grc and preferences, there are also Add-On Objects (Reference: https://graphisoft.github.io/archicad-api-devkit/group___add_on_object.html). These are especially helpful if you want the settings to be project dependent and work well together with Teamwork files. (Further references for storing your own data in projects: https://graphisoft.github.io/archicad-api-devkit/_own_data.html)

I'm also available for consultation and contract work for Archicad Add-Ons in case you are looking for more options.

Best,
Bernd

[Steve Sunny]

Thanks