Will Outlook allow programmatic modification of vbaproject.otm?

[Howard Kaikow]

With Word, Excel, etc, I can programmatically add code to a project and add
a reference to any required libraries.
Should be able to use just about the same code for Outlook/

Will Outlook allow me to do this?

Seems easier to do this than to ask users to manually modify the project.

 

[Sue Mosher [MVP-Outlook]]

No, Outlook doesn't support that.
--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Howard Kaikow]

No, Outlook doesn't support that.

Thanx.

So, the alternative is to use a COM add-in or supply instructuctions to
manually modify the OTM.

 

[Sue Mosher [MVP-Outlook]]

Exactly. An add-in would, of course, be preferable.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Howard Kaikow]

Exactly. An add-in would, of course, be preferable.

COM add-in would be overkill, but since the weak Outlook object model does
not expose VB projects, I've got little choice.

 

[Howard Kaikow]

Exactly. An add-in would, of course, be preferable.

Using a COM add-in, can I provide code that can run from a rule, such as
the example you give on pages 67-68 of your MSFT Outlook Programming book?

 

[Sue Mosher [MVP-Outlook]]

No, the "run a script" rule action works only with VBA code. Instead, you'd build your add-in to work with the NewMailEx, NewMail, or MAPIFolder.Items.Add event.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Howard Kaikow]

No, the "run a script" rule action works only with VBA code. Instead, you'd
build your add-in to work with the NewMailEx, NewMail, or
MAPIFolder.Items.Add event.

I'm after the equivalent of "run a script" so I would not want the code to
run automatically.
The code should be able to run anywhere within the set of rules defined by
the user, otherwise the order of filtering may not be that desired by the
user.

What about including a stub in the VBA that invokes a procedure in the COM
DLL?
The "run a script" could then refer to the stub.

 

[Sue Mosher [MVP-Outlook]]

That might be a great solution. You'd still have the manual VBA installation issue, but with a lot less code to replace if vbaproject.otm corrupts (as it has been known to do).

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Howard Kaikow]

That might be a great solution. You'd still have the manual VBA

installation issue, but with a lot less code to replace >if vbaproject.otm
corrupts (as it has been known to do).

That's my standard solution using a normal VB 6 ActiveX DLL.

With Word, Excel, etc., I use a setup program that actually creates the code
and adds the reference in the template/workbook. Alas, since the Outloook
object model does not expose the VBProject, there's a silly, unnecessary
roadblock to proper setup programs with Outlook.



With an ActiveX DLL, I can use a setup program to register the critter, but
the user will have to manually insert a reference in the VBAProject.otm..



With a COM add-in, I guess the effective difference is that the user won't
have to include a reference to the DLL, but will still have to manually
insert the stubs.



ThisOutlookSession would require code like


Private Sub Application_ItemSend(ByVal Item As Object, Cancel As Boolean)
EFItemSend Item
End Sub



Private Sub Application_Quit()
TerminateMyMailFilters 2
End Sub



Private Sub Application_Startup()
SetupMyMailFilters 1
End Sub



And there would need to be a standard module in vbaproject.otm like the code
below.



I can make the module an importable .bas file, but the ThisOutlookSession
stuff would have to be entered manually, as well as the reference to the
DLL.



Why in the world was the Outlook object model so crippled? Makes no sense?



Public EF As clsMyMailFilters



Public Sub MyIncomingFilters(objMsg As Outlook.MailItem)
' SetupClass
EF.ProcessIncomingFilters objMsg
End Sub



Public Sub SetupMyMailFilters(lngDummy As Long)
' SetupClass
Set EF = New clsMyMailFilters
EF.ReadMyMailFilterFile
End Sub



Public Sub TerminateMyMailFilters(lngDummy As Long)
Set EF = Nothing
End Sub



Public Sub EFItemSend(ByVal Item As Object)
If TypeName(Item) = "MailItem" Then
With Item

' Code to be determined
'Debug.Print "Outgoing:" & vbCrLf _
& "SenderEmailAddress:" & .SenderEmailAddress & vbCrLf _
& "SenderName:" & .SenderName & vbCrLf _
& "Subject:" & .Subject & vbCrLf _
& "To:" & .To & vbCrLf _
& "Cc:" & .CC & vbCrLf _
& "Importance:" & .Importance & vbCrLf _
& "Bcc:" & .BCC & vbCrLf _
& "Body: " & vbCrLf _
& .Body
End With
End If
End Sub

 

[Sue Mosher [MVP-Outlook]]

Security, no doubt.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003

and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Howard Kaikow]

Security, no doubt.

I don't buy that.

The ability to program filters is missing from the object model, yet you can
semi-hack around this using the run as script.

Proper filtering requires vetting ALL headers. The Outlook Guard message
about accessing the address book is bogus if all I am trying to do is get
the headers.