I have generally found that the Catastrophic exceptions seem to be 90% of the time
caused by references to nil pointers/objects/interfaces. Usually this occurs in the
Contructors/Destructors, especially if you reference other objects - have to watch
object counting if you keep references to a TxxObject, instead of keeping just the
Interface reference.
I ended up wilth a lot of checks for ( <> nil). Once you have had one or two
Catastrophic exceptions COM seems to fall dead. On NT closing delphi/IIS does the
trick normally. On Win95 a reboot (or hit the reset switch) is normally needed.
I was under the impression that if you keep an Interface to another COM object in you
own object, that Delphi will clean up the reference when you object is destroyed - but
alas this does not appear to be the case, I found I had to set all my IInterface
references to nil in the destructor code/ or in D4 the beforeDestruction of an object.
Myles.
-----Original Message-----
From: Neil Anderson [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, July 20, 1999 11:15 AM
To: Multiple recipients of list delphi
Subject: RE: [DUG]: Calling ocx from ASP com object
Thanks for the pointers I will investigate further,
BTY I do get the Catastrophic exceptions etc which amuses all except me :)
Thanks Neil
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, July 20, 1999 11:00 AM
> To: Multiple recipients of list delphi
> Subject: RE: [DUG]: Calling ocx from ASP com object
>
>
> I have only ever created COM objects using the CoCreateInstance.
> e.g.
>
> OleCheck( CoCreateInstance( CLASS_ObjectLoader, nil, CLSCTX_ALL,
> IID_IObjectLoader, Result ));
>
> As to which thread it is created on Depends on the nature of your own
> thread and its registry settings.
> If both are marked as apartment threaded, I would expect it to be created
> in the same thread - even if it was not, you should not be able to notice
> the difference as COM would marshal out your parameters to the components
> own thread and then marshal/unmarshal back the result - this assumes that
> all your parameters/types can be automatically marshalled - see the Delphi
> help file for those types that can be marshalled eg Integer, WideString.
>
> A bit strange that it hangs. If you have any problems normally only get
> the OLE Catastrophic excpetions.
>
> What I have done in this situation is to write my own test harness using
> Delphi and CoCreateInstance to simulate loading etc. Can then test and
> debug this before using under ASP.
>
> Myles.
>
> -----Original Message-----
> From: Neil Anderson [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, July 20, 1999 9:52 AM
> To: Multiple recipients of list delphi
> Subject: [DUG]: Calling ocx from ASP com object
>
> Hi
>
> I am using a 3rd party non visual ActiveX component(OCX) in a COM object I
> have developed for use with ASP.
>
> The problem I have is that if I run two instances simultaneously my COM
> objects hang.
>
> My COM object is apartment threaded and the OCX registry setting indicate
> that the OCX is also apartment threaded.
>
> After importing the ActiveX control into Delphi I create the ActiveX
> component using the standard Totherocx.Create(nil),
> does the OCX component I create run in the same thread as my base com
> object
> ?
>
> I am currently using the ActiveX component in a standard Delphi
> application
> and I can have two or more instances running concurrently, so I think the
> OCX is ok.
>
> Can anyone offer suggestions as to what I may be doing wrong ?
>
> Thanks Neil
> --------------------------------------------------------------------------
> -
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
application/ms-tnef
