How to set up column width in OMI SQLDataGrid?

Hi,

I checked the actual SQLDataGrid control (SQLDataGridUserCtrl.dll, the .Net WinForms control built on Infragistics UltraWinGrid) directly against its compiled interface.

It exposes several properties (SQL query, connection settings, paging/write commands, fonts, column grouping/aggregate/filtering toggles, etc.),

but there is no column width property anywhere in that surface, public or private.

The underlying Infragistics grid engine (ultraGrid1) does support per-column width natively, it's just never wired up to a settable property on the control.

As an alternative, instead of having the SQLDataGrid control query the database directly, query the data yourself via scripting and pass the result set into a DataGrid widget instead.

Unfortunately this doesn't get you around the problem either. I checked the included DataGrid widget the same way (its full property/config schema), and it has the identical limitation, no column width property, global or per-column. Its underlying grid (Kendo Grid) actually auto-fits every column to content on every data refresh, which overrides even the widget's own hardcoded default width.

Example location of the widget: C:\Program Files (x86)\ArchestrA\Framework\FileRepository\<Galaxy>\Vendors\Widgets\datagrid

So switching from the SQLDataGrid control to a scripted-data-into-widget approach initially doesn't solve the column width problem.

The grids also does support manual resizing, you can drag a column wider at runtime, but that's not scriptable, isn't persisted, and gets wiped out the next time the data refreshes (auto-fit kicks back in).

So it's not a real workaround, just a temporary cosmetic fix per session.

But.. Since a widget is not a black box, you (or whoever manages your Galaxy) could actually open it up and add these features yourself.
The DataGrid widget is a fairly small, self-contained web widget, a wjson property schema plus a JS bundle that builds the Kendo grid.
Adding a ColumnWidth/MinColumnWidth property and wiring it into the column definitions (and disabling/adjusting the auto-fit so it doesn't overwrite it) is a quite modest change. That's obviously a bigger ask than "flip a setting," but it's realistic if you have someone comfortable poking at the widget's JS.

More broadly, both of AVEVA's datagrid options (the classic .Net WinForms/WPF control and the OMI HTML5 widget) are pretty limited out of the box, and there are several things you'd expect from a data grid component that just aren't there.

AVEVA's support and development focus on these components seems fairly limited in general. But the flip side is that the custom-widget concept is genuinely open. Nothing stops you from building your own from scratch (or forking the existing widget) to get exactly the grid behavior you want, including proper per-column width control, if the built-in one doesn't get you there.

If you go the "build your own" route, AVEVA doesn't have official documentation for the WebWidget toolkit itself. There are some community guidelines and examples floating around, but nothing comprehensive from AVEVA. There's also a specific set of files required to package/compile a widget into something importable into your Galaxy, and that packaging step isn't obvious if you're starting from zero.

For what it's worth, I've already gone through the process of getting a basic datagrid working for OMI from scratch, so I've hit most of the walls you'd run into, the packaging requirements, and the "features you assume exist until you build it yourself",

(sorting, filtering, column sizing, persistence, or editing, extracting data based on selection, the use of icons and so on),
This all tend to need their own work.

Happy to talk through it if useful. It should at least save you some of the trial and error on where to start.

On the topic of listing dynamic data in OMI witch is usually the reason for bringing in SQL Data Grid.

As an alternative you could look in to the graphic repeater component, it allows for dynamic listing of data in quite elegant way. (requires your dataset to be converted to a csv format string), and you have the full power of any animation available in your symbol editor enabling user interaction with the datarow. 

This would allow you to stay to "out of the box functionality" without any manual tinkering in the widgets.

Hi,

I checked the actual SQLDataGrid control (SQLDataGridUserCtrl.dll, the .Net WinForms control built on Infragistics UltraWinGrid) directly against its compiled interface.

It exposes several properties (SQL query, connection settings, paging/write commands, fonts, column grouping/aggregate/filtering toggles, etc.),

but there is no column width property anywhere in that surface, public or private.

The underlying Infragistics grid engine (ultraGrid1) does support per-column width natively, it's just never wired up to a settable property on the control.

As an alternative, instead of having the SQLDataGrid control query the database directly, query the data yourself via scripting and pass the result set into a DataGrid widget instead.

Unfortunately this doesn't get you around the problem either. I checked the included DataGrid widget the same way (its full property/config schema), and it has the identical limitation, no column width property, global or per-column. Its underlying grid (Kendo Grid) actually auto-fits every column to content on every data refresh, which overrides even the widget's own hardcoded default width.

Example location of the widget: C:\Program Files (x86)\ArchestrA\Framework\FileRepository\<Galaxy>\Vendors\Widgets\datagrid

So switching from the SQLDataGrid control to a scripted-data-into-widget approach initially doesn't solve the column width problem.

The grids also does support manual resizing, you can drag a column wider at runtime, but that's not scriptable, isn't persisted, and gets wiped out the next time the data refreshes (auto-fit kicks back in).

So it's not a real workaround, just a temporary cosmetic fix per session.

But.. Since a widget is not a black box, you (or whoever manages your Galaxy) could actually open it up and add these features yourself.
The DataGrid widget is a fairly small, self-contained web widget, a wjson property schema plus a JS bundle that builds the Kendo grid.
Adding a ColumnWidth/MinColumnWidth property and wiring it into the column definitions (and disabling/adjusting the auto-fit so it doesn't overwrite it) is a quite modest change. That's obviously a bigger ask than "flip a setting," but it's realistic if you have someone comfortable poking at the widget's JS.

More broadly, both of AVEVA's datagrid options (the classic .Net WinForms/WPF control and the OMI HTML5 widget) are pretty limited out of the box, and there are several things you'd expect from a data grid component that just aren't there.

AVEVA's support and development focus on these components seems fairly limited in general. But the flip side is that the custom-widget concept is genuinely open. Nothing stops you from building your own from scratch (or forking the existing widget) to get exactly the grid behavior you want, including proper per-column width control, if the built-in one doesn't get you there.

If you go the "build your own" route, AVEVA doesn't have official documentation for the WebWidget toolkit itself. There are some community guidelines and examples floating around, but nothing comprehensive from AVEVA. There's also a specific set of files required to package/compile a widget into something importable into your Galaxy, and that packaging step isn't obvious if you're starting from zero.

For what it's worth, I've already gone through the process of getting a basic datagrid working for OMI from scratch, so I've hit most of the walls you'd run into, the packaging requirements, and the "features you assume exist until you build it yourself",

(sorting, filtering, column sizing, persistence, or editing, extracting data based on selection, the use of icons and so on),
This all tend to need their own work.

Happy to talk through it if useful. It should at least save you some of the trial and error on where to start.

On the topic of listing dynamic data in OMI witch is usually the reason for bringing in SQL Data Grid.

As an alternative you could look in to the graphic repeater component, it allows for dynamic listing of data in quite elegant way. (requires your dataset to be converted to a csv format string), and you have the full power of any animation available in your symbol editor enabling user interaction with the datarow. 

This would allow you to stay to "out of the box functionality" without any manual tinkering in the widgets.