Probably not for reasons of commercial secrecy. What I am working on has NDA agreements in place.
However, the current implementation now works well. We generate and compile the form code on the fly, and the form runs pretty quickly to provide a decent user experience. I am using the extended WPF toolkit DataGrid in place of the standard DataGrid which has solved the performance issues.
From searching on the internet, it's clear that the performance of data grids is an issue for a lot of people, and I am sure many have their own custom implementations.
I might be able to significantly reduce the memory footprint, and increase execution time but it would require significant development time which we do not have. We need to focus on the features that our customers will use, rather than gold plate something used from time to time by a couple of our own engineers.
You come across as a troll. Every single one of your posts is a put down. The suggestions you make are vague abstract comments (the kind that someone with no real knowledge could make), with no helpful content and nothing to indicate any actual technical knowledge on your part. Do you have anything constructive to say or is your goal simply to piss on me? Frankly I am getting pissed off with your obnoxious trolling.
The layout was designed by the engineers. It's what they have asked for and what they want. They've seen the current prototype and like it. It's the same as in the previous application which has served them well.
We need to configure a hard ware device, which provides configuration settings as tabular data. There are lots of different sets of tabular data. We want to display a given table in a view, so that the user can edit the fields. All fields in a given row have the same kind of data e.g. integer. However, one row might display integers, another might display a combo box, and another a check box. The problem is how to automatically create the WPF view and view model code.
The nature of the data in each table is defined in an XML file. Unfortunately for one table the number of columns is defined by a value in another table which is only known at run-time.
Thus we can create some tables at build time, but one must be created at run-time.
I created a parser which generates the WPF view and view model for each table of data. This parser can be run at run-time to generate view and view model source code, which is then compiled at run-time, and displayed. So far so good. This works well with one exception, as the number of fields is almost always modest.
Unfortunately one table has ~120,000 cells, and the resulting view model will not run as the number of controls exceeds the maximum allowed by WPF. The view will display and looks good. Clearly having so many properties in a view model is a tad ridiculous and crude.
So, we need a more elegant solution, and one which allows the values to be displayed in a table with cells all nicely aligned.
The view model contains a list of field objects, each of which provides data in the correct format for the corresponding table cell e.g. "true" and "false" for tick box. Is it possible to create a DataGrid, such that it gets its data from my table of fields, and displays the correct kind of control dependent on the nature of the data (which my field object knows)? Thus row 0 might be tick boxes, row 1 edit boxes, and row 2 combo boxes?
I came across some example code that almost solved our problem, and with some changes it does the job in my demo application which I will explain below in case anyone finds this useful. The link is as follows:
I created an Image button called MultiImageButton with 4 properties for Normal, Mouse Over, Disabled, and Pressed. I won't post the class code (unless you want me to ) because it works and isn't the problem. The class is in the Controls folder.
Bindings for value DataGridTemplateColumns don't show correctly in the designer intellisense, though they are binding to the ItemSource for your grid. It's an annoyance that I've learned to live with, as the values do bind correctly at run time.
That said, your style trigger is pretty mungy. Is there a terribly compelling reason that you can't do: