topic Re: Graphical hotspots, macros & arrays in Libraries & objects

Graphical hotspots, macros & arrays

Anonymous — Wed, 17 Aug 2005 11:46:22 GMT

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.

Re: Graphical hotspots, macros & arrays

Frank Beister — Wed, 17 Aug 2005 12:43:21 GMT

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

Re: Graphical hotspots, macros & arrays

gerd — Wed, 17 Aug 2005 12:48:58 GMT

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 ?

Re: Graphical hotspots, macros & arrays

Anonymous — Wed, 17 Aug 2005 13:09:49 GMT

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?

Re: Graphical hotspots, macros & arrays

gerd — Wed, 17 Aug 2005 14:02:08 GMT

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

Re: Graphical hotspots, macros & arrays

Oleg — Thu, 18 Aug 2005 07:03:33 GMT

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

Re: Graphical hotspots, macros & arrays

gerd — Thu, 18 Aug 2005 08:21:26 GMT

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

Re: Graphical hotspots, macros & arrays

Oleg — Thu, 18 Aug 2005 08:37:18 GMT

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.

Re: Graphical hotspots, macros & arrays

Anonymous — Thu, 18 Aug 2005 09:26:16 GMT

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

Re: Graphical hotspots, macros & arrays

Frank Beister — Thu, 18 Aug 2005 11:45:36 GMT

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.

Re: Graphical hotspots, macros & arrays

Oleg — Thu, 18 Aug 2005 13:01:45 GMT

F. wrote:
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.

Yes you can pass array parameter of any dimension to a macro independent macro's default dimension even if 'a caller' object has no such parameter.
It is more general feature out of the subject. IMHO the reason is not a priority but that array parameters are _dynamic_ arrays now.

It is very interesting feature irrespective of macros and hotspots.
We can increase an array size by an object itself ( instead of defining a big oversized array like earlier )

PARAMETERS array_param [idx] = some_value
If idx more than current array dimension it will be increased.

PARAMETERS array_param = other_array
The whole array will assigned. Other_array will not be necessarily parameter or has same size as array_param.

Re: Graphical hotspots, macros & arrays

Anonymous — Thu, 18 Aug 2005 13:18:13 GMT

F. wrote:
@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.

Hi Frank,

I had to rebuild your object (still on 8.1) but hapilly this is fast.
Yes i understand what you mean. It works just for one param once.

As i told you, i get similar results when i call for example, a window panel macro, with a graphical hotspot for angle opening.
The only condition, as you know, is to create the same param into the main object, and then the hotspot works.

The problem was to make it working with arrays, and i really thought it was not possible.
Thank you both for your help.

I will get a try with Oleg's solution, for an existing object, and see what happens.
Even if i have to create some additional params, i think this can save a lot of scripting lines,
and avoid to make the work twice, because my macros already have graphical hotspots.
Unfortunatelly, until now, i had to neutralize this part of script, and rewrite it into the main object. Tedious.

The important point, i think, will be to pay attention to the first uid for each macro. But it should work.
Thanks again.

Re: Graphical hotspots, macros & arrays

Anonymous — Thu, 18 Aug 2005 13:27:48 GMT

Oleg wrote:
Yes you can pass array parameter of any dimension to a macro independent macro's default dimension even if 'a caller' object has no such parameter.
It is more general feature out of the subject. IMHO the reason is not a priority but that array parameters are _dynamic_ arrays now.

It is very interesting feature irrespective of macros and hotspots.
We can increase an array size by an object itself ( instead of defining a big oversized array like earlier )

PARAMETERS array_param [idx] = some_value
If idx more than current array dimension it will be increased.

PARAMETERS array_param = other_array
The whole array will assigned. Other_array will not be necessarily parameter or has same size as array_param.

Hi Oleg,

You should write more often.
If you have other info like this one, please, do not hesitate.
Very interesting.

Re: Graphical hotspots, macros & arrays

Frank Beister — Thu, 18 Aug 2005 14:44:35 GMT

As I have told once (or twice 😉 ) I am not so amazed by the dynamic arrays, because the can cause memory trouble, if the objects are not well written and increase array size too much.

But I can't say, that these dynamic arrays are bringinging some easy programming.

E.g. The REQUEST ("Story_info",... does not need an variable for each story settings you want to request It's just enough to use one dynamic array. All story infos are afterwards stored in the array. I think there are some more examples.

Re: Graphical hotspots, macros & arrays

Anonymous — Mon, 22 Aug 2005 19:29:04 GMT

The funny thing, is that when i read again the documentation (yes i do),
everything is there, but i never understood this part, due to hermetic language for me.

Curiously, just with Oleg's real and short example, all is clear. Despite the barrier of language for both.

I would like more real examples in the documentation, instead of some portions of code, outside of any real context.
That means, beside the pdf documentation, a folder containing hundred of gsm objects, using each GDL tool or feature.

GDL is compact, so these examples (8 or 10 Ko each), should not be a problem for disk space.
Just an idea.