Jump to content

Outlook


Recommended Posts

This code reads the default folder [inbox] and triggers the Message when it encounters an email from the nominated sender [$sSender]. However for it to run you are required to respond to a Windows [Vista] MessageBox requesting that you give the script [up to 10 minutes] access to Email Addresses.

What I want to achieve is that the script runs without triggering the Windows Vista request for access. This is the script which runs provided you respond appropriately to the Windows Vista Access message:

CODE
#include <IE.au3>

Global Const $olFolderInbox = 6

$sSender = "99999@vodafone.net.au"

_IEErrorHandlerRegister()

$o_Outlook = ObjCreate("Outlook.Application")

$oNameSpace = $o_Outlook.GetNameSpace("MAPI")

$oInbox = $oNameSpace.GetDefaultFolder($olFolderInbox)

$oFolders = $oInbox.Parent.Folders

While 1

$oItems = $oInbox.Items

For $oItem In $oItems

If String($oItem.SenderEmailAddress) = $sSender Then

msgbox(0,"","New Email Found " & $oItem.Subject,2)

exitloop(2)

EndIf

Next

Sleep(2000)

WEnd

This is the the VB code for the "RequestAccessEmail Property" as published by Microsoft. Can this code be converted to AutoIT and will it allow the script to run without triggering the Vista requested for access messagebox?

CODE
Dim site As SPWeb = SPContext.Current.Web

Dim permsSite As SPPermissionCollection = site.Permissions

permsSite.RequestAccessEmail = "Email_Address"

Dim lists As SPListCollection = site.Lists

Dim permsList As SPPermissionCollection =

lists("List_Title").Permissions

permsList.RequestAccess = False

Help is always appreciated Ant.. :P

Link to comment
Share on other sites

The access permission messagebox isn't Vista specific but rather Outlook specific: it is from the "Outlook Object Model Guard".

According to MSDN, the permsList.RequestAccess property is for controlling acces requests to a SharePoint portal site

