For a long time We had a machine running OL98 and a custom
email reader.  This machine finally "gave up the ghost" several
days ago and I was given the task of re-writing a new, up-to-date
version of this email reader.  No problem.... sort of....

The old reader used CDO ONLY - No references to the OL object
model NOR any CreateObjects - nothing at all in it about Outlook.
The TRICK is - on this old machine, OL98 was installed in IMO mode
which, according to MS knowledge base Question 252720 - Will NOT
work.  But it DID.  and somehow, I can't figure out how the person (who
is no longer with us) set it up to work, without bombing.  (My
version dies with an unhandled exception when shutting down)

The ONLY reason I need to use CDO is to get at the sender's email address
(the reasons for Microsoft deciding we shouldn't be able  to use ol object
model  to do this is beyond me).  SO, I wrote the entire program using CDO
with no
references to OL.  It works fine until it tries to set the session = nothing
then it dies with an unhandled exception (because OL is in IMO mode).  BUT
this
worked on the old machine.  Obviously, there's a way around this IMO/CDO
thing because we did it for several years and it worked ok.

Can someone tell me if there is a workaround for this?  What libraries can I
install or references do I need, to avoid crashing and having to install in
CW mode.
The biggest problem with CW mode is that it is PAINFULLY slow, doesn't send
Internet
email correctly, and really stinks for what we need.

This is a frustrating problem at best.  Any help is greatly appreciated.

David Good
Software Developer
 Top Echelon, Inc.

 www.TopEchelon.com

Outlook IMO is not supported with CDO but most things work just fine
with it. There are exceptions, such as the DeliverNow method (C/W
only), but most things work. Logins are one thing you want to be
careful of. How are you logging into the CDO Session? Are you logging
off the Session before you set it = Nothing?

FWIW, I used to do a lot of CDO programming with Internet only mode
and discovered only a few gotchas.

--
Ken Slovak
[MVP - Outlook]
Lead Author, Professional Outlook 2000 Programming, Wrox Press
Co-author of "Programming Microsoft Outlook 2000", Chapters 8-13,
Appendices, Sams

I logon with
Dim oSession as new Mapi.Session

oSession.Logon ShowDialog:=False
......
After that Everything (cdo) works like a champ
UNTIL

oSession.Logoff
Set oSession = Nothing

Then I get that silly
"Error 123456 - The memory couldn't be read because User32.dll is illiterate
... and kernel32
works but your program doesn't, and make sure to register your copy of
Explorapedia and name your first-born child Bill because he wrote Encarta
and it's cool"
garbage.

| Outlook IMO is not supported with CDO but most things work just fine
| with it. There are exceptions, such as the DeliverNow method (C/W
| only), but most things work. Logins are one thing you want to be
| careful of. How are you logging into the CDO Session? Are you logging
| off the Session before you set it = Nothing?
|
| FWIW, I used to do a lot of CDO programming with Internet only mode
| and discovered only a few gotchas.
|
| --
| Ken Slovak
| [MVP - Outlook]
| Lead Author, Professional Outlook 2000 Programming, Wrox Press
| Co-author of "Programming Microsoft Outlook 2000", Chapters 8-13,
| Appendices, Sams
|


| > For a long time We had a machine running OL98 and a custom
| > email reader.  This machine finally "gave up the ghost" several
| > days ago and I was given the task of re-writing a new, up-to-date
| > version of this email reader.  No problem.... sort of....
| >
| > The old reader used CDO ONLY - No references to the OL object
| > model NOR any CreateObjects - nothing at all in it about Outlook.
| > The TRICK is - on this old machine, OL98 was installed in IMO mode
| > which, according to MS knowledge base Question 252720 - Will NOT
| > work.  But it DID.  and somehow, I can't figure out how the person
| (who
| > is no longer with us) set it up to work, without bombing.  (My
| > version dies with an unhandled exception when shutting down)
| >
| > The ONLY reason I need to use CDO is to get at the sender's email
| address
| > (the reasons for Microsoft deciding we shouldn't be able  to use ol
| object
| > model  to do this is beyond me).  SO, I wrote the entire program
| using CDO
| > with no
| > references to OL.  It works fine until it tries to set the session =
| nothing
| > then it dies with an unhandled exception (because OL is in IMO
| mode).  BUT
| > this
| > worked on the old machine.  Obviously, there's a way around this
| IMO/CDO
| > thing because we did it for several years and it worked ok.
| >
| > Can someone tell me if there is a workaround for this?  What
| libraries can I
| > install or references do I need, to avoid crashing and having to
| install in
| > CW mode.
| > The biggest problem with CW mode is that it is PAINFULLY slow,
| doesn't send
| > Internet
| > email correctly, and really stinks for what we need.
| >
| > This is a frustrating problem at best.  Any help is greatly
| appreciated.
| >
| >
| > David Good
| > Software Developer
| >  Top Echelon, Inc.

