What triggers a gdl object to redraw itself?

[TB]

I noticed that "Survey Coordinate Object 25" automatically updates the coordinates displayed when the survey coordinates are changed through the "Location Settings..." menu.

I have written objects that display parameter values derived from model information.  However if the model information changes, my object does not know to re-evaluate itself and update its display automatically.   I have to open the object or otherwise touch it in some way before it will update.  So how does the "Survey Coordinate Object 25" know that model information has changed and updates its coordinates automatically?  What triggers it to re-execute its 2d script?

Maybe I shouldn't store the values as object parameters?  Is seems I have a functional deficiency in my approach.  When is the 2d script of an object triggered?  At every redraw, or at a parameter change?

[Piotr Dobrowolski]

You can trigger it... basically if any parameter changes the scripts are redone..

You can use  if glob_modpar_name="yourParameter" and then for sure everything that is between that and endif will be redone on that parameter change

But when You move the object it will not be redrawn...the cache is in action.

There are some object that have to be redrawn by rebuild: regret to say that is stair grid for example...;P

[Peter Baksa]

Not just parameters, global variables and requests also trigger a re-run of the script if their value changes in that context. Quite a few globals are zero in the parameter script, so storing them as parameters is useless.

This example redraws with moving the element or changing the linear dimension settings:

n = REQUEST ("Linear_dimension", "", format_string)
text2 0,0, str{2}(format_string, SYMB_POS_X)

[TB]

But what causes "Survey Coordinate Object 25" to update without the object being touched in some way?   Is it just displaying a global variable that is not evaluated by gdl and therefore a gdl script is never triggered? 

[Kristian Bursell]

The GDL master script and 2D script is triggered when the 2D window rebuilds (zooming/panning), hence the value will update if the value being displayed is set in the master script or 2D script. If you then open the setting and this value is also a parameter then you will see it updated, however this is a bit of a smoke an mirrors scenario because the "parameter" value didn't actually update until you opened the settings.

This is how a lot of zone values and MVO controlled parameters work as they need to respond dynamically.

For example, if I have a parameter called "xOrigin" I want to respond dynamically, then in the master script I declare a "local parameter" called "_xOrigin" and I populate it with the information I require, which can come from a request or global variable as Peter mentioned (there is heaps of info available through these two functions). In the 2D/3D representation of the object I use the "_xOrigin" declared in the master script. I also send this value to the "xOrigin" parameter that I have created, like this:

xOrigin = _xOrigin

parameters xOrigin = xOrigin

This way I can actually use either "xOrigin" or "_xOrigin" in the 2D/3D script and it will update even before the actual parameter in the parameter value list updates.

The fact is, in all my objects the parameter value list is only there for values users want to schedule or actually control through the interface, but the entire object runs on the local parameters declared in the master script denoted by the "_" character (this is a typical coding style).

So to twist it around more; request, global variables and parameters set in the parameter list all control local variables in the master script and its a matter of which was activated most recently takes precedence. So if you change a parameter value it changes the "_" value but if a global variable changes then it changes the "_" value which then changes the parameter value.

its actually super cool as it provides dynamic responses. Unfortunately for me I was a few years down the track in developing my tools before I discovered this so had to go back and set my 2D and 3D scripts to read local values declared in the master script instead of parameter values which need a kick to respond.

[Peter Baksa]

SYMB_POS_FROM_SURVEY_POINT changes when the survey point is moved, and objects which use it are redrawn.