Graphical hotspots, macros & arrays

[Anonymous]

After emailing with Frank Beister, he told me: "This is worse for a thread on the Talk"
So, here is the thread.

I never succeeded to use macros with graphical hotspots into a main object using arrays.
Each time, i have to rewrite the complete list of graphical hotspots into the main object.
Frustrating.

My secret hope was it should be a way to do this, but Frank broke my dreams.
Frank, i am afraid you will have to do the job twice, and to explain why this is not possible.
Thanks anyway.

[Frank Beister]

Here my answer:

Betreff: Re: Hotspots & array
Datum: 17. August 2005 01:51:26 MESZ

Hello Oliver,

interesting situation. First: This can not work. Second. Your
workaround is the way. Why? Not easy to explain. I would prefer german.

If you have still a AC7 or below running, try the following:
Create a new project, place one object and go to File>save_special>plan dump. This will create a text file. open it with an editor (a better one than notepad, e.g. proton ). Search for the object name you have placed. Now you see a raw dump of the data, that is stored of the object in the plan (or database, as you like)-file. No lines, nor 3D-stuff etc. Just the raw values of the parameters from the list. This are the data-fields out of which AC creates (in combination with the script of the bib-element, the GSM) the 2D and 3D shape. And THIS are the values, which are changed, when graphical editing the object. Only this one. None in the GSM or anywhere else. Just the values, stored in the plan-file will be edited.
And be aware: All parameters of the object are stored.
No variables, no graphical stuff, just the parameters. BUT, and that's the point, none of the makros. All values for the right shape of the makro-stuff will be calculated in the main object and will be sent to the makro 'just in time'. Gone after saving and closing the plan. If the values are not given by the main object, AC takes this one for the makro-parameters, which stored in the ISM/GSM (so don't change values of existing makros in the gsm). IF AC should store this values in the database/plan too, it would have to store for as many makro-instances as you are calling in the main object. This would be a job not to be looking ahead. So if you want to change a parameter in the makro graphical, it has no data-field in the plan-database. And so it can't be edited. Clear?

But theres a trick in this circumstances. My object "Bauteilkatalog" (available at Jochens Page b-prisma) is an object, which is labeling standard text for complex components. You can edit the text in makros in a user interfaces and save for each project individual text-makros as ISM/GSM. But how to transfer Text from a makro to its calling main object. To transfer by buffer-statements numerical variables, OK, but text?
The trick: If there's an identical parameter in main object and the makro and you call the makro out of the parameter script and finally use in the
makro the "parameter var=var" statement for this parameter, it will be stored in the main object. You have to try it, its a bit theoretically.

And it's funny. It works principally with your problem too. If you add
a parameter "LEN" to the main object it should show the diamonds and
gives you hope it would work, but you can't move them (see above:
there is only one parameter-data-set of the main object in the plan
and you try to change it 10 times in the makro).

[...] As I said at the beginning: It will not work! 😉 Make the "lenT" editable in the main object.

Frank

[gerd]

I think, the problem is, that the makro is not able to give something (changed parameters) back to the main scipt.
its something like a one way street.

but I hope, someone can give more help, perhaps there is a way to overwit the program ?

[Anonymous]

F. wrote:
As I said at the beginning: It will not work! 😉 Make the "lenT" editable in the main object.

Frank

Thanks, Frank.

I understand why this is not possible.
May be for a next release, why not to dream?

[gerd]

just an idea: perhaps the giving back of values from makros works within the master skript with mixed commands from parameters skript and 2d-skript. (but I think, with hotspots it will not work)
but this will of course not help to make the scripts easier...
best regards

[Oleg]

I am not sure that I understood you exactly.
Download corrected version your test objects. May be it will help you find a way.

[gerd]

hi,

if I understand you right, the problem is not the thing, frank told us, but only a problem of the same uid values used more than once ???
you made sure to get different values by adding 10 befor going in the next loop.

great!
now we only need to find a useful implementation.

best regards, gerd

[Oleg]

gerd wrote:
hi,

if I understand you right, the problem is not the thing, frank told us, but only a problem of the same uid values used more than once ???

best regards, gerd

No. The main point I pass whole lenT array and array index to use.
Macro have to have same array parameter. Frank is right. So main
object keeps the array, when we pass whole array and use this array in the macro the macro will use and change main objects's array.

I think hotspot ids should be unical, so I pass the start Id, but I am not sure the requirement it strict.

[Anonymous]

Oleg wrote:
I am not sure that I understood you exactly.

Hello Oleg,

BRILLANT, as always!

This is exactly, what i need, you understood me perfectly.
In my previous attempts, i did a try by declaring "lenT" as an array in the macro object,
but i did not think to add "lenTidx" param as an index.

This is a very good new. I mean that several hundred lines of script into a main object,
just for 2D/3D hotspots, can be dramatically reduced. Thank you very much.

PS: for gerd, yes the first uid is important, but i don't think this is the main in this case.
May be Oleg can confirm this point.

In another attempt, i declared a "firstUid" param in the macro object (uid = firstUid) ,
and for the main object, in the macro called params, firstUid = k*5.
This did not change anything, because the hotspots did not work anyway, so i deleted this param, to simplify

[Frank Beister]

That's brilliant indeed. Thats the enhanced method I use in my label object.

Fascinating, that the array dimension of lenT, set in the macros parameter list, does not matter if it's called. The lenTidx can become e.g. 4 and the usage of lenTidx[4] would cause outside the makro-context an error. But because obvisiously the definition of lenT in the main object has a higher priority it's allowed.

This is of course a method to check out for its possibilities.

But this works only, see my explanations above, because there is a datafield in which the "graphical editor" can write it's values. It's indispensable to define a parameter for each moveable hotspot. And each instance might not be defined twice as a moveable one.

@Oliver
The objects I sent you Tuesday night didn't work, because there have been defined several moveable hotspots by calling the macro more than once. If you call the macro just one time it works for not-arrays too. See my modified and reduced example attached.