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.

[Miha_M]

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

[James Murray]

Yes.

[SenecaDesignLLC]

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

[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.

Barry.

[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.

[Barry Kelly]

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.

Barry.

[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]

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.

[runxel]

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"?>
<CalledMacros>
	<Macro>
		<MName><![CDATA["BasicGeometry"]]></MName>
		<MainGUID>EEDF5B3C-D4C1-40DC-88F8-A8399D8569D5</MainGUID>
	</Macro>
</CalledMacros>

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.