| >  www.TopEchelon.com
| >
| >
| >
|
|

Have you tried CreateObject to instantiate the CDO Session instead of
New? Does the profile you are logging into for the CDO session run
under the same permissions as the previous program did?

--
Ken Slovak
[MVP - Outlook]
Lead Author, Professional Outlook 2000 Programming, Wrox Press
Co-author of "Programming Microsoft Outlook 2000", Chapters 8-13,
Appendices, Sams

1.  Yes - same permissions

2. - Since you mentioned it, No, I haven't tried CreateObject
      The old version DID use CreateObject - Personally,
      I hate Late-binding BUT now that you mention it, the old
      version did work and mine doesn't and regarding CDO,
      this is one of the only differences..... I will try that and
      let you know.....

| Have you tried CreateObject to instantiate the CDO Session instead of
| New? Does the profile you are logging into for the CDO session run
| under the same permissions as the previous program did?
|
| --
| Ken Slovak
| [MVP - Outlook]
| Lead Author, Professional Outlook 2000 Programming, Wrox Press
| Co-author of "Programming Microsoft Outlook 2000", Chapters 8-13,
| Appendices, Sams
|


| > I logon with
| > Dim oSession as new Mapi.Session
| >
| > oSession.Logon ShowDialog:=False
| > ......
| > After that Everything (cdo) works like a champ
| > UNTIL
| >
| > oSession.Logoff
| > Set oSession = Nothing
| >
| > Then I get that silly
| > "Error 123456 - The memory couldn't be read because User32.dll is
| illiterate
| > ... and kernel32
| > works but your program doesn't, and make sure to register your copy
| of
| > Explorapedia and name your first-born child Bill because he wrote
| Encarta
| > and it's cool"
| > garbage.
|
|
|

CreateObject isn't really late binding, it just gives you more control
over when your object is created. FWIW, I rarely use New to create
most objects.

I've had some problems when creating CDO Sessions using New when the
Session was running in an ActiveX control too. This app isn't running
under an NT service or anything like that is it?

Let us know if CreateObject made a difference.

--
Ken Slovak
[MVP - Outlook]
Lead Author, Professional Outlook 2000 Programming, Wrox Press
Co-author of "Programming Microsoft Outlook 2000", Chapters 8-13,
Appendices, Sams

Technically - CreateObject IS late-binding.

You see,
    Nearly everything on a Win32 platform uses COM.  In order for COM to
work properly, Every COM object (Like MAPI) is given a GUID - a 128 bit
Globally Unique Identifier, also known as a ClassID or CLSID.

When you make a project reference to the class then use the VB Keyword "New"
you actually compile the CLSID into the obj files and consequently the
compiled
file ( .exe, .dll ).  Using New causes the compiled program to always know
the
CLSID at runtime without any additional registry look-ups.

When you use "CreateObject" you use what is called the ProgID which is
nothing
more than a "friendly name" (string) for the object.  This  ProgID does NOT
associate
with the CLSID and results in a registry look-up at run-time for that
particular object.
The ProgID is a string stored in the Registry that points to a CLSID.  Each
CreateObject
statement results in an extra system for every external object you create.
Caveat:
ProgID's are NOT unique - this makes you vulnerable to naming conflicts - if
2 objects
register themselves using the same "ServerName.ClassName" they each will
then have
the same ProgID BUT point to different CLSID's.

Lastly, "New" requests ONLY the default interface for the class being
created - which
is defined by the TypeLib.  CreateObject on the other hand, requests the
IDispatch
or IUnknown interface and must re-request interfaces with the "Set" keyword.

--Dave

| CreateObject isn't really late binding, it just gives you more control
| over when your object is created. FWIW, I rarely use New to create
| most objects.
|
| I've had some problems when creating CDO Sessions using New when the
| Session was running in an ActiveX control too. This app isn't running
| under an NT service or anything like that is it?
|
| Let us know if CreateObject made a difference.
|
| --
| Ken Slovak
| [MVP - Outlook]
| Lead Author, Professional Outlook 2000 Programming, Wrox Press
| Co-author of "Programming Microsoft Outlook 2000", Chapters 8-13,
| Appendices, Sams
|


| > 1.  Yes - same permissions
| >
| > 2. - Since you mentioned it, No, I haven't tried CreateObject
| >       The old version DID use CreateObject - Personally,
| >       I hate Late-binding BUT now that you mention it, the old
| >       version did work and mine doesn't and regarding CDO,
| >       this is one of the only differences..... I will try that and
| >       let you know.....
|
|
|