in reply to Re^2: Passing win32::0LE object handle to another thread
in thread Passing win32::0LE object handle to another thread

I am creating a new object to WIN32::OLE in the thread and I am consistently getting the following here:

Win32::OLE(0.1709) error 0x800401f0: "CoInitialize has not been called" at test.pl

From the briefest of looks at the docs for ->Initialize(), I find the optional COINIT argument:

Win32::OLE->Initialize(COINIT)

The Initialize() class method can be used to specify an alternative apartment model for the Perl thread. It must be called before the first OLE object is created. If the Win32::OLE::Const module is used then the call to the Initialize() method must be made from a BEGIN block before the first use statement for the Win32::OLE::Const module.

Valid values for COINIT are:

  • Win32::OLE::COINIT_APARTMENTTHREADED - single threaded
  • Win32::OLE::COINIT_MULTITHREADED - the default
  • Win32::OLE::COINIT_OLEINITIALIZE - single threaded, additional OLE stuff

COINIT_OLEINITIALIZE is sometimes needed when an OLE object uses additional OLE compound document technologies not available from the normal COM subsystem (for example MAPI.Session seems to require it). Both COINIT_OLEINITIALIZE and COINIT_APARTMENTTHREADED create a hidden top level window and a message queue for the Perl process. This may create problems with other application, because Perl normally doesn't process its message queue. This means programs using synchronous communication between applications (such as DDE initiation), may hang until Perl makes another OLE method call/property access or terminates. This applies to InstallShield setups and many things started to shell associations. Please try to utilize the Win32::OLE->SpinMessageLoop and Win32::OLE->Uninitialize methods if you can not use the default COINIT_MULTITHREADED model.

My interpretation of that is that you will need to pass one of those constants when you initialise this object. Which of those will depend upon the threading model chosen by the authors for the particular DCOM library you are trying to use. Ie. It is up to you to read the docs for that library and discover that information. No one here can do that for you.

Please note. I have little knowledge, and no interest, in Win32::OLE. I do have some knowledge of threads, and considerable reservations that using the former from multiple iThreads will ever work. If you succeed in getting beyond the initialisation problem, I foresee that you will encounter other problems, and I will be unable to help you with them.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^4: Passing win32::0LE object handle to another thread
by himanshujain_60 (Initiate) on Mar 19, 2011 at 03:56 UTC

    Hi,
    Thanks for your reply. I was able to get the win32:ole object handle in another thread by doing the following: 

    package operations;   # Package name
Win32::OLE->Initialize(); # first line of my package
no warnings;
use Win32::OLE;

sub init{ # this funtion is called by script
$RQCC = Win32::OLE->new("rqccdriver.ExternalInterface.1") || die "Crea
+teObject: $!";
my $EventQueueTread = Thread->new(\&MonitorEventQueue, ($self, $Id));
# do other stuff
}

sub MonitorEventQueue {
   my $self         = shift;
   my $Id           = shift;
   $EventQueueTread->detach;
   my $Devicehandle= Win32::OLE->GetActiveObject("rqccdriver.ExternalI
+nterface");
# do stuff
}

    [download]

    Thanks for your help

[reply]
[d/l]

In Section Seekers of Perl Wisdom