( http://msdn.microsoft.com/en-us/library/mi...uestaccess.aspx )

It doesn't look like there is a simple way around the problem. More info here:

http://www.outlookcode.com/article.aspx?ID=52

Note: one company listed at the bottom of that page is selling an ActiveX object to disable the guard for $149 USD!!!

Edited by ResNullius
Link to comment
Share on other sites

The access permission messagebox isn't Vista specific but rather Outlook specific: it is from the "Outlook Object Model Guard".

According to MSDN, the permsList.RequestAccess property is for controlling acces requests to a SharePoint portal site

( http://msdn.microsoft.com/en-us/library/mi...uestaccess.aspx )

It doesn't look like there is a simple way around the problem. More info here:

http://www.outlookcode.com/article.aspx?ID=52

Note: one company listed at the bottom of that page is selling an ActiveX object to disable the guard for $149 USD!!!

[/quot

Thanks for the information much appreciated.. Ant..

Link to comment
Share on other sites

Thanks for the information much appreciated.. Ant..

More info on the MSDN in this article: http://msdn.microsoft.com/en-us/library/aa168454.aspx under the heading Revised and Improved Security Model (about 1/4 way down the page).

I tried adapting the "trusted code example" but I don't think the secure "Application" object they talk about is available through the regular COM interface; only through Outlook VBA or an Outlook Add-in :P

Link to comment
Share on other sites

If your script is for use only on your computer or ones you manage, you could download & install this add-in: http://www.mapilab.com/outlook/security

It allows for remembering your choice of whether to allow access. Free for personal & commercial use!

Edit: Another advantage to this method is that it appears to mark the system dll that gets called so any new scripts you create will also run without prompts!

Edited by ResNullius
Link to comment
Share on other sites

If your script is for use only on your computer or ones you manage, you could download & install this add-in: http://www.mapilab.com/outlook/security

It allows for remembering your choice of whether to allow access. Free for personal & commercial use!

Edit: Another advantage to this method is that it appears to mark the system dll that gets called so any new scripts you create will also run without prompts!

Thanks for the information. I guess this is the VB code that you were referring to. What I have learnt is that not all attributes of an email trigger a Object Model Guard Warning dialog box. For example $oItem.SenderEmailAddress triggers the dialog box whereas $oItem.Subject does not.

CODE
Sub TrustedCode()

Dim olApp As Outlook.Application

Set olApp = Application

Dim oMail As Outlook.MailItem

Set oMail = _

olApp.Session.GetDefaultFolder(olFolderInbox).Items(1)

MsgBox oMail.SenderEmailAddress, vbInformation

End Sub

What I was wanting to build was a trigger to start and stop another process. It was attractive to make an email as what acuated the trigger which could have been an exclusive sender as well as subject. The code would then periodically look at the nominated inbox and look for a text match of the subject which would either turn the process on or off as the case may be. Given that most mobile phones these days have an email capability and the iPhone is supported by MobileMe world wide remote control appeared to be quite easy to achieve.

Given that I can make the subject exclusive then I guess from a trigger point of view it really does not matter as to the name of the sender to actually build a trigger. I guess in review two attributes to acuate the trigger was always going to be better than one. The sender name giving that added level of security however the likely hood of someone actually matching a email subject is probably to small to contenplate. Given that I have control of the code I could shift the trigger value on a regular basis to avoid conflicts should someone else learn the value and decide to send emails to switch the process off when it should be running.

I will also have a look at your suggest downoload but I guess it was always going to be better to have the solution contained within your own process.

Ant.. :P

Link to comment
Share on other sites

If your script is for use only on your computer or ones you manage, you could download & install this add-in: http://www.mapilab.com/outlook/security

It allows for remembering your choice of whether to allow access. Free for personal & commercial use!

Edit: Another advantage to this method is that it appears to mark the system dll that gets called so any new scripts you create will also run without prompts!

I downloaded the software from MAPILab and as you predicted it overcame the issue with the Outlook Object Security. After thinking about it the better solution would still be one entirely contained within the AutoIT script. I guess there are many reasons for this view including quality control, not relient on a third party and the list goes on. On reading the MSN documentation I came to the conclusion that in Office 2007 the user has better control over this type of security in any case and in the absence of that software I am not sure what are the likely issues. My guess is that there are probably many AutoIT users that would be interested in a elegant solution in respect to email management. Given the wealth of experience that users have demonstrated from time to time my guess is that there is probably someone out there that can put their finger on an AutoIT solution. In the meantime I am going to simply base my trigger on the Subject which does not require the MAPILab software. I will post a copy of the function when it has been finished and tested. Ant.. :P

Link to comment
Share on other sites

I downloaded the software from MAPILab and as you predicted it overcame the issue with the Outlook Object Security. After thinking about it the better solution would still be one entirely contained within the AutoIT script. I guess there are many reasons for this view including quality control, not relient on a third party and the list goes on. On reading the MSN documentation I came to the conclusion that in Office 2007 the user has better control over this type of security in any case and in the absence of that software I am not sure what are the likely issues. My guess is that there are probably many AutoIT users that would be interested in a elegant solution in respect to email management. Given the wealth of experience that users have demonstrated from time to time my guess is that there is probably someone out there that can put their finger on an AutoIT solution. In the meantime I am going to simply base my trigger on the Subject which does not require the MAPILab software. I will post a copy of the function when it has been finished and tested. Ant.. :P

I look forward to seeing it.

By the way, apparently you can access the message stores on an Exchange server and not trigger the warnings.

Of course, that assumes you're running an Exchange server in house for your email.

Link to comment
Share on other sites

I look forward to seeing it.

By the way, apparently you can access the message stores on an Exchange server and not trigger the warnings.

Of course, that assumes you're running an Exchange server in house for your email.

A Exchange Server [no such luck or more to the point no need]. I found this a useful resource http://msdn.microsoft.com/en-us/library/aa...office.11).aspx which is pretty much everything you need to know about programming for Outlook 2003 [and was afraid to ask]. Ant.. :P
Link to comment
Share on other sites

A Exchange Server [no such luck or more to the point no need]. I found this a useful resource http://msdn.microsoft.com/en-us/library/aa...office.11).aspx which is pretty much everything you need to know about programming for Outlook 2003 [and was afraid to ask]. Ant.. :P

Subscribers should note that this code requires the MAPILab Outlook Security Software [run as an Outlook Com Add- In]to be Pre-Installed.

CODE

#include <IE.au3>

#Include <Date.au3>

;//sSEmailTest INI File

Const $DirEmail = @ScriptDir & "\sSTest.ini"

;//Global Variables

Global $olFolderInbox = 6, $sSender = "anyone@anywhere.net.au", $sSubjectSTOP = "sSENTRY STOP", $sSubjectSTART = "sSENTRY START", _

$sSTime, $sSFlag

;//Call the Email Start Stop Switch Routine

While 1

_CheckEmailForTrigger()

Msgbox(0,"Test","Just Checked the Inbox",1)

Sleep(2000)

WEnd

;//Check Email for Unique Start/Stop Email

Func _CheckEmailForTrigger()

;//Create the Outlook Object

$o_Outlook = ObjCreate("Outlook.Application")

$oNameSpace = $o_Outlook.GetNameSpace("MAPI")

$oInbox = $oNameSpace.GetDefaultFolder($olFolderInbox)

$oFolders = $oInbox.Parent.Folders

;Check the Default Inbox

While 1

$oItems = $oInbox.Items

For $oItem In $oItems

;//Check for Unique Sender ID

If String($oItem.SenderEmailAddress) = $sSender Then

;Read the Status of the flag On = 1 Off = 0

$sSFlag = StringLeft(IniRead($DirEmail,"s_Switch","Value",""),1)

;Read the Email Subject Line for a Start/Stop Trigger

If String($oItem.Subject) = $sSubjectSTOP And $sSFlag = 1 Then

;//Write the INI File Comma Separate On [1] Off [0] Flag and the DateTime [for record purposes]

IniWrite($DirEmail,"s_Switch","Value",0 & "," & $oItem.ReceivedTime)

ElseIf String($oItem.Subject) = $sSubjectSTART And $sSFlag = 0 Then

IniWrite($DirEmail,"s_Switch","Value",1 & "," & $oItem.ReceivedTime)

EndIf

Msgbox(0,"Test", "Trigger Processed",1)

;//Delete the Email Trigger so that it is not reprocessed;

$oItem.Delete

;//Exit the For/Next and While/WEnd Loops

Exitloop(2)

EndIf

Next

;//Exit Loop If No $sSender is a Match

ExitLoop

WEnd

;//Return to Calling Routine

EndFunc

Ant.. :P
Link to comment
Share on other sites

I have modified the posted code to take into account that the processing should be performed on the email which has the most recent sent time rather than the received time. There is an assumption that two emails sent at or near the same time one to 'Stop" and one to "Start" a process will be delivered to the recipient in the order in which they were sent and as a consequence the order in which they are subsequently processed. Dependant upon how often Sent/Receive is processed by the Outlook Client it is possible that both Emails could arrive at or about the same time. It is therefore necessary to ensure that the email which has precedence is the last processed. The following code seeks to achieve that outcome. Ant.. :P

CODE
#include <IE.au3>

#Include <Date.au3>

;//sSEmailTest INI File

Const $DirEmail = @ScriptDir & "\sSTest.ini"

;//Global Variables

Global $olFolderInbox = 6, $sSender = "anyone@anywhere.net.au", $sSubjectSTOP = "sSENTRY STOP", $sSubjectSTART = "sSENTRY START"

;//Call the Email Start Stop Switch Routine

While 1

_CheckEmailForTrigger()

Msgbox(0,"Test","Just Checked the Inbox",1)

Sleep(2000)

WEnd

;//Check Email for Unique Start/Stop Email

Func _CheckEmailForTrigger()

;//Create the Outlook Object

$o_Outlook = ObjCreate("Outlook.Application")

$oNameSpace = $o_Outlook.GetNameSpace("MAPI")

$oInbox = $oNameSpace.GetDefaultFolder($olFolderInbox)

$oFolders = $oInbox.Parent.Folders

;Check the Default Inbox

While 1

$oItems = $oInbox.Items

For $oItem In $oItems

;//Process only Unique Sender and Trigger ID's

If String($oItem.SenderEmailAddress) = $sSender And StringLeft($oItem.Subject, 7) = "sSentry" Then

;//Format the Inbox Email Date and Time Sent to yyyy/mm/dd hh:mm:ss

$SentOn = StringLeft($oItem.SentOn,4) & "/" & StringMid($oItem.SentOn,5,2) & "/" & StringMid($oItem.SentOn,7,2) & " " & _

StringMid($oItem.SentOn,9,2) & ":" & StringMid($oItem.SentOn,11,2) & ":" & StringMid($oItem.SentOn,13,2)

;//Read the Date of the Last Processed Start/Stop Email

$LastSentOn = StringRight(IniRead($DirEmail,"s_Switch","Value",""),StringLen(IniRead($DirEmail,"s_Switch","Value",""))-2)

;//If No LastSentOn Set a Default Date

If $LastSentOn = "" Then $LastSentOn = "1970/01/01 00:01:01"

;//Calculate a Sent Date Time Difference and Process only the Last Sent Email

If _DateDiff('s', $LastSentOn, $SentOn) > 0 Then

;//Read the Email Subject Line for the Start/Stop Trigger and Write the INI File with [1] ON or [0] OFF and Formated Sent Date Time

If $oItem.Subject = $sSubjectSTOP Then

IniWrite($DirEmail,"s_Switch","Value",0 & "," & $SentOn)

EndIf

If $oItem.Subject = $sSubjectSTART Then

IniWrite($DirEmail,"s_Switch","Value",1 & "," & $SentOn)

EndIf

EndIf

;//Delete the Email Trigger so that it is Not Re-Reprocessed;

$oItem.Delete

EndIf

Next

;Exit the Loop after Mailbox Processing has Completed

ExitLoop

WEnd

;//Return to Calling Routine

EndFunc

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...