Beware the use of global, it's a "Deprecated Global Variables".
If you use it in v19, Archicad will not benefit of predictive computation.
In v20 GLOB_CONTEXT used in parameters script or master script will have always the value 2.
Bruce wrote: Turns out it only affects the parameter script (as you mentioned). If I move the GLOB query into the Master Script, it should still work.
If you use PARAMETERS command in master script it works as parameters script. It's not written, but I'm quite sure it's so.
The master script to work fine must not have PARAMETERS command.
I'm sure 95 % 😉
Mac Power Book M1 Max 64GB- OS X 12.2.1 - Archicad 25
In version 19 will work, in 20 - no.
Instead of the GLOB_CONTEXT, should be applied GLOB_VIEW_TYPE. Press the Check Script button in v19, and will be generate the warning in the GDL Editor.
All GLOB_ canceled, PEN_OF_RGB, MATERIAL_INFO, TEXTBLOCK_INFO - how many items will have to redo. Not very pleasant innovation in GDL.
I could not agree more with SL_GDL!
To remove context and other globals is insane!
Anyone using context or view dependant code WANTS to have objects change dependant on views!
The line of "in teamwork two people can see the object differently depending on the view" is the whole point!!!!! Not an argument for removing the option!
No sorry my solution doesn't work in 19 - not the initial release anyway.
It is supposed to work when the next hotfix is released to give us time to change our scripts before it stops working again in 20.
But just what can we change our scripts to.
I use GLOB_CONTEXT quite a bit.
This is a classic example of how.
Or in a schedule I use it to control the 2D symbol of an object so it is not rotated/reversed just because the object was placed that way.
Can someone from GS please explain if we can no longer use GLOB_CONTEXT how can we set a parameter based on the context of what is happening to the object at that time?
i.e. how do we get around this particular problem of resetting a Boolean parameter when we are not viewing the object settings dialogue.
This would be greatly appreciated.
I agree with Kistian in that we want objects to change dependent on the views - teamwork or no teamwork.
What is the solution?
One of the forum moderators. Versions 6.5 to 25 Dell XPS- i7-6700 @ 3.4Ghz, 16GB ram, GeForce GTX 960 (2GB), Windows 10 Dell Precision 3510 - i7 6820HQ @ 2.70GHz, 16GB RAM, AMD FirePro W5130M, Windows 10
It is, indeed, a simple but interesting issue.
As far as I can tell, objects will be able to change depending on the views, just coded differently. You will be able to use GLOB_VIEW_TYPE, GLOB_PREVIEW_MODE and GLOB_FEEDBACK_MODE to set how the object looks, but not change its stored parameters just by changing to another view type. So, in this particular case, if the user has set a value for the boolean parameter, the parameter script won't be able to change what the user has set as a stored parameter... or at least this is how I understand the GDL changes document.
I think the part about teamwork is referring to instances where an object might change stored parameters based on a view that another team member is using, something like if I'm looking at an object with 2 pieces set as an integer and a team member reserves that object, opens another type of view and because of that the object changes that parameter to 3, then it is no longer reliable what the two people are looking at. You could still code in that the object should display 3 pieces in that view or 2 in the other, but without changing the original 2 pieces set... something like that.
I can see the use for the example provided in the thread, re-locking a parameter once the dialog box closes; but don't think it will work in future versions.
Of course... I could be ENTIRELY wrong in what I've said until further and deeper information is available.