Hi Liang,
Ah - I see where some of the confusion is coming from.
1. Excel-DNA integrates with Excel via the C API, and not as an
Automation Add-in. This has a few advantages - no registration is
required, so no admin permission on the client are needed to use the
add-in. The UDF performance is generally better. There is more
flexibility in support for how functions are displayed in the function
wizard. Multi-threaded UDFs can be created. And more...
The main difference in your code between an Automation Add-In and
Excel-DNA functions is that the Excel-DNA functions have to be
declared as 'public static' functions, and that you'd deal with
'Range' parameters in a different way.
2. Although the Excel-DNA ribbon support uses COM integration behind
the scenes, your add-in will not be created using either the COM add-
in templates or the VSTO libraries in Visual Studio. So you would
never use the 'Create an Excel add-in' options in Visual Studio with
Excel-DNA. You will never use anything like 'ThisAddIn' whcih is
generated for you.
3. Excel-DNA does not use the ribbon wrapper classes that are part of
VSTO (the references that start with Microsoft.Office.Tools.*), so you
will have to manage the ribbon xml yourself, and perhaps make some
helpers classes to keep it the ribbon updated (you can't just set
'properties' on the ribbon - everything is calllback-based).
To get started using Excel-DNA with Visual Studio and C#, you can
follow this step-by-step guide to make your first C# add-in:
http://www.codeplex.com/Download?ProjectName=exceldna&DownloadId=372242.
Then for the ribbon you can look at the examples in Distribution
\Samples\Ribbon to get you started - the easiest route is to put the
ribbon .xml in your .dna file, and then define a handler class in your
library that is marked [ComVisible(true)] and derives from
ExcelDna.Integration.CustomUI.ExcelRibbon.
I don't yet have a nice write-up that positions Excel-DNA vs. the
other ways of integrating with Excel. So you have more specific
questions, I'd be happy to answer if you post back.
I think once this confusion is sorted out, the rest of this discussion
will make more sense.
Regards,
Govert
> I tried the share state idea. But couldn't get it to work. I think I miss
> something, therefore the login state wouldn't share. I didn't exactly
> follow your suggestion of using the same assembly, but rather added the
> reference, and I didn't use ExcelDNA, as I just try to figure the general
> idea first.
>
> What I did was:
>
> 1. Created a class library (MyFunctions class) for Automation addin for UDF.
>
> 2. Created a Excel add in (2010) and added a Ribbon (actually, how the
> Ribbon loads itself without being in the Addin reference and constructor I
> also couldn't understand, please forgive my understanding).
>
> private void ThisAddIn_Startup(object sender, System.EventArgs e)
> {
> MessageBox.Show("Add in loaded");
> }
>
> 3. In the Ribbon class, I adds the an object reference for the automation
> addin (Myfunctions), and changed its login state in the initialization.
> public partial class Ribbon1
> {
> public MyFunctions autoAddin = null;
>
> private void Ribbon1_Load(object sender, RibbonUIEventArgs e)
> {
> }
>
> private void btnLogin_Click(object sender, RibbonControlEventArgs e)
> {
> autoAddin = new MyFunctions();
> autoAddin.IsAuthorizaed = true;
> MessageBox.Show("The auto addin is logged in in the Ribbon");
> }
> }
>
> Build the Excel Addin project, and open an excel application.
>
> The result is:
> 1. Excel add in loaded immediately after excel started.
> 2. After excel started, I tried to execute UDF, the login state is false.
> 3. I clicked the login button in the ribbon, message shows an automation
> addin has been created (MessageBox.Show("The auto addin is logged in in the
> Ribbon") in the ribbon class). But this did not change the existing UDF
> login state.
>
> The problem is the Automation Addin in the UDF is loaded by excel. And
> there is no reference to it that can be used to manipulate its state. Even
> though create another automation addin in ribbon would not work.
>
> So i guess my question is how ribbon can get the reference of the existing
> instance of the automation addin, therefore manipulate its state? Is this
> possible without using ExcelDNA? If not, how does ExcelDNA tackle this
> issue?
>
> Best Regards,
> Liang