topic Re: Palette resource id should be unique, even in another addon it cannot be the same in Archicad C++ API

Palette resource id should be unique, even in another addon it cannot be the same

eptar — Wed, 13 May 2026 21:08:13 GMT

We have 2 addons using the same palette logic, so the good old copy and paste method helped us to create the palette in our new application. We used the same grc, changed the addonid, also created a new guid for the palette of our new addon so we can register a callback. During development there was no issue, since only one addon was loaded.

If just one of the addons is loaded, then addon A opens palette A, if only addon B is loaded, then it opens palette B.

When both addons are loaded when I try to open the palette from addon B, the palette of addon A is opened. Addon A works the same way, it also opens palette A. If I change the resource id of the palette in one of the addons it starts to work as it is expected so addon A opens palette A, addon B opens palette B. As far as I know the resources are addon specific, we can use the same ids in different addons.

I am not sure if this is dev id specific, or global issue, so only a developer cannot use the same resource id for a palette in multiple addons, or none of the developers can use the same resource id for a palette to avoid such a racing condition. Currently we just tested it on windows, version 27 and 29, but this seems to be a general issue at least on windows.

Operating system used: Windows 11 25H2

Re: Palette resource id should be unique, even in another addon it cannot be the same

Ralph Wessel — Thu, 14 May 2026 09:56:36 GMT

I don't know whats causing this problem, but it's not the fact that the palettes share the same resource ID. We have numerous add-ons with a palette sharing the same resource ID and haven't seen any problems (on Mac and Win)

Re: Palette resource id should be unique, even in another addon it cannot be the same

eptar — Thu, 14 May 2026 15:27:42 GMT

But you also use the callbacks for reopening the palette after restarting Archicad and such? So not just the regular callback for button clicks, but the one like this:

PaletteAPIControlCallBack(Int32 referenceID, API_PaletteMessageID messageID, GS::IntPtr param)

If we do not have these kind of functions in place, everything seems to work perfectly. Then if I have an open palette command it opens the right palette.

Actually it is not super important in our current project, but still it would be nice to know what the problem is.

In both addon in the callback mentioned above I write into the session report the ref id and the guid just in case:

if (referenceID == Palette::RefId ()) { ACAPI_WriteReport(...) }

In the session report I clearly see after clicking on the open palette command in one plugin, that both callbacks were executed, and both bypassed the condition. The output is different, I see addon1, refId1, and guid1 in one case, and addon2, refId2 and guid2 in the other line.

What I can state for sure:

- we use the same developer id in both addons

- we use different addonid (obviously)

- we use the same resource id in both addons for the palette dialog

- we use the same resource id for a very simple menu (basically open palette, and show manual kind of complexity)

- we use different guids for the dialogs

- we use different class names, which are in different namespaces regarding the palettes

- if I change the resource id only, everything seems to work perfectly.

My feeling is that somehow this is related to the resource id and the PaletteAPIControlCallBack function.

Re: Palette resource id should be unique, even in another addon it cannot be the same

BerndSchwarzenbacher — Thu, 14 May 2026 16:53:59 GMT

Very curious behavior.
I've tried the following:

Copy one of my Add-Ons "Room Coverings" with a palette and named it "test"
Change the Add-On ID of the "test" project (and menu item strings so I can distinguish them).
But I left everything else (developer id, resource ids, even same palette GUIDs) the same
Load both the "Room Coverings" and "test" Add-On
Open/close palettes for each Add-On. Trying different orders of opening & closing.

Everything works as it should. The menu item for the "Room Coverings" Add-On only opens its palette and the menu item of the "test" Add-On opens only it's own palette too. Tested on AC29 Windows.
So I wasn't able to reproduce your issue with my setup.
Can you show us the relevant parts on how you register the palette and how your PaletteAPIControlCallBack function looks like?

Maybe even reduce your problem to a minimal case (palette code only) for us to try to reproduce it with your code.

Best,
Bernd

Re: Palette resource id should be unique, even in another addon it cannot be the same

Ralph Wessel — Fri, 15 May 2026 08:26:58 GMT

@eptar wrote:

But you also use the callbacks for reopening the palette after restarting Archicad and such? So not just the regular callback for button clicks, but the one like this:
PaletteAPIControlCallBack(Int32 referenceID, API_PaletteMessageID messageID, GS::IntPtr param)

No, we don't use any callbacks like that. In what context is that being used?

Re: Palette resource id should be unique, even in another addon it cannot be the same

eptar — Fri, 15 May 2026 08:58:28 GMT

