Life of NEWCOM

[Walt Decker]

I assume that under the hood NEWCOM does "CoInitialize" and "CoCreateInstance" to create an instance of the COM class or object. So how long is the life of the instance? Does it depend on the life of the varb pointing to the instance, i. e. local or global?

[José Roca]

> I assume that under the hood NEWCOM does "CoInitialize" and "CoCreateInstance" to create an instance of the COM class or object.

Wrong assumption. NEWCOM only does CoCreateInstance. The compiler does CoInitialize when the program starts and CoUninitialize when it ends.

> So how long is the life of the instance? Does it depend on the life of the varb pointing to the instance, i. e. local or global?

If it is global or static, until the program ends; if it is local, until the variable goes out of scope. But you can "kill" it at any time setting it to NOTHING.

[Walt Decker]

Thank you, Mr. Roca.

The reason I asked is I have seen C/C++ code that uses coinitialize(), and cocreateinstance to work with ISHELLLINK and IPERSISTFILE.

At the end of the code it does:

iPersistFile->Release();
iShellLink->Release();
couninitalize()

However, I have not been able to find release methods for IPERSISTFILE and ISHELLLINK.

[José Roca]

The reason I asked is I have seen C/C++ code that uses coinitialize(), and cocreateinstance to work with ISHELLLINK and IPERSISTFILE.

Because the C++ compilers don't call CoInitialize/CoUninitialize under the hood, but PB does it.

At the end of the code it does:

iPersistFile->Release();
iShellLink->Release();
couninitalize()

However, I have not been able to find release methods for IPERSISTFILE and ISHELLLINK.

You can do:

iPersistFile = NOTHING
iShellLink = NOTHING

But if the program is going to end or iPersistFile and iShellLink are local, you can omit it.

PB has always tried to imitate VB6.

[Michael Mattias]

I believe PB also calls CoInitialize on THREAD CREATE . (Must be called on each thread using COM objects).

[Walt Decker]

Mr. Roca, the point was, 1) I could find now "release" methods in the MS docs, and 2) thank you for pointing out the method to release the interface when using NEWCOM.

Mr. Mattias, That sounds reasonable since a thread is "a prog within a prog."

[Michael Mattias]

That sounds reasonable....

"Sounds Reasonable" is not a good reason.

From the Microsoft API doc for CoInitializeEx() ...

RemarksCoInitializeEx must be called at least once, and is usually called only once, for each thread that uses the COM library. Multiple calls to CoInitializeEx by the same thread are allowed as long as they pass the same concurrency flag, but subsequent valid calls return S_FALSE. To close the COM library gracefully on a thread, each successful call to CoInitialize or CoInitializeEx, including any call that returns S_FALSE, must be balanced by a corresponding call to CoUninitialize.

Note You must include the #define _WIN32_DCOM preprocessor directive at the beginning of your code to be able to use CoInitializeEx.

A thread must call CoInitializeEx or CoInitialize before calling any other COM library function except the CoGetMalloc function and other memory allocation calls (CoTaskMemAlloc, CoTaskMemFree, CoTaskMemReAlloc, and the IMalloc methods on the task allocation supplied by CoGetMalloc).

.....

AFAIK PowerBASIC does not document its use of this function. But since PB has tried - and succeeded IMO - in simplifying multi-threaded programming, I'm pretty sure they handle the COM initialization.