[Feedback] NEW Perspective Dashboard

**mitchell-ACS** · October 8, 2019, 7:57pm

Must have been a cacheing issue because I cannot replicate what I saw myself! thanks for the quick response @ynejati

**rcrownover** · October 9, 2019, 9:52pm

The “style” property (which is valid and can be added manually) does not appear by default in the PROPS sections. I would request that it be added for clarity (and so the shortcut style class chooser icon can be there).

Super awesome! Literally just started building something that would do this. So excited to see it as a standard component.

**ynejati** · October 28, 2019, 2:32pm

You are completely right. Thank you for the heads up!

**tordvd** · October 29, 2019, 6:37pm

Wish there was a demo project or some resources available in the Ignition Exhange!

**tordvd** · October 29, 2019, 7:25pm

Regarding “Saving Runtime Edits”.

As an alternative to using property change script on the widget props, maybe the following can be utilized:

All configuration changes inside the widget is sent out of the View as an In/out parameter. This way, the user can configure the widget like normally, and the parameters are sent out of the widget in run time.

Then by using a save button, one can simply save the “widget” array JSON directly to the database.
Using a load button or onStartup event, one can populate the dashboard by restoring the the “widget” array.

Or am i missing something here?

**ynejati** · October 30, 2019, 2:42pm

No, I don’t think you’re missing anything. That’s definitely another, possibly better, way of going about it. I approve.

**tordvd** · November 12, 2019, 7:44am

I am struggling when trying to message the individual widgets.

Maybe each widget on the dashboard could have its unique ID passed into the widget-view. (The same way you do with the “configuring” parameter.)

This way, I can on the individual widget-view, call a common popup (tagPicker), then message the ‘page’ with the new tag path like this:

system.perspective.sendMessage('updateTagPath', {'widgetID':widgetID,'tagPath':tagPath}, 'page')

The message handler could then check if the widgetID is the correct one.

Here you can see the graphical interface for what i am talking about.

Edit:
I actually solved this by other means. Because only one widget can be in editing mode at any time. Only the widget with active “editing mode” will run the recieve script in the message handler

**Steve_Laubach** · November 13, 2019, 2:35pm

That’s good to know.

Thanks for posting all this stuff. I haven’t had time to play around with this control yet but I’m sure I’ll save time by simply reading what you said.

**Herbie** · November 13, 2019, 8:06pm

This looks amazing! We are still using Vision in 7.9. I can’t wait until we can upgrade to 8.

**wmbrits7** · November 26, 2019, 2:10pm

Is there a way to dynamically change the header of a widget.
In the example below I configured a widget view for a udt.

When I configure the widget I would like to enable the user to enter the header text as shown below

Any suggestions on how to do it?

**Steve_Laubach** · November 26, 2019, 5:53pm

When I first read this I thought to myself “that sounds easy”. Granted, I hadn’t played around with the control yet so I didn’t know what I was doing.

You probably already know this next part but just to make sure we’re on the same page…

You populate the “availableWidgets” property (array) with a list of views you want to use as widgets. When the user creates an instance of the widget at runtime you will see a new widget in the “props.widgets” property (array).

I found that you can bind the title of the widget window to a tag to pass a value into it. The problem at that point is figuring out how to marry your widget instances to the title your user has assigned to them. I feel like there’s a way to do this with a string array tag but I haven’t done much with those so I’m not sure if there’s a limitation there.

It seems like you should be able to create a string array tag with a node for each widget on your form. You might even be able to dynamically add and remove elements from the string array tag as widgets are added. From there it’s just a matter of figuring out how to marry your widgets to your string array which is something I"m not sure how you do (if you can).

**wmbrits7** · November 26, 2019, 7:07pm

Thanks, you gave me an idea. I manage to get it to work.

Made a bi-directional parameter on the widget view that is binded to the textinput text. I then keep a list that of the tagPath of the udt and index of the widget. I can then marry the two lists using the tagPath and then use the Index in the list to write to the title of a specific widget.

**wmbrits7** · November 27, 2019, 8:22am

I am having issues saving the widget properties json array to the DB. Do you have some sample code on how you manage to do the convert the array/list to a string and the other way around.

**tordvd** · November 27, 2019, 11:22am

at the moment there is no straight forward way to do this, as i understood it.
I asked the same question as you, See this post:

**tordvd** · November 27, 2019, 11:25am

I like how you got it to work. I have also been asking myself how to implement this.

I do wish that header each widget will be bound to a widget parameter like the “configuring” tag. Anything else feels like a quickfix.

Developers please

**grietveld** · November 27, 2019, 12:10pm

Its fairly simple to do once you can convert the wrapper objects. Below is the majority of my code to accomplish this. Your path to the dashboard might change, but save jsonObjectFull to a table and then I use a non-polling query binding on the property to pull it back on load. So far it seems to work fine.

   	from com.inductiveautomation.ignition.common import TypeUtilities
    User = self.session.props.auth.user.userName
	layoutFull = self.parent.parent.getChild("BreakpointContainer").getChild("Dashboard").props.widgets
	jsonObjectFull = TypeUtilities.pyToGson(layoutFull)

**deon.korb** · November 28, 2019, 6:39am

Or it can be directly editable when the widget goes into configuration mode?

**reese.tyson** · January 17, 2020, 6:12pm

Absolutely love this feature and the possibilities that come with it! I do have a feature request. While I do like the auto-rearrange feature when adding and moving widgets, it can be very frustrating at times. When trying to get a layout just right, the auto-rearrange feature continues to ‘undo’ the layout that I am trying to create. I have tried making the widgets different sizes and arranging the widgets in a different order but it always seem to “fill” to the top of the dashboard when dragging the widgets around. Maybe next to the edit and delete icons there could be a lock icon that toggles the ability to move the widget.

**yoni.peleg** · January 30, 2020, 2:58pm

Hi,
So I seem to be having trouble ‘marrying’ viewParams to a specific widget.

I created an iframe View where a user can input into a text field a url, and I made this view an availableWidget.

I added two viewParams to the availbaleWidget: configuring and src. I want the src to populate once a user enters the url. I tried doing this by binding the src entered in the View text field to a global View parameter I called src, which should automatically populate the widget because it has the same parameter name. However, it doesn’t physically populate it (I can’t see any change to the src parameter in the widget). I DO however see the url in the iframe, so there is some sort of connection being made.

Even more strange is what happens when I try to delete the widgets. If I add widget A with src a and then widget B with src b, and then I try to delete widget A, what happens is that src b gets populated with src a due to some indexing issue.

I’ve made a couple attempts to work around this but I am having trouble finding information about this relatively new component. What I need is the ability to find out which widget is currently being edited. How can this be done?

Cheers,

Yoni

**ynejati** · February 15, 2020, 1:02am

Hi,

Glad you like it. It’s still a little rough and we do have plans to improve it. Specifically the bin packing algorithm that is used to reposition widgets in available space. Currently is does repack to the top left corner, but we are hoping to refine this so that it is more natural to the user. Keep in mind, widgets do not save their new position unless a widget is dropped in a position where one or many widgets might be already placed. It might look like they are getting repositioned while you move a widget, but that is more for feedback to let you know where they might move in case the widget was dropped in its present position. Widgets will return to their original positions if their original position exists.

I hope that helps clarify things.

-Y