Global User Variables

[DGSketcher]

I am trying to set up a system where a number of different GDL objects can access common values. These values need to be accessible for updating with all the connected objects following the changes. I have a set up using MVO and the objects pulling values with the LibraryGlobal command. This is working great, until I change to a different MVO setting at which point all the values revert to their default / last changed values for that MVO. This can destroy my drawings (not literally), until all the variables are updated. Is there a practical alternative or some way of feeding back values so that all MVO selections use the same values? 

[Kristian Bursell]

Do you mean they are not updating automatically to the chosen MVO settings when you change to a different MVO? If so it may be because you are sending the MVO setting to a parameter and you have to wait for this parameter to refresh (the parameter script of the element to run). The trick is to send it to a local variable in the master script and use this value instead of the parameter value, or name it the same as the parameter.

I have described this in a couple other post; just say the parameter name is "bClearance" and you call it from the MVO using the "success" method as "mvo_bClearance". in your master script, after the MVO call put:

bClearance = mvo_bClearance

parameters bClearance = bClearance

This will result in the 2D and 3D script automatically responding the the MVO change without the need to run the parameter script.

[DGSketcher]

@Kristian Bursell Thank you for the response. My problem is the MVO is working as it should. What I need is a way to set a parameter in my Library Global Setting Object in the MVO say "Width" and make that value the same in all the other existing MVO settings and any new MVO settings. I can't justify external file I/O (too slow) to save the values, but I would like to set "Width" to a system wide value easily from a single location.  Before being deprecated I think the solution would have been GLOB_USER_1. Maybe my approach is wrong?

[Barry Kelly]

In my opinion, the old GLOB_USER_?? variables used to work perfectly.

I think they still do work, but the problem is (from memory) that they can no longer be set from an object, they must be initially set in a MASTER_GDL object.

I still think we need a UNIVERSAL_GLOBAL that can be set at any time like you would in the MVO values, but it is not actually part of a particular MVO combination.

Therefore it will not change as you swap MVO combinations.

Barry.

[DGSketcher]

Thanks Barry, not just me seeing an issue here. I have tried to get my head around  "Master_GDL" but the information / tutorials seem in short supply. Being able to assign a PLN file specific editable variable and have it cascade into the objects seems like a useful thing to have.

[runxel]

The easiest way to implement this descendent to GLOB_USER_XX in my eyes is the following strategy (GS, please take notes):

• Having a a new button in the GDL editor (like the "U")
• If this button is pressed the value will be automatically added to a list of truly UNIVERSAL GDL parameters
• There will be a new interface dialog like the "project info" dialog

In this list all of those global GDL parameters are collected and can be set.

This value will go on to propagate into all placed objects with this certain parameter.

Of course there needs to be some kind of override (think of the "chain link" symbol already present in the properties UI), because some outliers always need to be special and different from the rest.

In the end, everything is already somehow there, GS would just need to assemble it.

Please make it happen!

[DGSketcher]

Perhaps something as simple as a flag in the Library Global Object that controls whether to set each parameter in the MVO to a single value or changeable for each MVO setting would be easy to manage. Something along the lines of the "Placeable" switch e.g. "Parameters are global ✅" ? 

[Kristian Bursell]

Sounds very interesting and quite powerful.

Objects are instance based but then become type based through MVO' s and now this theory asks for MVO's to have another higher level of control, effectively creating a project based control.

I like it.

I use the XML i/o for this same effect but that's at a far more detailed level (involving multiple specific parameters and arrays) for locking things to a favorites type function and its very object specific and complex. However, I can definitely appreciate the desire for similar quality control at a global parameter level.

I am thinking perhaps the XML i/o could be incorporated to work with MVO's to achieve this control but the interaction would be too clumsy unless it was an API. Hence I think this topic should be moved to the wishes forum as it definitely has a lot of merit and I don't believe it can be handled just with GDL unless you go down the same complex path I have with my XML catalogue functions, which is not a part of MVO's.

[DGSketcher]

@Kristian Bursell 

---

Objects are instance based but then become type based through MVO' s and now this theory asks for MVO's to have another higher level of control, effectively creating a project based control.

---

Nice summary. I assume your XML programming is system based control rather than project?

[Kristian Bursell]

Yes it is system based. However, it does include a process to allow project based and even a combination of project and system based.

XML catalogues are stored externally (company server) and the user can create as many varied catalogues as they choose, hence they generally have an office wide catalogue next to project specific catalogues.

The more advanced teams even break it down into project stage catalogues starting with basic simplified configurations and evolving through the project to more detailed and specific configurations.