Developer forum
Showing results for 
Search instead for 
Did you mean: 

Exact Copy of AC Library Detail Marker Throws New Errors

James Murray

I am trying to tweak the marker Detail Marker 01 25 in the USA library. This library part has only a Master Script, which contains only a macro call for BaseMarker_macro. All the action takes place in that macro; there are no further calls from any script.


I would think I could save as to create both BaseMarker_macro_JM and Detail Marker 01 JM, and modify the marker object to call my new macro instead.


This done, with precisely zero changes to any script, the new marker starts reporting errors from all scripts:


  • The 2D script has a div0 error.
  • The interface script reports that a parameter name (bVerticalTextPosition) isn't valid. The UI is also missing portions in the settings dialog.
  • The parameter script says that GLOB_SCALE is in use in the parameter script (via the master script). This is certainly true, but the original marker doesn't mind.

To reiterate: This is after a pure save as, no changes except the new macro name in the caller.


What's going on here, what am I missing, how do I fix it? Any help would be appreciated.

James Murray
Rill Architects • macOS •


I am no expert in GDL so sorry if I'm off target here. Have you tried reloading the library?

Archicad 4.55 - 25 | HP Z840 | 2× E5-2643 v4 | 64 GB RAM | Nvidia Quadro M5000 @ Windows 10 Pro x64


James Murray
Rill Architects • macOS •

I don't have 25 but I could test on 24 to see if the same thing happens?

FREE Soffit & Fascia for Rail Tool -
FREE wall Accessory framing and coverings -
FREE Truss object -
FREE Custom Tube Object -
AC 24, Twinmotion current, Windows 11, Msi 10UG with rtx 3070, wacom intuos pro m, Wacom Cintiq Pro 16, razer Tartarus pro.

Barry Kelly

I just tried with that marker from the AUS library.

I assume it is the same (not like doors and windows)


I opened both the detail marker object and the macro.

I 'saved as' and renamed the macro first.

Then I adjusted the 'CALL" in the detail marker object to be the new name of the macro and then I 'saved as' and renamed the detail marker object.


All fine and no error messages when checking scripts.



One of the forum moderators.
Versions 6.5 to 25
Dell XPS- i7-6700 @ 3.4Ghz, 16GB ram, GeForce GTX 960 (2GB), Windows 10
Dell Precision 3510 - i7 6820HQ @ 2.70GHz, 16GB RAM, AMD FirePro W5130M, Windows 10

James Murray

Just tried it in 24, where it worked, and re-tried it in 25, where it worked. 🙄


I also tried the problem marker in a new file, where it failed.


The bad marker is attached if you want to have a look. When I tried to post the macro, I got the interesting result that the CMS rejected it because its type didn't match its extension, which I can assure you is not true. That's why the macro is zipped.

James Murray
Rill Architects • macOS •

Something went wrong with your macro.

It seems to be from an older version?

Somehow you renamed the wrong macro the first time.

That may be why it has the GLOB_SCALE issue and other warnings.


When I compare that one to the 25 one they are definitely different.






One of the forum moderators.
Versions 6.5 to 25
Dell XPS- i7-6700 @ 3.4Ghz, 16GB ram, GeForce GTX 960 (2GB), Windows 10
Dell Precision 3510 - i7 6820HQ @ 2.70GHz, 16GB RAM, AMD FirePro W5130M, Windows 10

James Murray

**beep**. There must have been another BaseMarker_macro loaded and that got opened when I did Open Object from the master script. Thanks for looking into it Barry. Crazy-making.

James Murray
Rill Architects • macOS •

James Murray

Graphisoft has helpfully included an old BaseMarker_macro in the Migration library, specifically the AC22 migration library. That's the file that opens when you select the name text and Open Object, though the macro call itself works fine.


I remain amazed that any of this creaky beep works at all.


Screen Shot 2022-04-06 at 11.20.02 AM.png

James Murray
Rill Architects • macOS •

Interesting find, James! I am not that much amazed tho, and I have a good guess at what happened here. Let me explain:

While the actual CALL in an object is made by the macro's name, something else in the background happens. Archicad wants to be extra sure to call the right macro. So to avoid collisions there is a "secret" library part. One can actually see it when converting a .gsm to the HSF format via the LP_XMLConverter. There will be a bunch of .xml files, one being the "calledmacros.xml" file.

It's content might look like this:

<?xml version="1.0" encoding="UTF-8"?>

A voila! The macro will not be called by the name! This is done only so the user doesn't need to handle the GUIDs themself.

However... now comes the caveat.

Because you used the "mark-name-in-editor-and-hit-open" trick you opened the wrong file unbeknownst to you. In this case Archicad has no other clue, it doesn't actually check the GUID. Probably because this part will only be written on save and this function had to be working before that already. (Works even from the project notes btw!)

Why did Archicad choose the wrong file?

The migration library will be loaded first. Thats why. First come first serves.

This explains also why nobody could replicate your issue.

AC 24 [ger] | Win 10 | Developer of the GDL plugin for Sublime Text |
«Furthermore, I consider that Carth... yearly releases must be destroyed»

As runxel wrote, macro calls are identified by a GUID (well, if they are compiled correctly from source code). Here is some explanation:

Migration libraries need the old versions of a macro, they can't work with the newest if the parameters have changed.

Currently the best way to check which library part is opened is the Open Object button's dropdown list of the "Edit GDL Library Parts" toolbar, it shows the URI of the selected item in the status bar. Sadly it doesn't work correctly in AC24-25, but that will be fixed.

Péter Baksa
Software Engineer, Library as a Platform
Graphisoft SE, Budapest

Still looking?

Browse more topics

Back to forum

See latest solutions

Accepted solutions

Start a new discussion!