如何在 ThisAddIn 类之外访问 VSTO Outlook 加载项中的应用程序属性?

发布于 2024-08-19 16:10:22 字数 1368 浏览 4 评论 0原文

使用新的 Outlook VSTO C# 项目创建的此AddIn 类具有一个 Application 属性,您可以使用该属性来访问 Outlook 文件夹和项目。问题是,当您在 ThisAddIn 类内部时,您可以轻松地使用它,但从项目中的其他类无法轻松访问它。这是因为它是一个实例属性。

我想找到访问此属性在其他类中提供的相同功能的最佳方法,因此我提出了两种可能的解决方案,但我不知道其中哪一个(如果有)是好的。

假设我想获取默认收件箱文件夹。在 ThisAddIn 类中,我会简单地执行以下操作:

this.Application.Session.GetDefaultFolder(Outlook.olFolderInbox);

现在如何在该类之外执行相同的操作?

1. 静态属性

首先,我可以向 ThisAddIn 类添加一个静态属性,并将其设置为我想要在其他类中公开的值。

public partial class ThisAddIn
{
    public Outlook.Application OutlookApp;

    void ThisAddIn_Startup(object sender, EventArgs e)
    {
        // init static variable value here
        OutlookApp = this.Application

        // initialize the rest of addin here
    }

    void InternalStartup()
    {
        this.Startup += this.ThisAddIn_Startup;
    }
}

这样,在我的任何其他类中,我可以执行以下操作:

ThisAddIn.OutlookApp.Session.GetDefaultFolder(Outlook.olFolderInbox);

2. 创建新的应用程序对象

我可以做的第二件事是在使用其他类中的应用程序对象之前对其进行初始化。但我不确定创建该类型的新对象是否不会创建 Outlook 的新实例。

class MyOtherClass
{
    public void MyMethod()
    {
        var app = new Outlook.Application();
        var folder = app.Session.GetDefaultFolder(Outlook.olFolderInbox);
    }
}

有没有人对哪种方法更好有任何建议,或者如果您对这个问题有不同的解决方案,我也会很感激。

ThisAddIn class created with new Outlook VSTO C# project has a Application property that you can use to among other things get access to Outlook folders and items. The problem is that you can easily use it when you're inside of ThisAddIn class but there's no easy access to it from other classes in the project. This is because it's an instance property.

I want to find the best way of having access to the same functionality this property provides in my other classes so I come up with two possible solutions but I don't know which one (if any) of them is good.

Lets assume I want to get default inbox folder. Inside ThisAddIn class I would simply do something like this:

this.Application.Session.GetDefaultFolder(Outlook.olFolderInbox);

Now how to do the same outside this class?

1. Static property

First, I could add a static property to ThisAddIn class and set it to the value I want to expose in other classes.

public partial class ThisAddIn
{
    public Outlook.Application OutlookApp;

    void ThisAddIn_Startup(object sender, EventArgs e)
    {
        // init static variable value here
        OutlookApp = this.Application

        // initialize the rest of addin here
    }

    void InternalStartup()
    {
        this.Startup += this.ThisAddIn_Startup;
    }
}

This way in any of my other classes I could do something like this:

ThisAddIn.OutlookApp.Session.GetDefaultFolder(Outlook.olFolderInbox);

2. Create new Application object

Second thing that I could do is to init Application object in my other class before I use it. But I'm not sure if creating new object of that type doesn't create a new instance of Outlook.

class MyOtherClass
{
    public void MyMethod()
    {
        var app = new Outlook.Application();
        var folder = app.Session.GetDefaultFolder(Outlook.olFolderInbox);
    }
}

Does anyone have any suggestions which approach is better, of if you have different solutions for this problem I'd apprieciate that as well.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

┼── 2024-08-26 16:10:23

将静态变量放置在 ThisAddIn 中以便从代码中引用实际上是一种不好的做法。

根据这个答案https://stackoverflow.com/a/46493968/2068626,Outlook应用程序对象是一个单例,所以最好执行您自己的第二个建议

var app = new Outlook.Application();

由于这是一个 Outlook VSTO 加载项,因此启动 Outlook 的风险为零,因为根据定义它将会运行。如果您在另一个 Office 应用程序中使用此方法,则仅当 Outlook 当前未运行时才启动 Outlook。

为了完整起见,所有其他共享模型都应该使用依赖注入的形式,这样您的代码中就不存在强耦合。

使用这两种方法,您还可以更轻松(可能)地将代码和其他类重构到单独的库中,以便更轻松地在 VSTO 项目甚至 Nuget 包中重用。

It is actually bad practice to place static variables in the ThisAddIn in order to reference from around your code.

According to this answer https://stackoverflow.com/a/46493968/2068626, the Outlook Application object is a singleton so it would be preferred to do your own second suggestion

var app = new Outlook.Application();

Since this is a Outlook VSTO add-in there is zero risk of starting Outlook since it by definition will be running. If you use this method from within another Office application you would start Outlook only if Outlook is not currently running.

For completeness sake, all other shared models should use a form of Dependency Injection so there is no strong coupling in your code.

Using these two approaches it would also be easier (possible) for you to refactor your code and other classes out into a separate library for easier reuse across your VSTO projects or even a Nuget Package.

So要识趣 2024-08-26 16:10:22

由于您可以拥有 ThisAddIn 的单个实例,因此您可以拥有一个静态变量来访问外部的应用程序表单...仅供参考,当您添加 Outlook-AddIn VSTO 项目时,ThisAddIn 的实例将作为静态类 Globals 中的静态成员提供。 EM>

Since you can have single Instance of ThisAddIn you can have a static variable to access Application form outside... FYI when you add Outlook-AddIn VSTO project,instance of ThisAddIn will be available as static member in static class Globals

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文