triming the message cause QT-API list is sending it back
> I think there's a subtle problem with the script below: you create a
CFObject in the WScript process, load the settings, and then assign the
CFObject to
> a QTExporter belonging to QuickTime Player running in a different
process. The QTExporter is unable to load the out-of-process CFObject that
> you've handed it, and fails with error code 0x80040201.
Shouldn't COM marshal the object across processes OK? I suppose it's not a
COM related problem, but more of a QuickTime one
If the COM object is passing some internal pointer to a calling code (or a
calling client object to which the COM object was passed to), it could first
check the process id and if it's different from the process id on which the
object was first created it could create a local structure and return that
instead. An issue then is who will free the local structure, since the
object will be self-destroyed (it's reference counted at the process where
it was originally created [the server]) and it won't be able to kill QT
structures it had created at the context of different processes (clients).
In the above text, the server is WScript (where CFObject was created) and
the client is the QuickTime Player Application's Exporter object (at start
its vice-versa, but then it calls into the CFObject we passed to it to get
the exporter settings)
***
A solution could be to add a method called "CFObject <CFObject>.LocalCopy()"
that checks the process id and if it's different from the one on which the
object was created (you keep the PID at a private field during object
construction), then creates a local CFObject (at the context of the code
that called LocalCopy) and encapsulates the trick you wrote below if it sees
the PID of the current process is different from the private field it had
stored with the PID of the CFObject creator process.
Any code that uses CFObjects passed to it (in this case the qtExporter
object code that runs in the context of the QuickTime Player Application in
this case), will always call "LocalCopy" on the CFObject passed to it - note
LocalCopy won't be called by the WScript code in this case, it will remain
as is, the qtExporter implemenation will call LocalCopy so that it's created
in the context of the process that will use the CFObject).
Using this scheme you now have two objects that will both take care fine of
the internal QT structures they encapsulate [e.g. they'll be able to delete
them when the object's refcount goes to 0 and it kills itself])
We use the PID checking to avoid doing this XML trick for all LocalCopy
calls and doing it only when LocalCopy is called at the context of a process
different from the one the object was created in. Can extend this adding
ThreadIDs too (those are numbered per process I think so you'll need the PID
number too to distinguiss them system-wise) if QuickTime CFObjects creation
and usage steps are sensitive to using different Threads in the same process
too. For creation of CFObject and then call(s) of LocalCopy on the same
process (or thread too if you check for thread affinity too), a binary copy
of the QT structure for CFObject (if there's such a fast proc at QT API to
clone the respective structure) should be used instead to avoid the XML
processing penalty for the local case.
***
I'll fill in a report for this
-----
John Chromie wrote:
A workaround involves using an existing Settings CFObject that belongs to
the QuickTime Player process without having to create a new CFObject:
var xmlCodecInfoText = CodecFileInfo.ReadAll();
var tempSettings = qtExporter.Settings;
tempSettings.XML = xmlCodecInfoText;
qtExporter.Settings = tempSettings;
----------------
George Birbilis (email@hidden)
Microsoft MVP J# for 2004-2006
Borland "Spirit of Delphi"
* QuickTime, QTVR, ActiveX, VCL, .NET
http://www.kagi.com/birbilis
* Robotics
http://www.mech.upatras.gr/~Roboticshttp://www.mech.upatras.gr/~robgroup
_____
avast! Antivirus <http://www.avast.com> : Outbound message clean.
Virus Database (VPS): 0626-1, 27/06/2006
Tested on: 28/6/2006 3:15:42 ??
avast! - copyright (c) 1988-2006 ALWIL Software.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
QuickTime-API mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quicktime-api/email@hidden
This email sent to email@hidden
