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.
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
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!
Frank
Oleg wrote:Hello Oleg,
I am not sure that I understood you exactly.
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
That's brilliant indeed. Thats the enhanced method I use in my label object.
Fascinating, that the array dimension of
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.
Fascinating, that the array dimension of
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.
