Data Sharing with Custom Task Pane

[Achilleas Stamos]

Hi All,

I have created a Custom Task Pane which contains a DataGridView. The Grid is bound to a static object in a static class within the broader dll/xll.

When I pass data to that object through the CTP I can see the data is written correctly into the object. However if I then try to access that same object from a different part of the code, for example from a different winform, the object seems to be null/hold no data.

Has anyone come across this issue previously? Any workarounds?

Many Thanks,

Achilleas

[Govert van Drimmelen]

----------

Excel-DNA is now registered on GitHub Sponsors.

Please sign up as a sponsor to help fund future development.

----------

Hi Achilleas,

That sounds like a case where the CTP control or the form is loaded into a different AppDomain (probably the default AppDomain) to the custom AppDomain where the add-in lives.

If you have build a form control and switched on the "Register for COM interop" option in the Visual Studio project, you'll get the the control is activated through the .NET runtime and not the add-in and Excel, causing this trouble. I guess there are other ways it can go wrong.

I suggest you add some code to trace the AppDomain in these different contexts (off the top of my head, something like AppDomain.CurrentDomain.Name should work).

Then you can see whose in the wrong AppDomain and figure out how to get it to load into the add-in domain.

It's a bit tricky by the time you have both a CTP loading a user control and a separate form all inside your add-in.

-Govert

[Achilleas Stamos]

Hi Govert,

Good morning and many thanks for your quick response.

You are bang on the money. The two reside in a different domain.

The winform is in the DefaultDomain whereas the CTP is in FullTrustSandbox(Excel-Dna: .... .xll).

I experimented a bit further and tried to access the static object through a com class I exposed to vba. The same issue persisted. The com class was in the DefaltDomain whereas the CTP was in the FullTrustSandbox.

I then also thought about invalidating the Ribbon programatically through a com class exposed to vba. And I found the same problem. The com class once again in the DefaultDomain whereas the Ribbon in 

FullTrustSandbox.

Doing some additional logging effectively it boiled down to the fact that the Ribbon and CTP are in the FullTrustSandbox domain and anything else in the add-in is in the Default Domain.

Any thoughts on how I could bring the two together please?

Much appreciated,

Achilleas

[Govert van Drimmelen]

Hi Achilleas,

To deal with this situation, Excel-DNA supports a way to expose COM objects from inside the add-in (and hence the add-in's AppDomain.

These COM objects may be used from VBA or in other contexts, like the CTP task panes.

The key is to not have the COM project (the dll you're building) registered via the normal .NET mechanism.

In particular, this means you should never enable the "Register for COM Interop" checkbox on the project, and you should neve use RegAsm to register such assemblies.

There is a detailed write-up of setting up such a COM server in an Excel-DNA add-in here: Samples/DnaComServer at master · Excel-DNA/Samples (github.com)

I suggest you try to work through that sample in a new project, and then try to back-patch into yours.

Please ask if you run into any snags.

-Govert

--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/exceldna/d1c2c093-2dba-4686-86b1-52918fac22bfn%40googlegroups.com.

[Achilleas Stamos]

Hi Govert,

Thanks again for your help.

You were right. I was effectively having a Debug issue, as I was not registering the AddIn.xll in my post build events. I was instead exposing the .tlb and referencing that directly in my References in vba, whereas in a prod set-up everything was working fine.

I followed the instructions in your link above to point to the AddIn.xll when Debuging and that has now resolved my issue.

Thank you,,

Achilleas