I'll going to do some scenarios over the weekend, maybe it is about mixing the c++ and c style concept a bit. I'll check what if I implement things clearly c++ style, compared to the current solution, cutting back the code basically to have only a button on the palette with a WriteReport, and deleting everything else physically from the code. I just do not like the way how events are implemented in the c++ approach in the GS samples. We used the OwnerDrawnListBoxPalette to take some ideas from the examples in the devkit if I remember well, and adjusted that to our needs, ending up with something which is a little bit closer to the c# style of dialog handling. I'll check if I can implement our flow clearly with the c++ style and eliminate the DG functions completely. The PaletteAPIControlCallBack is actually the same like in the OwnerDrawnListBoxPalette sample, in some of the cases an extra invalidation logic is added because a disable all / enable all thing is not enough for us.

Re: Palette resource id should be unique, even in another addon it cannot be the same

eptar — Fri, 15 May 2026 09:16:00 GMT

This kind of callback (from GS examples):

GSErrCode __ACENV_CALL OwnerDrawnListBoxPalette::PaletteAPIControlCallBack (Int32 referenceID, API_PaletteMessageID messageID, GS::IntPtr param) { static bool paletteOpenAtClose = false; GSErrCode err = NoError; if (referenceID == OwnerDrawnListBoxPalette::ODLBPaletteRefId ()) { OwnerDrawnListBoxPalette& palette = OwnerDrawnListBoxPalette::GetInstance(); switch (messageID) { case APIPalMsg_ClosePalette: case APIPalMsg_HidePalette_Begin: if (palette.IsVisible()) { paletteOpenAtClose = true; palette.Hide(); } else { paletteOpenAtClose = false; } break; case APIPalMsg_OpenPalette: paletteOpenAtClose = true; // no break case APIPalMsg_HidePalette_End: if (paletteOpenAtClose && !palette.IsVisible()) { palette.Show (); } break; case APIPalMsg_DisableItems_Begin: palette.DisableItems(); break; case APIPalMsg_DisableItems_End: palette.EnableItems(); break; case APIPalMsg_IsPaletteVisible: (*reinterpret_cast<bool*> (param)) = palette.IsVisible(); break; default: break; } } return err; }

This you can register in the regular initialize function using this API call:

__APIEXPORT GSErrCode ACAPI_RegisterModelessWindow (Int32 referenceID, APIPaletteControlCallBackProc *callBackProc, GSFlags controlFlags, const API_Guid& paletteGuid = APINULLGuid);

So this callback is not the regular onclick kind of callback. It can be used for a couple of things, eg. opening the palette by default when Archicad starts if the palette was opened when Archicad was closed before, otherwise just keeping it closed until the user wants to open it. It is not necessarily an essential thing to do, but it is nice to have.

Re: Palette resource id should be unique, even in another addon it cannot be the same

Ralph Wessel — Fri, 15 May 2026 11:20:31 GMT

@eptar wrote:

This you can register in the regular initialize function using this API call:
__APIEXPORT GSErrCode ACAPI_RegisterModelessWindow (Int32 referenceID, APIPaletteControlCallBackProc *callBackProc, GSFlags controlFlags, const API_Guid& paletteGuid = APINULLGuid);

Have you tried using a different ID to register the palette, i.e. some other unique identifier instead of the resource ID?

Re: Palette resource id should be unique, even in another addon it cannot be the same

eptar — Fri, 15 May 2026 12:16:33 GMT

I used the same approach like mentioned above, so I have such a function:

OwnerDrawnListBoxPalette::ODLBPaletteRefId ()

I took the implementation from the sample, it calculates a hash based on the guid, and it is different in the different addons. I call that function to get the reference id.

ACAPI_RegisterModelessWindow(Palette::PaletteRefId(), Palette::PaletteAPIControlCallBack, API_PalEnabled_FloorPlan + API_PalEnabled_Section + API_PalEnabled_Elevation + API_PalEnabled_InteriorElevation + API_PalEnabled_Detail + API_PalEnabled_3D + API_PalEnabled_Worksheet, GSGuid2APIGuid(Palette::PaletteGuid()));

But as I wrote I'll do some further experiment tomorrow or Sunday, I just wondered if anyone else experienced such a thing before. Especially, because if it is a global issue somehow, then it is one thing I can take care of my resource ids, but I do not have control over others.

Probably I will start from one of the GS examples to see if I can reproduce the issue with their approach with the pure c++ classes.

Re: Palette resource id should be unique, even in another addon it cannot be the same

BerndSchwarzenbacher — Fri, 15 May 2026 12:42:25 GMT

Thanks for sharing the relevant code bits. My code looks very similar and I think I also started out from the OwnerDrawnListBoxPalette example. But that was a few years ago 😅

Looking forward to see what your experiments bring up!