Visual Studio Tools for Office: Using C# with Excel, Word, Outlook, and InfoPath [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

جستجو بر اساس ... همه عنوان پدیدآور موضوع یادداشت تمام متن
اصطلاحنامه مجموعه ها مرورالفبایی لغت نامه دهخدا
➟
جستجو در لغت نامه
بیشتر
کتابخانه شخصی پرسش از کتابدار ارسال منبع

Visual Studio Tools for Office: Using C# with Excel, Word, Outlook, and InfoPath [Electronic resources] - نسخه متنی

Eric Carter, Eric Lippert

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
میخواهم بخوانم
درحال خواندن
خوانده شده
ارسال به دوستان

آدرس پست الکترونیک گیرنده :

آدرس پست الکترونیک فرستنده :

نام و نام خانوارگی فرستنده :

پیغام برای گیرنده ( حداکثر 250 حرف ) :

کد امنیتی را وارد نمایید

ارسال
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
➟
جستجو در لغت نامه
بیشتر
لیست موضوعات

Visual Studio Tools for Office: Using C# with Excel, Word, Outlook, and InfoPath
By Eric Carter, Eric Lippert
...............................................
Publisher: Addison Wesley Professional
Pub Date: September 08, 2005
ISBN: 0-321-33488-4
Pages: 1008
Index

توضیحات
افزودن یادداشت جدید






Outlook Issues


This section examines two special issues relating to Outlook development. The first is the Outlook object model security dialog and how to prevent your add-in code from triggering it. The second Outlook-specific issue is a third object model, called Extended MAPI, that can be used in addition to the Outlook object model and the CDO object model. We briefly consider when you might need to resort to using it and how this is typically done.

Outlook Object Model Security


Occasionally as you develop Outlook 2003 add-ins, you might write code that causes the Outlook object model security dialog to display (see Figure 11-11). This dialog was added to prevent the spread of viruses and worms that accessed parts of the Outlook object model such as the address book to spread themselves.

Figure 11-11. The Outlook object model security dialog.

Typically, you want to prevent this dialog from coming up because it can distress your users. When you understand why this dialog appears, you can refactor your code to avoid this dialog. If you write a COM add-in, you are passed an Application object to the OnConnection method of IDTExtensibility2. If you write a VSTO add-in, you can access the methods and properties of Outlook's application object through the base class of the ThisApplication class. The Application object passed to OnConnection and the base class of VSTO's ThisApplication class are trusted in Outlook 2003as long as you obtain all other objects you use from these trusted objects, you never have to worry about the object model security dialog.

If you create a new instance of the Application object, this new instance will not be trusted, and the objects you create or access from it will sometimes cause the Outlook object model security dialog to appear. Also, the objects passed into your event handlers as parameters are not trusted objects, and accessing restricted methods and properties on these objects can cause the Outlook object model security dialog to appear. If you trigger the Outlook object model security dialog by using these objects, you should find a way to get the same object through your trusted Application object.WordEditor

ItemProperties

Any access of a restricted property associated with an Outlook item

JournalItem

Body

ContactNames

SaveAs()

MailItem

Bcc

Body

Cc

HTLMBody

ReceivedByName

ReceivedOnBehalfOfName

ReplyRecipientNames

SaveAs()

Send()

SenderEmailAddress

SenderEmailType

SenderName

SentOnBehalfOfName

To

MeetingItem

Body

SaveAs()

SenderName

NameSpace

CurrentUser

GetRecipientFromID

PostItem

Body

<203Body

SaveAs()

SenderName

Recipient

All properties and methods.

Recipients

All properties and methods.

TaskItem

Body

ContactNames

Contacts

Delegator

Owner

SaveAs()

Send()

StatusUpdateRecipients

StatusOnCompletionRecipients

UserProperties

Find()

UserProperty

Formula

Listing 11-31 illustrates a COM add-in that uses a trusted and an untrusted Application object. The first block of code gets a MailItem out of the Inbox using the Application object passed to OnConnection, which we have set to a class member variable called trustedApplication. It then tries to access the MailItem object's Body property (which is a restricted property) on the object obtained via the trustedApplication object. This action will not cause the object model security dialog to appear. The second block of code uses an Application object we have created using the new keyword. This Application object is not trusted, and the Outlook item we obtain via this untrustedApplication variable causes the object model security dialog to appear when we access the restricted Body property.

Listing 11-31. A COM Add-In That Accesses a MailItem's Body Property Through a Trusted Application Object and Through an Untrusted Application Object


public void OnConnection(object application, 
Extensibility.ext_ConnectMode connectMode, 
object addInInst, 
ref System.Array custom)
{
trustedApplication = application as Outlook.Application;
untrustedApplication = new Outlook.Application();
// Using trusted application
Outlook.MAPIFolder inbox = trustedApplication.Session.
GetDefaultFolder(Outlook.OlDefaultFolders.olFolderInbox);
Outlook.MailItem mailItem = inbox.Items[1] as Outlook.MailItem;
if (mailItem != null)
MessageBox.Show(mailItem.Body);
// Using untrusted application causes dialog to appear
Outlook.MAPIFolder inbox2 = untrustedApplication.Session.
GetDefaultFolder(Outlook.OlDefaultFolders.olFolderInbox);
Outlook.MailItem mailItem2 = inbox2.Items[1] as Outlook.MailItem;
if (mailItem2 != null)
MessageBox.Show(mailItem2.Body);
}

Listing 11-32 shows a VSTO add-in that has a similar problem because it tries to access a restricted property on an Outlook item passed into an event handler as a parameter. As mentioned earlier, parameters passed into event handlers are untrusted, and accessing properties on these parameters that are restricted causes the Outlook object model security dialog to appear.

Listing 11-32. A VSTO Add-In That Tries to Access the Body Property of a MailItem Obtained from an Untrusted Event Parameter


private void ThisApplication_Startup(object sender, EventArgs e)
{
this.ItemSend += new 
Outlook.ApplicationEvents_11_ItemSendEventHandler(
ThisApplication_ItemSend);
}
void ThisApplication_ItemSend(object Item, ref bool Cancel)
{
Outlook.MailItem untrustedMailItem = Item as 
Outlook.MailItem;
if (untrustedMailItem != null)
{
MessageBox.Show(String.Format(
"Untrusted body {0}", untrustedMailItem.Body));
}
}

If you are developing for a version of Outlook older than 2003, the Application object provided to an add-in is not trusted by default. Also, some installations of Outlook 2003 are configured to not trust any COM or VSTO add-ins by default. For these cases, you have to use the Outlook security administration tools, which rely on a public exchange folder and a form template (Outlooksecurit.oft) that can be installed and configured to provide specific add-ins with a trusted Application object. For VSTO Add-ins, you need to use the Outlook security administration tools to trust the AddinLoader.dll component that loads all VSTO add-ins. You also need to deploy appropriate .NET security policy as described in Chapter 19.

Extended MAPI


Occasionally, you will find a property in the Outlook object model that you really want to change but is read-only. Sometimes it is possible to change these properties using another API set called Extended MAPI. Extended MAPI is a C++-oriented API that talks directly to the MAPI store that backs Outlook folders and items. The way .NET developers typically use Extended MAPI is by creating an assembly written in managed C++. Your existing managed code can then call the managed C++ assembly, which can then call into Extended MAPI. This is an advanced scenario that is not covered further in this book.

/ 213