I generated the COM interfaces for (Microsoft Outlook) msoutl9.olb
with the ActiveX Component Wizard with class prefix Outlook. My problem arises when trying to access Microsoft Outlook on a remote machine using the following code. outlook := Outlook_Application onCLSID: Outlook_Application clsid hostName: 'DELL'. outlook session currentUser answers - "an OutlookRecipient('Scott Dumonceaux')" outlook := Outlook_Application onCLSID: Outlook_Application clsid hostName: 'MIC'. outlook session currentUser answers - "an OutlookRecipient('Scott Dumonceaux')" 'Dell' is my machine and should answer "an OutlookRecipient('Scott Dumonceaux')" but 'MIC' is my girlfriends machine and should not answer that. I get no error message connecting to the other machine, so it looks like it successfully connected to the remote machine, but the data indicates that it is only connecting to the local machine. (I have also checked other data like emails and contacts) I would appreciated any help on how to connect OutLook on a remote machine. Thanks, Scott |
Scott,
> outlook := Outlook_Application onCLSID: Outlook_Application clsid > hostName: 'MIC'. > outlook session currentUser > answers - "an OutlookRecipient('Scott Dumonceaux')" > > 'Dell' is my machine and should answer "an OutlookRecipient('Scott > Dumonceaux')" > but 'MIC' is my girlfriends machine and should not answer that. > > I get no error message connecting to the other machine, so it looks > like it successfully connected to the remote machine, but the data > indicates that it is only connecting to the local machine. (I have > also checked other data like emails and contacts) You're venturing into DCOM, which is (asking for strength here<g>) marginal technology at best. Even if you do get it working, it's unlikely to be reliable because the error handling is (asking for even more strength<g>) apparently based on the idea that machines never crash, never get turned off, never reboot while a peer thinks it's still connected, networks never fail, etc. I've worked with at least three CORBA ORBs, and all of them put DCOM to shame in their ability to recognize that the other side wasn't cooking on all burners. Depending on the OS, you might need to make some changes to enable DCOM or arrange for sufficient privileges on the right account for OE to run. Also, crossing between 9x and NT and then back can cause problems because of the different approaches to security. In the end, you'll probably do better to do the networking yourself via sockets between two Dolphin apps, one of which runs OE locally. > I would appreciated any help on how to connect OutLook on a remote > machine. If you do make it work, please tell us - given the number of security holes in OE, if it can be launched "for me" then I'll uninstall it from every machine I own/control :) Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
In reply to this post by Scott
"Scott" <[hidden email]> wrote in message
news:[hidden email]... > I generated the COM interfaces for (Microsoft Outlook) msoutl9.olb > with the ActiveX Component Wizard with class prefix Outlook. > > My problem arises when trying to access Microsoft Outlook on a remote > machine using the following code. ...[snip demonstration of getting local object]... > > I get no error message connecting to the other machine, so it looks > like it successfully connected to the remote machine, but the data > indicates that it is only connecting to the local machine. (I have > also checked other data like emails and contacts) As a consequence of the way Dolphin creates objects, even when a hostname is specified a local implementation of the object will take precedence. I think this is probably a bug in COMInterface>>onCLSID:outerIUnknown:hostName:licenseKey:, from which one can see that if a hostname is specified then the creation context flag CLSCTX_REMOTE_SERVER is #bitOr:'d in with the default creation context flags (which includes the flags for in-proc and local servers) rather than replacing the default flags entirely. As a result if there is a local version of the component available, then it will be used in preference. To "fix" this replace the line: dwClsContext := dwClsContext bitOr: CLSCTX_REMOTE_SERVER]. with: dwClsContext := CLSCTX_REMOTE_SERVER]. You may find that after doing this that you get an error when attempting to create the remote object, in which case you are in the realms of DCOM configuration (Start/Run... "DCOMCNFG"). Frankly I've no idea how all this is set up now in these days of COM+ and "component services", so perhaps someone else more knowledgeable could chip in. Regards Blair |
Free forum by Nabble | Edit this page |