Return size of macro

[runxel]

Anyone has a nice strategy to get the size of the macro you're calling?
This would be very handy.
E.g. row of chairs where you want to place them in distance.
Returning "A" and "B" doesn't work, sadly.

[Barry Kelly]

I think I know what you mean.
Returning A & B will reset the values of A & B in your calling (parent) object.

Why not add some parameters to the called macro for the chair_row_length = A and chair_row_width = B.
Then return these new parameters and you can use them in the parent object without upsetting the A & B size.

If that is not it then I misunderstand what you want.


Barry.

[runxel]

No no, you're right, Barry.
If all of the content is under your control then this is not an issue. My goal is different tho. I want that the user can use whatever they want, maybe even their own objects.
This means an extra step for the end user and I think there should be some automation for it. Soooo an item for the wishlist...

[Peter Baksa]

So your goal is to use the default sizes defined in the object that the user selects? This sounds dangerous, I wouldn't trust that the defaults don't change. This is outside our mechanism for migrating parameter values.
I doubt it would be impactful enough to rework migration, maybe it's easier to solve your use case with Param-O.

[runxel]

Thanks for chiming in, Peter.

I can't really agree with your statement of it being dangerous, tho.
Well, I certainly can guess why you'd think so.
However this case is a bit different. As I said above and to be clear: I'm currently developing a kind of meta object. Users can feed my object with other objects, most probably with ones they made themself (by just saving them from the floor plan, meaning they are dumb objects and will never change!).
To make matters worse the meta object will call different objects, so one distance won't work for all, it's more complicated than just a simple multiplicating along an axis.
That concludes why I really need to know the bounding box of a called macro, otherwise I don't know where to place the next object.

Param-O won't help at all, by the way.

[Barry Kelly]

runxel wrote:
That concludes why I really need to know the bounding box of a called macro, otherwise I don't know where to place the next object.

I think I get what you are after.
Just as we can CALL an object and send a parameter a new value (CALL object PARAMETERS A=value),
You need to get a returned parameter value but assign it to another parameter in the parent object rather than the original parameter, so you need something like ... CALL object RETURNED parameter_x = A
You don't want the returned value of A to affect the A parameter in your calling object.

And as you are not the user necessarily creating the object being called, you have no control to add a parameter to collect the value you want.

Is that the problem you are facing?

What if in the parent object just before the CALL you save the parent's A value.

A_original = A

Then CALL the object and RETURN A
This will reset the A in the parent object.
Now you can save that value as a new parameter.

new_parameter = A

Then reset the A back to the original value.

A = A_original
PARAMETERS A = A

You should have the 'new_parameter' value that you can use in your calculations.

I think this should work, but I haven't tested.
There may be a better way.


Barry.

[runxel]

Edit: I wrote nonsense here originally.
A corrected version:

What I totally missed:
You can only return values you specified in an "END/EXIT" statement in the macro:

end A, B

And now you can call the macro:

call "my_macro", parameters a_nonsense_param_not_in_use = 0, returned_parameters any, name

Only the order is crucial. You can assign the returned parameters to any values you'd like.

So. to conclude: I have to tell the users, if they use their own objects that they need to open them and paste the end statement from above into their code.

[Anonymous]

Hi folks,
I think I am facing the same issue with this object.
The object calls for another object that is basically a Mesh saved by the user.
Archicad somehow mix the Mesh Hight and elevation into the zzyzx parameter.
The result is that I simply can't get the exact elevation of the called object (which is used for a series of SEO operations).
The only solution I came for now, is to save the Mesh at zero elevation. Which is not acceptable for me.
I tried the RETURNED_PARAMETERS (adding the zzyzx after the END). It works, but it is also not acceptable for a user with no GDL knowledge.
So... As runxel suggested, this one goes to the GDL Wishlist.
I hope I am missing something.

[Peter Baksa]

@Braza: the origin of elements saved as GDL will be the user origin. Just put the origin at the right place before saving with Alt-Shift

@runxel: you can omit a_nonsense_param_not_in_use: call "my_macro" parameters returned_parameters any

[Anonymous]

@runxel: Sorry for hijacking your post.
@Peter:
Thanks for the feedback Peter.
The issue I described only happen if I the mesh is saved from the plan/2d view. Saving from 3d works, but then I loose the 2d hotspots that the user can use to correctly place the object (and will be displayed in my object). I inspected a series of objects (saved meshes with weird combinations of elevations, skirts[Mesh height] and node heights) and the only parameter that can correct the geometry elevation is the zzyzx. Which, if I could retrieve, I could use to correct the elevation of the saved mesh object.