Thanks, that is exactly what I have asked for.

One final question: As I can see, using this technique, only static methods
and properties can be invoked on add-in class?

"Ken Slovak - [MVP - Outlook]" wrote:

You didn't look closely enough at the templates. Look at the code at the end
of the ThisAddin class in the section starting with this line:

public static AutomationObject AddinObject = null

That code and what follows in the override and interfaces, along with the
AutomationObject class are what you need. That will expose the addin and
from there the code in the CalledFromOutside method shows how to expose
properties to the outside. You can modify that to call methods in your addin
code also.

To call from outside you'd use something like this (VBA code):

Dim oAddin As Office.COMAddIn

Set oAddin = Application.COMAddIns.Item("MyVSTOAddIn") ' the addin name
here
If Not (oAddin Is Nothing)
oAddin.Object.CalledFromOutside
End If

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Nenad" wrote in message
...
I can get a reference to Office.COMAddIn, but what I really need is a
reference to TheAddIn (which is a subclass of a
Microsoft.Office.Tools.AddIn
class and is inherited from
Microsoft.VisualStudio.Tools.Applications.Runtime. IStartup interface).

This is code from Initialize(Outlook.Application app) method from user
control hosted in FHP:

object name = "MyAddIn";
Office.COMAddIn addin = (Office.COMAddIn)app.COMAddIns.Item(ref
name);
ThisAddIn add = addin.Object as AddIn.ThisAddIn;

I was hoping that I will get a reference to VSTO AddIn using addin.Object
property, but it is always null. I also tried to set that property in the
start-up event of the add-in, but it caused TypeMismatch error, so I
assume
that it is a misleading.

Anyway, I have set [ComVisible(true)] attribute on the add-in, but it
didn't
helped.

Thanks for templates, they are great, but I didn't find what I needed
there.

Thanks

I believe that static is a requirement, but I'm not positive. Try it without
and see if it works. If it doesn't that still lets you set the externally
visible interfaces as static and still work with non-static methods and
properties.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Nenad" wrote in message
...
Thanks, that is exactly what I have asked for.

One final question: As I can see, using this technique, only static
methods
and properties can be invoked on add-in class?

No, it is not necessary to be static, not even a add-in member
field/property. The only requirement is that an instance of a class that is
returned from a RequestComAddInAutomationService event handler is
implementing a given COM interface.
I am using code like this:
protected override object RequestComAddInAutomationService()
{
PreInitialize();
return new PreInitializeData(factory, client);
//return base.RequestComAddInAutomationService();
}

"Ken Slovak - [MVP - Outlook]" wrote:

I believe that static is a requirement, but I'm not positive. Try it without
and see if it works. If it doesn't that still lets you set the externally
visible interfaces as static and still work with non-static methods and
properties.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Nenad" wrote in message
...
Thanks, that is exactly what I have asked for.

One final question: As I can see, using this technique, only static
methods
and properties can be invoked on add-in class?