Anyone know how to generate an “Input object” in the configurator using code? I have to add 500 inputs (TextBoxes, Comboboxes and CheckBoxes) to a configurator screen and name them in a specific way so to do this in code would save the effort! I have tried in code using the object types used to generate an internal list of Inputs but can’t get it to work.
I guess that E10 is protecting the underlying framework from being tampered with but I may be wrong.
Thanks in anticipation.
Dave
I’d rethink a configurator that need 500 inputs.
But if you really need to do it, maybe a uBAQ on the PcInputs table would might work.
I agree with @ckrusen. The whole configurator system is gonna give you trouble with that I think. Even saving could take a while.
If you explain more about the end goal we might be able to help you brainstorm an alternate solution.
I agree with others, consider other approaches to see if you can reduce the number of controls. I have worked on Configurators that needed that many controls so not saying it might not be legitimate.
You can do a paste insert into the list page. Add one of each control type you want to add. Go to the list page, Right click and copy to Excel. Then using these rows as templates, add rows to excel, change the name, do a simple incrementing of the X and Y pos. Then copy paste insert the new rows. Make sure not to paste insert the original rows. Then drag the controls where you want them. You can’t paste insert on leave code and the like so you will need to visit each control to add that. If you are NOT in the cloud you could export the configurator and do some hand editing of the xml and then re-import. But real easy to get the xml wrong.
James,
I have done that no problem but I am trying to take the whole “page design phase” out of the configurator by data driving it from a configurator lookup table so that I can only display the controls that I want to use for the product chosen by the operators as opposed to having to pre-allocate all the inputs in the design space.
This sounds like the fence I find myself on, when designing configurators. We have a product line that has variations based on the application. They’re all pretty similar - hence why I’m making a configurator - but different enough that individual configurators might make more sense…
The innards of the products are the same - but still need configuration (current capacity, length, etc…). The outer jackets vary the most. There are: fabric, wrapped, metal mesh, and perforated HDPE jackets. Some are meant for direct burial, other for in water, etc… It’s not just different materials for the jacket, but the processes are much different.
So I wrestle with the choice of making one configurator that allows the user to select the jacket type, and the configurator has to do all the logic of which other inputs to show, set limits, etc… Or making separate configurators (one for each Jacket type).
The first only requires maintaining one very complex configurator - and not just the user input aspect but all the row rules. The second is requires four configurators that are much simpler and concise - but have a lot of overlap, meaning a simple change might need to be done 4 times (one in each configurator).
Creative use of cascading configurators can be helpful. There is a primary/top level configurator and based on the answers different sub-assemblies are picked/kept which calls the configurator associated with that sub-assembly.
One thing that gets missed that sometimes reduces complexity is materials can be moved from an operation to another operation. For example if the entire part needs 8 materials but the number of materials on an operation aren’t fixed. An operation might need 3 materials sometimes and 5 other times Another might need 5 sometimes and three other times but between the two never more than 8 total. Frequently I will see 5 materials on both operations. By moving materials we only need 8 total materials. If materials move a lot I will sometimes put all the materials on First Operation and move them to the operation it goes with or get rid of them if not needed.
For operations one configurator I work with uses a lookup based on the base part number to set the operations dynamically. The method has 15 operation placeholders, the lookup will return up to 15 opcodes, if it returns less than that the left over operation placeholders are deleted.
You can still use that approach, a lookup table can tell us which controls to make invisible and if desired you can move them to make things look nice and eliminate blank areas.
I am working on a boat configurator that does that, one model has a ton of options, the other only a handful. I make the options/controls not needed invisible and dynamically move the remaining controls to be nicely laid out top to bottom.
Guys,
I have now completed the “front end” to the configurator and I am more than happy to release it as open source to anyone who wants it along with an easy screen design program that generates the “output screen data driver” information. Over the next few days I will release the source code along with a short video so you can see it in action. Then I am going to move onto the operations configurator and deal with it in the same way using the same framework. We manufacture plastic film that can be made up of up to 7 layers each layer containing up to 6 materials. each layer is allocated a fixed percentage of the final film thickness despite the film thickness being maybe 80 micron. The film can be made on many types of alternative machines, some producing 3 layers and others more layers so a different BOM needs to be generated for each method of manufacture as the layer ingredients can change acording to the MOM.
This complexity and the number of potential material parts along with the numerous Operator inputs required to customise the final sales product lead me to use this data driving approach as I have written many commercial data entry systems in C# using this method but must admit to never ever being as frustrated at the lack of a stable development environment in which to test out software. Doing this using standard in-line code would have taken a lifetime and been a real pain to maintain. Maintaining the system as is when data driven, simply means either reloading up the screen design software and generating a new display or modifying the data driver for the film type as held in a configurator lookup table or held in an Excel spreadsheet outside the system as a master that can be modified and re-imported after modification.
Now I am belt and braces, testing out the pure C# code in Visual Studio, holding a copy of the configurator source code in Note++ and finally copying and pasting the final code into the configurator methods to test out and debug. It is a long winded process but I was caught out so many times when I started this by the configurator white screening and generally not being responsive… especially if you happen to hit the “.” and activate the intellisense … or what masquerades as intellisense, but in reality is of no use whatsoever… at least on the Epicor Public Cloud.
Tell me, does the Premise based intellisense work any better or in fact does it work at all?
to create a bunch of inputs, you can use the grid view to paste them in… I often use the grid view in the configurator… I will create a couple of fields, then Copy from the grid view into Excel… then you can replicate the fields to create many similar fields. You can even specify the position of the fields, the names, and types… Excel is excellent at doing this.
Tim,
That is great and I do use that but it is only available at design time not run time!
Dave