I am working on another project in the configurator designer screen where I need to load an external dll. Most screen customizations, I can simply Add an Assembly Reference and load the dll there. But the problem I am having is on the ‘test inputs’ screen is where I need to load the dll and best that I can tell, this screen is scripted (using CompileCustomScript) and generated at runtime and I can’t seem to find a way to ‘customize’ that screen. I can add a button on the test inputs screen but I do not have access to the head of the code so I can’t specify a using declaration and I can’t utilize reflections to accomplish this (because once again, I can’t reference System.Reflections to load/reference a dll at runtime).
I would like to load the test inputs screen and load the dll within the test inputs screen:
Which gets me to:
As you may have guessed, I am trying to open an Excel file to map values directly into the fields, which is why I need to load an external reference - to open/navigate the excel data.
Now, I know this can/has been done because our company paid to have this custom built before and we want to get away from reliance on some of our 3rd party customs and dlls.
Perhaps there is another way I can approach modifying this screen? I have begun looking at the ICE.XXXDef and ICE.XXXChunk and I can see where the base and custom code is in there but I am a little confused on if XXXDef is encoded/encrypted and then decrypted and loaded into XXXChunk or how that all works or if I can just make change to XXXChunk to see if it works? This approach seems pretty extreme but I am still very new to Epicor.
Our engineers compile and output a lot of their data from spreadsheets. Relying on Excel is one thing, relying on custom built dlls that break with every upgrade is a entirely different problem. I hope that makes sense
I am quite hopeful here, as it looks like this may work. I will follow up with the end result or any issues that I can’t figure out. Sometimes it is something as simple as declaring the full namespace. Here’s to hoping
It looks like that is all I needed. I dug way too deep looking for solutions in all the wrong places when the answer was right in front of my face. Much appreciated!
var DLL = System.Reflection.Assembly.LoadFile(@"C:\Program Files (x86)\Microsoft Visual Studio\Shared\Visual Studio Tools for Office\PIA\Office14\Microsoft.Office.Interop.Excel.dll");
string t = "";
foreach(Type type in DLL.GetExportedTypes())
{
t += type.ToString()+"\n\r";
}
MessageBox.Show(t);
Oh, it makes complete sense. We have engineers too! Ask them, “How many machines run with this parameter at 150 or more?”
“Oh, OK. How many different parts run across this machine?”
“Why can’t you answer me?”
“Well, everything’s in hundreds of Excel spreadsheets on dozens of desks around the organization.”
If engineers engineered parts like they do their data… smh
But, that’s not what I was asking. Why are we pulling it directly from Excel? What if the worksheet is open, or worse, incomplete? How do you know the data is “ready” for input into Kinetic?
One possibility is to have a publish button/macro on these spreadsheets that store the results into a repository that is easier to query. This will make it much easier if/when you move to the browser and you won’t have to worry about that dependency anymore. Nobody is asking them to stop using Excel. We just want them to use it more effectively.
Haha, I completely agree with the overuseage of excel here. It’s the hammer that they know so who am I (the new guy) to lecture them on what tools they use. I actually have a process in the works with Node.js that harvests all of their data from the spreadsheets and dumps them into an intermediary database, so that is likely going to be the long-term solution.
Hundreds of excel spreadsheets in many dozens of locations, I hear ya.
