Evan, Ross and Mark,
What I want to do and have successfully accomplished 80%-90% of, is to data drive the configurator display screens, in my case from a Configurator lookup file which holds all the row, column, length, format details of the fields I want to show on the configurator screen.
I have an external program that generates a screen display much easier than the configurator (about 5 minutes to design a bespoke screen) and this outputs the data in a table form (1 x row per control) to an excel spreadsheet which you can then import into the configurator lookup table. The lookup table holds the data for each design screen with a major key being the screen number which will have multiple rows for each field.
Once a screen design is selected from the configurator by the operator, using the PCLookup feature all the data for the requested screen is loaded in and fields are placed on the screen in the correct row, column locations and formatted as required…This works fine, with no issues.
Using Evan’s coding method of loading like inputs into C# Lists each existing input field is then loaded into the list and associated with a field in the Configurator Lookup table making all displayed inputs to be easily modified as the input control can be manipulated by referencing an element in the “input type” list. Effectively you manipulate the inputs by accessing them as a list element. The element number is held inan internal array which mimics the configurator lookup table but contains the list element number of the control it is bound to as opposed to the input name.
This works fine but we have some 50 possible screens that the sales people may well be using, each being a product or a variation. In addition the total number of unique fields to display in the configurator over all screens could be 500-600 “inputs”. Despite only one screen being used for the product, you have to hold all the possible inputs for all the possible screens if you conventionally drive the configurator and only being able to make the inputs visible or invisible - a very messy method of display.
Doing it my way the inputs have to be pre-defined before you can create a list of them in C# so I simply wanted to create the inputs on the fly as I load in the data driven screen data from the configurator lookup table as opposed to hand tabbing them into the configurator as fixed items at configurator entry time. The controls are a mixture of character, checkbox, decimal fields with a couple of images thrown in for good measure.
Not knowing how many of each control I may need now and in the future I have initially pre loaded up 50 of each field type (not images as we only need a couple) into the configurator. I may need 200 text fields but only 50 check boxes and 40 combo boxes over all screens or any combination, so loading up the maximum I will need at configurator entry time is the only way to be sure you can accomodate any input screen. However, creating the inputs on the fly once I know from the data driven table which screen I want to display and hence the number and types of fields I require would be the optimal solution.
The advantage of data driving the runtime displays is that you can assign a list Number to each control having set up lists for each of the data types which you can in effect bind to an internal array of controls as loaded in from the configurator lookup table.It is the closest you can get to having an object reference to an input.
Hope this is making sense to you all. If not I can post some screenshots and examples of it in action for you to see along with anyone else who is interested. Data driving all input screens is something I have always done in C# projects as you generate the data driving software once and then can re-use it ad infinitum. Unfortunately the inability to use C# reflection in the configurator limits whet you can do to manipulate objects in the configurator but I have overcome this, as I said earlier, with some out of the box thinking.