topic Re: Sensing the MVO change in GDL

Sensing the MVO change

Piotr Dobrowolski — Wed, 01 Dec 2021 19:40:50 GMT

Hi,

Have anyone found a way to sense in the object that the MVO changed?

looking for request like thing...because the change of parameter by LIBRARYGLOBAL does not produce any trigger to GLOB_MODPAR_NAME.

Piotr

Re: Sensing the MVO change

Lukas Oelmueller — Thu, 02 Dec 2021 09:16:46 GMT

Example

success = LIBRARYGLOBAL ("LibraryGlobals13", "W_opLinePen", W_opLinePen)

pen W_opLinePen

Re: Sensing the MVO change

Piotr Dobrowolski — Thu, 02 Dec 2021 09:20:54 GMT

OK, a little misunderstanding.

I want something else could sense MVO change. I have a database (csv) hooked up with some data. I made some GLOB_MODPAR_NAME's that trigger the database reload. MVO change, even if the parameter that comes from LIBRARYGLOBAL changed do not trigger the reload.

Piotr

Re: Sensing the MVO change

Lukas Oelmueller — Thu, 02 Dec 2021 09:32:07 GMT

oh...not so sure if I can help...

Have you tried placing a dummy object to "trigger" with the same code of the GLOB_MODPAR_NAME?

Re: Sensing the MVO change

DGSketcher — Thu, 02 Dec 2021 16:35:15 GMT

@Piotr Dobrowolski Are looking for an MVO change trigger? I place the following code in the Master Script of my GDL objects and get consistent change response across all placed objects.

It doesn't seem to work in other scripts. If your object Master Script detected a changed state for Param1 e.g. Param1 <> Param2 then you could possibly use that to trigger a reload?

chk = LIBRARYGLOBAL ("My_MVO_Macro", "My_MVO_Param1", _reqParam1) Param1 = _reqParam1 PARAMETERS Param1 = Param1

If anyone else is looking for guidance on linking to MVO settings this link may help...

http://gdl.graphisoft.com/tips-and-tricks/custom-made-model-view-options-object

Re: Sensing the MVO change

Piotr Dobrowolski — Thu, 02 Dec 2021 16:50:47 GMT

I do have such thing, but I have it a little different:

chk = LIBRARYGLOBAL ("My_MVO_Macro", "My_MVO_Param1", Param1) PARAMETERS Param1 = Param1

And it does not work...GLOB_MODPAR_NAME does not trigger...

I tested with the parameter equaling...and it does not change anything

maybe it is because I load the database in the parameter script...I will investigate further.

Piotr

Re: Sensing the MVO change

Pertti Paasky — Mon, 06 Dec 2021 20:08:58 GMT

https://gdl.graphisoft.com/forums/topic/libraryglobal-mess-up

This tread gives me an impression, that the Libraryglobal works in 2d and 3d only.

Re: Sensing the MVO change

Piotr Dobrowolski — Tue, 07 Dec 2021 05:47:18 GMT

Not only - I successfully use it for exchanging the translation strings, and passing some region specific data... The only drawback is limited no of entries and the problem in this tread 😉

(You can see how it works in Velux library BO will have latest ver. soon)

Re: Sensing the MVO change

Pertti Paasky — Tue, 07 Dec 2021 07:06:11 GMT

Ok.

I have used another method to find out the last modified parameter: I create a "shadow" parameter like Param_a_ for Param_a. When Param_a is changed, then there is a

difference between Param_a and Param_a_.

Parameter script:

modparname=""

If Param_a#Param_a_ then modparname="Param_a"

parameters modparname=modparname, Param_a_=Param_a

endif

I have not tried this method in Your case but this problem is interesting.

Re: Sensing the MVO change

Piotr Dobrowolski — Tue, 07 Dec 2021 08:52:01 GMT

I Will try it... Implementation of more and more database features becomes more and more complicated 😉 (database csv is ~60x~7000 cels and keeps growing ;P)

Re: Sensing the MVO change

Peter Baksa — Mon, 13 Dec 2021 17:03:23 GMT

From the manual: Visible placed objects whose 2d or 3d scripts contain LIBRARYGLOBAL commands are refreshed when the library global object’s parameters change at Model View Options. Parameter and migration scripts should not use LIBRARYGLOBAL values, the current view should not have any effect on other views.

Also parameters of an object are directly accessible for listing, so they mustn't depend on the current MVO.

You should be able to read the same data from 2d and 3d scripts.

Re: Sensing the MVO change

Pertti Paasky — Sun, 19 Dec 2021 16:17:20 GMT

Found in GDL manual AC24, maybe they give some idea.

page 261: In addition, the global string variable GLOB_MODPAR_NAME contains the name of the last user-modified parameter. -does this cover the program-modified parameters too?

page 298: • LIBRARYGLOBAL requests cannot return dictionary type values.

page 560: When resetting the value of a parameter in a certain condition in the Parameter Script using the parameters command, a similar statement must be put into the Master Script. This keeps the object's display correct in cases when the parameter script is not run by the system. E.g.:

! parameter script if bCondition then yy = 1 parameters yy = yy endif ! master script if bCondition then yy = 1

Re: Sensing the MVO change

Piotr Dobrowolski — Mon, 20 Dec 2021 19:45:31 GMT

I have to completly rebuild the triggering system... glob_modpar_name...fails in some situations...some user changing parameters trigger database reload...while others do not...restart of playing detective 😜

Re: Sensing the MVO change

Piotr Dobrowolski — Mon, 12 Sep 2022 08:22:41 GMT

Haha...

It took me quite a time to test this ideas (until my data import caused some errors due to the textual parameters...and caused me treating the database in powershell first to get a numerical chart)

Anyway it works, however it has to be done in a correct order.

(all in parameter script)

1. compare the library global loaded parameter with the local

2. if they do not match trigger the update and all needed code

3. use parameters command to update the parameters that came from library global

and the point 2 was partly a success...because this part must be in the beginning and some values are not calculated yet...anyways I managed to do a dummy update which then was compared and triggered the final one.

Anyway LibraryGlobal can trigger some data reload inside the treated object