Jason Sobell
Posts: 18
Joined: 2008-04-02
|
I noticed that when I accidentaly renamed the XLLContainer class, the plugins failed to load with Excel generating various confusing errors.
As we have a large number of functions, and may even wish to load some dynamically, can you explain the rules regarding the hosting of the UDFs?
Are you using reflection to look for an embedded class with the name 'XLLContainer'?
The ideal would be if the UDF definition contained a delegate refering to the static function it relates to, then we could create as many static classes as we like, add them dynamically, and simply refer to them at runtime.
The main issue we have at the moment is that we have to modify every class to begin with
[U]Partial[/U] Class XLLModule
{ Friend [U]Partial[/U] Class XLLContainer
...
just so it will be recognised as a UDF.
Cheers,
Jason |
|
Sergey Grischenko
Add-in Express team
Posts: 7233
Joined: 2004-07-05
|
Hi Jason.
You can modify the name of the XLLModule class only. In this case you also need to modify the adxloader.dll.manifest file (see the 'xllClass' attribute). |
|
Jason Sobell
Posts: 18
Joined: 2008-04-02
|
Hi Sergey,
So does this mean that you have hard-coded the system to look for a class 'XLLContainer' inside the class specified in xllClass="WarehouseAddin.XLLModule"?
Does the ADXXLLModule use reflection to scan this module?
It seems odd to have to embed all your function in a specifically named nested class of the base class, so could you add the UDFFunctions name as a parameter of the manifest (and default to the XLLContainer class)?
Cheers,
Jason |
|
Sergey Grischenko
Add-in Express team
Posts: 7233
Joined: 2004-07-05
|
Hi Jason.
Yes, the XLLContainer class is a hard-coded class/container. And Add-in Express uses reflection to search for XLL functions. I really don't see any restrictions of this, do you?
|
|
Jason Sobell
Posts: 18
Joined: 2008-04-02
|
Well, only the fact you end up with monolithic classes that can't be extended programatically.
The ideal would be to have any specified class registered with the base class, which would allow developers to create multiple individual DLLs and have them all registered in a single XLL.
I did a lot of work with (and on) the ExcelDNA library, and I know how frustrating it is when multiple developers modify function classes. Having the flexibility to extend classes in .NET is wonderful, and ExcelDNA does this by allowing you to specify all the DLL libraries in it's config file.
In my systems I modify the library to support a 'plugins' folder and I dynamically load the DLLs in this folder, so other developers can add to the collection without a recompile of the existing base XLL.
The current XLLContainer implementation prevents you doing this, and it seems a shame to have a restrictive process when a few lines of well thought out code would open a range of other registration methods.
Why not create a base class for external libraries to inherit for the XLL functions (protecting any licensing issues), and add a method something like 'RegisterContainer(XLLContainer)' that can be optionally called if someone want to register more than the default contained class?
I think the Add-in Express product has enormous potential, and these are developer based suggestions for improvements, not criticisms.
Cheers,
Jason |
|
Sergey Grischenko
Add-in Express team
Posts: 7233
Joined: 2004-07-05
|
Hi Jason.
Thank you for the suggestion. I will think it over. Probably I should add an additional XLL module class as it is already done for COM add-ins. |
|