Model View Option alternative for objects.

[Barry Kelly]

Playing with the new LibraryGlobals command in version 13 I discovered what I think would be a very handy use for something like a Model View Option but one that is not saved as an MVO.

Let me explain.

I have an object that the user can add default values to and these values are written to a text file.
It is actually for our Building Code of Australia glazing values for U-value, solar heat gain, shading device height and overhang, etc. for glazed door and window objects.

Our door and window objects then read in these default values from the text file to save the user having to set them up in all of the objects individually.
The values can be over-riden on an object by object basis in need be.
The text file is used to set the defaults rather then set them in the GDL script as they will vary from job to job and this is an easy way to set them all at once.

I use the user interface of the object to input the default data so I thought why not create a LibrayGlobal script that does the same thing.
It all works really well - no need for the external text file any more as all objects can us LIBRARYGLOBAL to enquire these values set in the MVO.

The problem is that these MVO settings are stored in each MVO combination. So they need to be set the same for each MVO combination (not easy to do) or have one particular MVO that must be invoked when we want to calculate the list of data from the windows. If the wrong MVO combination is set then the wrong info will be output.

What I would like to see is a similar system to MVO but for parameter storage.
A bit like a cross between GLOB_USER variables and the project info but on steroids.
We would not be limited to 20 GLOB_USER values and they can be any parameters we want - pen colour, line style, a text or numeric value, etc.

The information could be stored in the job like the MVO info is now but would not be affected when changing MVO combinations - they would stay constant.
So like I say the same as the MVO but exempt from the MVO combinations.

I hope I explained myself well enough.
Just wanted to get this out there.

Barry.

[David Maudlin]

Barry:

I think I understand your need, but I am not sure that the Model View Options is the best place for entering and storing this information, as the Model View Options are tied to views, are intended to change as the views are changed. It seems like the Project Info window would be closer, as this contains information specific to the project that does not change with the view. Have you looked at using this to input and use this type of information?

(I have started to update my objects to use MVOs, and it is a powerful addition to the GDL toolbox.)

David

[Geoff Briggs]

I think you two are actually agreeing, as am I. The new LibraryGlobals is indeed powerful and promising, but storing common parameters is not the best use for it, even though it can be used for that.

It appears Graphisoft themselves fell into this same trap when they moved the door swing and other parameters into the MVO. If they understand that to have been a mistake (big if), then perhaps we all share a common desire to create an improved mechanism to propagate parameter values.

[Barry Kelly]

David wrote:
I think I understand your need, but I am not sure that the Model View Options is the best place for entering and storing this information, as the Model View Options are tied to views, are intended to change as the views are changed.

That is why I want something "like" an MVO but not stored as an MVO combination so it will not be stored in the views.

Maybe GS could have something like "LibraryGlobal" for MVO saved settings and "LibraryLocal" for non-MVO saved settings?

David wrote:
It seems like the Project Info window would be closer, as this contains information specific to the project that does not change with the view. Have you looked at using this to input and use this type of information?

Yes but you can't have the nice graphical interface as in the MVO.

Barry.

[Geoff Briggs]

I’ve been thinking about this a little too since my last post. Doesn’t this fall into the realm of favorites? That’s the existing system of propagating parameter values. But currently favorites affect all the parameters of only one object, whereas Barry’s request (if I read it correctly) is to edit all the instances of one parameter across all objects (or some subset) that share said parameter.

A key question in designing this feature is whether it pushes a value to a parameter that remains accessible within each object, like favorites, or supplants that parameter with a new global setting, like MVOs.

The problem with the AC13 implementation of the LibraryGlobal, as has been discussed at length, is twofold. First, it contains settings that no one changes by view (e.g. door swing pen), forcing users to edit every one of their MVOs to edit them. Second it globalizes settings that users want to vary by instance (e.g. swing line shape), robbing them of that ability. The first is merely inconvenient,. The second a loss of function. So as it stands the current feature is a stark example of what not to do.

[Barry Kelly]

Geoff wrote:
Doesn’t this fall into the realm of favorites?

As you say the favourites are only good for the next object to be placed or you have to manually select all those you want to alter and then ALL parameters will change - not just the one or two you want.
You don't have control over individual parameters.

Thinking about it, setting up a schedule to search for all objects with a particular parameter would allow you to select and alter them.
Just not what I would call a particularly straight forward method though.
And it is getting away from the topic at hand.

Geoff wrote:
The problem with the AC13 implementation of the LibraryGlobal, as has been discussed at length, is twofold. First, it contains settings that no one changes by view (e.g. door swing pen), forcing users to edit every one of their MVOs to edit them.

That's why I would like to see this implemented without having them saved in the MVO combinations.

Geoff wrote:
Second it globalizes settings that users want to vary by instance (e.g. swing line shape), robbing them of that ability. The first is merely inconvenient,. The second a loss of function. So as it stands the current feature is a stark example of what not to do.

This problem is fairly easy to overcome and has been discussed here.

http://archicad-talk.graphisoft.com/viewtopic.php?t=31036

Each object just needs a parameter switch to allow it to use the LibraryGlobal (or LibraryLocal or whatever it may be called) settings or not.

We can then have global settings that can be over-ridden by individual objects and we can also choose to have the parameters saved with the MVO combinations or just as an overall parameter that can be changed at will but stays constant no matter what MVO is used.

Barry.

[David Maudlin]

Barry wrote:

David wrote:
It seems like the Project Info window would be closer, as this contains information specific to the project that does not change with the view. Have you looked at using this to input and use this type of information?

Yes but you can't have the nice graphical interface as in the MVO.

So maybe the solution is to add another panel to the Project Info window that would be driven by the same code as the LIBRARYGLOBAL commands, universally for the project without any ties to the MVOs.

David

[Erika Epstein]

Not a solution but perhaps a workaround. Can you put this info in the favorites prf file?
Export the favorites, open the prf file in a text editor, insert your lines of code and then reimport it into the file?
I'm obviously not a GDL expert, but would this work?

[Geoff Briggs]

Barry wrote:
This problem is fairly easy to overcome and has been discussed here.

http://archicad-talk.graphisoft.com/viewtopic.php?t=31036

Each object just needs a parameter switch to allow it to use the LibraryGlobal (or LibraryLocal or whatever it may be called) settings or not.

I did read that and I appreciate your explanation. I plan to use this for some of my objects. But it is not reasonable to expect users to fix the OOTB doors and windows (especially give the frequency of library updates). That is Graphisoft's job.

We can then have global settings that can be over-ridden by individual objects and we can also choose to have the parameters saved with the MVO combinations or just as an overall parameter that can be changed at will but stays constant no matter what MVO is used.

I like the sounds of that. Incorporating your notion of using schedules, maybe both the MVO and favorite thingy use a criteria picker, like the IS, to add any combination of existing parameters to the control mechanism. Then GS doesn't have use us as guinea pigs to figure out which ones work and which don't.

[Barry Kelly]

Erika wrote:
Not a solution but perhaps a workaround. Can you put this info in the favorites prf file?
Export the favorites, open the prf file in a text editor, insert your lines of code and then reimport it into the file?
I'm obviously not a GDL expert, but would this work?

I think you would need more than just a text editor to understand and edit a PRF file directly.
Plus using favourites you would still need to select all of the object you want to control before activating the favourite.
So I don't think it would work but I like the thinking outside of the box.
Barry.