Interfacing with MS Outlook using ActiveX Automation

For questions and postings not covered by the other forums
ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Interfacing with MS Outlook using ActiveX Automation

Postby ConvertFromOldNGs » Fri Aug 07, 2009 1:07 pm

by BeeJay >> Thu, 15 Mar 2007 3:04:59 GMT

Has anyone had any prior experience with importing MS Outlook as an automation object in Jade and has any tips to share?

Cheers,
BeeJay.

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Interfacing with MS Outlook using ActiveX Automation

Postby ConvertFromOldNGs » Fri Aug 07, 2009 1:07 pm

by Torrie >> Thu, 15 Mar 2007 4:46:04 GMT

We've added it, just to get a list of email addresses. We use the mail functions in CardSchema to send email. With the addresses you can get both groups and individuals coming through so you do need to check whether it is a group or not. However the user does get the Outlook pop up warnings when you access the address book.

We also import all active libraries into a separate schema as the active X schemas tend to be large and static. Thus when you do an update, you won't need to load this schema each time as it doesn't change much.

We also have interfaces with MS Word and Publisher. If you are running thin clients, we find it is best to code the active x automation in a DLL as you can wrap up a number of active X calls into one external function from Jade. There is far less thin client traffic this way. Otherwise each call to the active X server (e.g. Word) is a thin client round trip. You don't bloat your schemas this way
We use Delphi for this (and create external function calls in Jade to the dll produced) You can also do this with VB but you then get another active X library. Care is needed if you use VB and an active X libraries as only one version can be active on a machine at once which can make testing new versions a little tricky if running a live and test system on the same machine.

Torrie

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Interfacing with MS Outlook using ActiveX Automation

Postby ConvertFromOldNGs » Fri Aug 07, 2009 1:07 pm

by BeeJay >> Thu, 15 Mar 2007 22:06:00 GMT

Thanks for your thought's Torrie. Unfortunately using VB or Delphi to create a wrapper DLL is probably not an option. I was also planning to create a package schema to prevent the main schema getting polluted with classes and to allow this to be used in other applications as well. I already use the CnSmtp classes to send e-mails. This requirement is to get the text out of e-mails for keywording purposes when .msg files are loaded into the system so it should hopefully be less thin client traffic intensive.

Cheers,
BeeJay

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Interfacing with MS Outlook using ActiveX Automation

Postby ConvertFromOldNGs » Fri Aug 07, 2009 1:07 pm

by John Munro >> Fri, 23 Mar 2007 19:55:53 GMT

We use VB ActiveX dll wrappers for things like this because the Office dll's have different names for different versions.

To support all versions of Office you'd need to install each one and import that version of the dll's into Jade.

With the VB dll you can get around this using something like this:

Dim app As Object
Set app = GetObject(, "Word.Application")

If app Is Nothing Then
Set app = CreateObject("Word.Application")
End If

which works for any version of the dll's

ConvertFromOldNGs
Posts: 5321
Joined: Wed Aug 05, 2009 5:19 pm

Re: Interfacing with MS Outlook using ActiveX Automation

Postby ConvertFromOldNGs » Fri Aug 07, 2009 1:07 pm

by jcampbell >> Mon, 26 Mar 2007 4:30:19 GMT

Other thing to note is issues doing this server-side when running Jade as a service
See http://support.microsoft.com/kb/257757

which basically says
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when run in this environment.

and
Besides the technical problems, you must also consider the feasibility of such a design with respect to licensing. Current licensing guidelines prevent Office Applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA).


So if you intend using Office Automation you need to consider these aspects and preferably launch any of this stuff on the client rather than the server so that you don't hit any of the possible issues etc. Whilst it is often possible to get this stuff working with some of the configuration suggestions associated with this article there is no guarantee and hotfixes etc could easily impact on/break things.


Return to “General Discussion”

Who is online

Users browsing this forum: No registered users and 3 guests