Detect if an XLL is open?

[Patrick O'Beirne]

Hi Govert,

How can I tell from VBA the name(s) of any open XLLs?
Or even if a specific known name is open?
If I double-click on a exceldna .xll, it opens and the functions are
present but it's not visible in the Workbooks or Addins collections.

And how would I programmatically open or close the XLL from another XLL
or from VBA?

Thanks

P

[Govert van Drimmelen]

Hi Patrick,

Using the C API from inside another Excel-DNA add-in, you can use the
XlCall.xlfRegister function to load an add-in. Closing is a bit
tricky, but there is a way to do it. Some examples of how you could
make a 'host' add-in in this discussion
https://groups.google.com/group/exceldna/browse_thread/thread/6e668735035f4acc.
I'm happy to help if you need help with this example.

Via COM (from VBA or another Excel-DNA add-in) you can call
Application.RegisterXLL to open an .xll, or you can do
Application.AddIns.Add("...path here...").Installed = True. I think
this doesn't just load, it adds it as a persistently installed add-in.
Then if you kept track the new AddIn object, you can unload it with
myAddIn.Installed = False.

No idea how you can know about the open add-ins for your Excel
session. Maybe you can experiment a bit with the Name APIs.
I guess you could also use P/Invoke and some WIN32 API to enumerate
the loaded modules, and pick out the ones with .xll extensions from
there. But an add-ins could also have .dll or some other extension, so
you'd not be sure.

Of course your own add-ins could register themselves somewhere, maybe
using .NET remoting and some IPC mechanism to make a cross-AppDomain
singleton that keeps track of things.

What are you actually trying to do?

Regards,
Govert

[Patrick O'Beirne]

Thanks, Govert

I started from noticing that when I double-clicked an XLL to open it,
the only way I had to know if it was open was to attempt to call one of
the functions in it.
I couldn't see it from inside Excel, even though Excel had opened it,
warned about macros, and I enabled them.
So I was wondering if there was any way to check if it had opened
successully.

P

[Naju Mancheril]

The workspace call looks cool.

You can also just enumerate over all addins using interoperability, right? The Addins property is enumerable with foreach. You can cast each item to type Addin.

Maybe if you needed to do this one-off in a runnig excel, you would do this in VBA?

If you want this functional permanently, the maybe you could write a "debug addin" that exposes this macro. Then you could use it to debug your other addins.

[Patrick O'Beirne]

Thanks, Keith.

GET.WORKSPACE(44) is the same as Application.RegisteredFunctions
When I try that from VBA, I indeed see the XLL functions, although their name is f0, f1, etc.

...TestFuncs\bin\Debug\TestFuncs.xll	f0	QQ
\TestFuncs\bin\Debug\TestFuncs.xll	f1	QU#
\TestFuncs\bin\Debug\TestFuncs.xll	f2	QQ

So that solves that problem, thank you.
Naju: the Addins collection is no help because the XLL was simply opened in Excel, not registered as an Addin.

By the way, I was curious to see if i could use this information.
I know I can call the function directly as a UDF
f1 is really SumNConstants(<ExcelArgument(AllowReference:=True)> ByVal RangeToSum As Object) As Double
so I can type =SumNConstants(B6:B8) in a cell and get the answer.

I can make them visible to VBA using this declaration
Declare Function SumNC Lib "TestFuncs.XLL" Alias "f1" (ByVal rg As Range) As Double

x = SumNC(Worksheets("Sheet3").Range("B6:B8"))
but I get an error "Expression too complex."
The function uses ReferenceToRange and the address of the reference passed in is "15" rather than the expected " Sheet3!$B$6:$B$8"
Just a curiosity, nothing that I see I can use yet.


On 02/08/2012 23:04, Keith Lewis wrote:

You can call GET.WORKSPACE(44) from the C api:

A three-column array of all currently registered procedures in dynamic link libraries (DLLs). The first column contains the names of the DLLs that contain the procedures (in  Microsoft Excel for Windows) or the names of the files that contain the code resources (in Microsoft Excel for the Macintosh). The second column contains the names of the procedures in the DLLs (in Microsoft Excel for Windows) or code resources (in Microsoft Excel for the Macintosh). The third column contains text strings specifying the data types of the return values, and the number and data types of the arguments. For more information about DLLs and code resources and data types, see the "Using the CALL and REGISTER Functions" in the Appendix for the Microsoft Excel Worksheet Function Reference, or Using the CALL and REGISTER Functions in online Help.

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To view this discussion on the web visit https://groups.google.com/d/msg/exceldna/-/VAwqcXEAL58J.
To post to this group, send email to exce...@googlegroups.com.
To unsubscribe from this group, send email to exceldna+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/exceldna?hl=en.

[Govert van Drimmelen]

Hi Patrick,

In general the VBA Declare style access will not work. The Excel-DNA
functions return XLOPER data structures to Excel (that's what the 'Q's
mean in the registration string), and dealing with these in VBA would
be a nightmare. The fact that it nearly seems to work is a red
herring. For functions that take doubles and return a double you might
be able to pull it off with the 'IsExceptionSafe:=True' option set on
the .NET side. But there is no chance of passing strings or objects
around that way.

The COM Server support is the right direction to look if you really
need to use the .NET code from VBA.

Regards,
Govert

[aberglas]

For installing an addin using COM, I had added some docs here

http://exceldna.codeplex.com/wikipage?title=Installing%20your%20add-in&referringTitle=Documentation

Anthony