LIBRARYGLOBAL - mess up

[Nader Belal]

Hi there,

I was trying to work my head with LIBRARYGLOBAL in an object that I´m creating, and although I have followed the required indications by the GDL manual, it fails miserably to update the object's parameter that I have destined for that matter.

My question is, what are the factors that can mess up with the correct functioning (updating) of LIBRARYGLOBAL ?

[Jochen Suehlo]

I had no problems with LIBRARYGLOBAL until now.
What is exactly your problem?
If you want to change the parameters of the object, you
have to use the PARAMETERS command as well.

[Piotr Dobrowolski]

The only problem with LibraryGlobal objects is: overloaded UI page with parameters or UI elements - it slows down the MVO dialog opening. And that is IMHO the only problem.

Piotr

[Ralph Wessel]

The LIBRARYGLOBAL command accesses the Model View Options settings, which are intended to control the rendering or visual appearance of an object. There can be different model view options applied to different views, so you could see the same object multiple times in the same layout with different MVO settings and appearance. On that basis, it wouldn't make any sense to capture these values in a parameter. The value is dynamic depending on the view.

[Nader Belal]

OK, I'm creating an object that must respond to a library global parameter value, apparently I have done it right, but I don't see the result of changing this parameter value in my screen ... funny enough, I have linked that parameter to the object GUI and it works just fine, but then I find out that for that the global parameter to take effect I must first open the object tool tab ... as if it will not refresh the parameter's value unless I open the object GUI.

DR;TL Global Parameter value doesn't refresh until I open the object's tool tab

my question, what are the GDL orders or procedures that prevents the object from refreshing the parameter's value ...

OR

Is there another way to solve that problem ??

@Joachim Suehlo
I know and I have used that (extracted from Master Script)

success = LIBRARYGLOBAL ("library_globals", "library_globals_0011", _param_global_0011)
if success > 0 then parameters	parama_0011 = _param_global_0011

[Ralph Wessel]

Moonlight wrote:
OK, I'm creating an object that must respond to a library global parameter value, apparently I have done it right, but I don't see the result of changing this parameter value in my screen ... funny enough, I have linked that parameter to the object GUI and it works just fine, but then I find out that for that the global parameter to take effect I must first open the object tool tab ... as if it will not refresh the parameter's value unless I open the object GUI.
DR;TL Global Parameter value doesn't refresh until I open the object's tool tab

It doesn't work the way you expect because you shouldn't be doing it – refer to my note above. The GDL Reference Manual also states:

View or project dependent global variables should not be used in parameter scripts (or master scripts run as parameter script)

MVO values are view-dependent, so it makes no sense to capture them in stored parameters. Use the current value for rendering only and discard.

[Pertti Paasky]

You should have the request also in 2d script. If it is only in parameters script, it works only after changing object's parameters.

[Barry Kelly]

Ralph wrote:
The GDL Reference Manual also states:

View or project dependent global variables should not be used in parameter scripts (or master scripts run as parameter script)

MVO values are view-dependent, so it makes no sense to capture them in stored parameters. Use the current value for rendering only and discard.

It all depends on what you are using the value for.
Sure don't use something like plan Level Of Detail or 3D LOD in the master script.

But I am currently creating a Bushfire Attack Level note and lables.
The BAL rating is set in the MVO and I use the library globals in the master script of the object and labels to find the BAL rating and set the parameter in the object.
Then based on that parameter the note or label will change accordingly.
Seems to be working fine for me and as soon as I change the MVO setting, all notes and labels update.

This probably still isn't 100% correct, as I can have different views with different MVO settings, but generally I would never want a different BAL rating - I just have to make sure all MVO schemes have the same BAL rating.
That is why we actually need a true UNIVERSAL GLOBAL variable that is project based and not model view based.
I made a wish for this 9 years ago now.


https://archicad-talk.graphisoft.com/viewtopic.php?t=31427


We did (and still do have) GLOB_USER varaibles, and I used to use these to set global values, but the way these now work was changed (probably around the same time I made that wish).
So we are now stuck with the MVO (Library Globals) method.


Of course when ever using the MVO to set values, always add an override option into the object so you do not have to use the MVO setting - so you can manually change the setting in the object itself as well.

Barry.

[Ralph Wessel · Accepted solution]

Barry wrote:

Ralph wrote:
The GDL Reference Manual also states:

View or project dependent global variables should not be used in parameter scripts (or master scripts run as parameter script)

MVO values are view-dependent, so it makes no sense to capture them in stored parameters. Use the current value for rendering only and discard.

But I am currently creating a Bushfire Attack Level note and lables.
The BAL rating is set in the MVO and I use the library globals in the master script of the object and labels to find the BAL rating and set the parameter in the object.
Then based on that parameter the note or label will change accordingly.
Seems to be working fine for me and as soon as I change the MVO setting, all notes and labels update.
[...]
That is why we actually need a true UNIVERSAL GLOBAL variable that is project based and not model view based.

It's certainly a thorny problem, but I understand GS not wanting to introduce more global variables – they are seen in a similar light to 'goto' in programming circles (some use may be justified, but tread carefully), e.g.: Globals are Evil.

We've seen GS tighten up significantly on the use of globals in recent years, and there are incredibly good reasons for that. It caused a lot of pain for some GDL developers, so I think we should try to steer in a direction that won't repeat that pain, e.g. following GS guidance in the manual.

I suspect that it isn't really working in the case you describe either. If an attached label is using a stored parameter value, then it won't be changed simply by changing an MVO setting. That's because only the rendering scripts will be called in response to that change, and any use of the PARAMETERS command will be disabled. The parameter will only change if the object is edited and the parameter script runs.

Perhaps the labels and/or notes could reference the MVO setting instead so the rendering of object and label are always synchronised.

[Nader Belal]

@Ralph Wessel

That is exactly what I'm trying to do now.

@Barry Kelly
Not because it's running fine in your script means that it's the right thing to do. For instance I´m editing an object based on the previous work of another person, that in that aspect he's just doing that and works perfectly, and in my case it's not working as it should, and I find that quiet frustrating and infuriating.

By the way, in your case you should be using "GLOB_SCRIPT_TYPE" to limit it's use.
Source: Gergely Fehér @ GDL Central - LIBRARYGLOBAL – MESS UP