topic Re: Scope of HOTSPOT2 identifiers in a macro object? in Libraries & objects

Scope of HOTSPOT2 identifiers in a macro object?

Anonymous — Wed, 06 Jan 2010 23:11:52 GMT

I was tinkering with hotspot-based editing commands and I ran into an annoying problem. I have a 2D script and I want to be able to call the same macro several times based on parameters of the object calling the macro. The macro defines and places the hotspots since the geometry to manipulated is created in the macro.

The problem is that if I call the macro more than once I get an error when trying to place the object saying that the hotspot identifies are no longer unique? I assumed the scope of the identifier would be localized to the macro object, not the calling object but this seems to be false?

If for whatever reason this is actually functioning as intended is their any way I can get around this limitation without creating a parameter and passing it when I call the macro? Ideally the macro would keep track of the identification assignments internally rather than having the calling object track the identifiers - can this be done?

Thanks in advance.

Re: Scope of HOTSPOT2 identifiers in a macro object?

David Larrew — Thu, 07 Jan 2010 02:11:31 GMT

I had that problem with some of my Macro Objects that were upgraded to utilize the graphical editing Hotspots when the option was introduced. You need to hard-code a start uiID# in the receiving Object (that is calling the Macro) to reset the ID count for each instance the Macro is called. Then create a parameter in the Macro Object to receive the assigned uiID#. This way the Macro just loops the ID #s within itself without errors while being called multiple times in the receiving Object.

Re: Scope of HOTSPOT2 identifiers in a macro object?

Barry Kelly — Thu, 07 Jan 2010 02:41:57 GMT

I am tackling a similar problem at the moment.

When you call your macro you need to pass on a parameter like HSID_add = 1000.

Then in your macro you obviously need a parameter for HSID_add.
All of the hotspots in the macro need to have this value added to the unique ID.
HOTSPOT2, 0, 0, UNID + HSID_add
UNID = UNID + 1

The next time you call the macro (from the same object) you must increase the HSID_add value.
CALL "macro" PARAMETERS HSID_add = 2000.
CALL "macro" PARAMETERS HSID_add = 3000.

You can still use UNID and increase it by 1 after every hotspot but this can cause problems if you want to attach dimension to your objects.
Especially when they have IF > THEN statements with hotspots in them.
Then the ID numbers change and the dimension jump to the different points in plan.

It is best to use fixed ID's instead of UNID = UNID + 1.
HOTSPOT2, 0, 0, 1+ HSID_add
HOTSPOT2, 0, 0, 2+ HSID_add

You just have to be careful and keep track of what UNID numbers have been used.

This all seems to work fine where you only have one level of macro calls.
i.e. object_1 calls macro_1

But starts getting messy when your macros start calling other macros.
object_1 calls macro_1 and macro_1 calls macro_2
Then later object_1 calls macro_1 again.
You need to know exactly what is calling what so you can set the HSID_add value appropriately or as I am trying at the moment parsing a parameter macro_level = macro_level + 1 and multiplying the HSID_add variable by (10^macro_level).

This will create unique ID numbers completely clear of any others as they will be increased by a factor of 10 at each macro level.
So long as it ID's are unique it doesn't seem to matter what the size of the number is.

The trick is getting them to be unique for all instances.

Sorry if I complicated the issue at all but the first part of my post will solve your problem.

As far as I know duplicate or changing ID's are only a problem when you want to dimension the object.
I noticed this with the new automatic annotation for doors and windows in the interactive schedules in version 13.
Graphisoft recommend unique and fixed ID's.

Barry.