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.

--
http://www.standards.com/; See Howard Kaikow's web site.

No, Outlook doesn't support that.
--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx


"Howard Kaikow" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
> 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.
>
> --
> http://www.standards.com/; See Howard Kaikow's web site.
>
>

"Sue Mosher [MVP-Outlook]" <(E-Mail Removed)> wrote in message
news:OU$(E-Mail Removed)...
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.

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

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx


"Howard Kaikow" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
> "Sue Mosher [MVP-Outlook]" <(E-Mail Removed)> wrote in message
> news:OU$(E-Mail Removed)...
> 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]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
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.

"Sue Mosher [MVP-Outlook]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
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?

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
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx


"Howard Kaikow" <(E-Mail Removed)> wrote in message news:urezM%(E-Mail Removed)...
> "Sue Mosher [MVP-Outlook]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> 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]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
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.

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
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx


"Howard Kaikow" <(E-Mail Removed)> wrote in message news:(E-Mail Removed)...
>
> 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]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

>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