Macros: defining parameters from caller objetcts

[Sam Karli]

Hi, I've run into a set of similar problems.

I code a complex railing, that is stretchable and whats components are (banisters, rails) exchangeable. The stuff is made through embedded macros, the the top level object responds for general geometry, while, say, a called banister macro for individual banisters.

The problem is that some banisters have some parameters, others have completely different ones. If a banister is rounded, it has a radius, if it's square, not.

The question is if I can reach the parameters of embedded macros not using the PARAMETERS of CALL (since in this case I have to know what specific parameters use or not use a specific banister).
(For example, giving a set of params).

Other, similar question is if I can somehow reach the hotspots of the embedded object for stretching. Now I can define hotspots in the caller object, that I can stretch, and I can define hotspots in the embedded object that I can only see, not stretch. (Again, caller object doesn't know what to stretch in the embedded object.)

And a third, less similar question, from which the whole stuff originated: When defining custom door/window text, I tried to make the text position stretchable by hotspots, but I couldn't stretch these embedded hotspots, too. In this particular case (placing texts) visual editing would be especially important, and I couldn't do it, although some colleagues said that it's possible.

Not easy questions,
Thanks in advance.

[Erich]

IN answer to you first question, I do not believe that it is possible to affect the parameters of your macro without having those specific parameters listed in your CALL statement. If they are not listed, the CALL will merely bring in the macro object with it's default parameter values meaning that they might as well not be parameters at all.

Since, in your railing object, you have multiple possible parameter sets, I would try to group them into logical sets then access those sets through a set of IF/THEN statements. For instance you could have a call for round balusters and another for rectangular ones. I would compliment this by setting up some hiding or locking of unused parameters so the object remains easily useable.

This will make your railing script a bit more complex but it will also be much more flexible.

In your window issue, it is certainly possible to affect a moveable hotspot in a macro. Just make sure both the macro and the calling object both have a parameter that can be matched. For instance if your macro have a hotspot that moves in the Z directions, say hsZ, then in the calling object have a parameter, say macroZ, that can be matched in the PARAMETER portion of the call statement (i.e. hsZ=macroZ). Make sure that both parameters are of the same type and that neither is locked or otherwise forced to a value or range of values excluded by the other.

HTH