question

Przemyslaw Pasich avatar image
0 Likes"
Przemyslaw Pasich asked Jordan Johnson commented

Losing createdView reference when model is saved

When a dashboard is opened, its elements (accessed as its subnodes) get a handy reference to their view under the createdView label, e.g.:

Model.find("Tools/Dashboards/1/1>variables/createdView")

The pointer stored there is useful (especially if you don't have an ID assigned to that dashboard element) - it can be used to dynamically edit e.g. the font color as per the comments in:

https://answers.flexsim.com/questions/121047/how-to-change-color-font-of-a-button-in-the-dashbo.html

However, if you save the model, that createdView node gets destroyed, eliminating this handy link, forcing you to either close and re-open the dashboard or search the View tree to get a pointer to that dashboard element's view.

Is there an option of preventing that node from getting deleted on model save? Or maybe an easy way of restoring that node after a model save?

FlexSim 24.0.2
flexscriptsavecreatedview
· 1
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Przemyslaw Pasich avatar image Przemyslaw Pasich commented ·
Worth adding that this behavior might not be intended - in 23.2.3 the createdView node doesn't get destroyed when the model is saved.
0 Likes 0 ·

1 Answer

Logan Gold avatar image
0 Likes"
Logan Gold answered Jordan Johnson commented

Hey @Przemyslaw Pasich, we've been able to replicate the behavior in both 24.0 and 23.2. I have let the developers know so they can help us figure out if this is a bug or expected behavior.

I did notice that in 23.2, opening a model that already contains an open Dashboard will cause the value of createdView to be null, and the value doesn't change to anything meaningful until the Dashboard is closed and opened again. Are you using createdView in a different way, or do you just have to close and reopen the Dashboard each time you open a model in 23.2?

This is understandably better than having to close and reopen the Dashboard after every save, but I'm curious if using the createdView in this way was not intended to begin with. Again, the developers should be able to shed some light on the behavior.

I do know that there are ways to close and open Dashboards with code. So you could do that before trying to access the createdView variable. Or, more specifically, check to see if the createdView node exists before trying to access its value, and then close and reopen the Dashboard if it does not exist. That may not be feasible depending on how many times you want to access createdView, but it should possible.

Otherwise, I'm not aware of another way to create or populate the createdView variable. I'm not sure how it's done normally. We'll see what the developers can find out and tell us.

· 2
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Przemyslaw Pasich avatar image Przemyslaw Pasich commented ·
The context is me trying using a Dashboard as a GUI - more specifically, in function of whether a checkbox is ticked or not, the text in certain edit fields (accessed through createdView) would gray out to suggest they are inactive. The Dashboard has enough elements to make opening/closing it annoyingly slow from UX perspective. However, the intended interaction is that the user - who is not me - opens up the model with this Dashboard already open. And that Dashboard will stay open throughout this use.

So in this particular context, your proposed solution of testing for the existence of createdView and its value and running a dashboard close/reopen code if needed on e.g. model open trigger will work.

I will keep an eye on release notes of future updates; if it turns out to be a bug, I imagine its fix will be mentioned there.


0 Likes 0 ·
Jordan Johnson avatar image Jordan Johnson ♦♦ Przemyslaw Pasich commented ·

The createdView variable is meant for use by the developers of FlexSim to make certain features of the dashboard work. I don't recommend using it in a custom interface, as it was never designed to be used the way you want to use it, and it is entirely possible that we'll change or even remove that node in future versions of the software.

0 Likes 0 ·