IsLibrary problem - false in DLL

[Jan Najvarek]

I have followong problem:

DLL is dynamically loaded and unloaded (FreeLibrary) in COM object.

On second call of LoadLibrary application crashes - problems is in
TApplication.Create in line

if IsLibrary then CreateHandle;

As I found out, IsLibrary is false even this is DLL.

COM object is called from Delphi app built with packages, COM object and DLL
is NOT built with packages (C++ Builder 4) - fr sure, I checked it for few
times.
I have no idea why VCL does not recognize DLL - I could understand this
behavior with build with packagas, but DLL is built without packages.

If I run DLL within IDE, second call of LoadLibrary produces OutOfResources
exception in TApplication.CreateHandle.

Anybody have idea why?

I know interim solution (set IsLibrary to true before Forms.pas
inicialization), but I would like to know the source of the problem.

Thanks

Jan Najvarek

[Edward Diener]

I reported a bug to Borland regarding BCB4 and centered on the setting of
IsLibrary and regarding TApplication.CreateHandle. If you have a VCL DLL being
linked to a VCL application, when the application starts, Windows first loads
the DLL, and the DLL loads the VCL package. At that point the VCL sets IsLibrary
to true and performs initialization based on that assumption. This means that
the global application object's Handle does not get created, which would be fine
if there were no VCL application. After the DLL gets loaded the application now
begins, links to the VCL package, and sets IsLibrary to false. Unfortunately the
global Application's Handle is still not created and there is no VCL code to go
back in and create the Handle at this time.

My workaround for this problem was to add to my WinMain routine the line:

if (!Application -> handle) { Application -> CreateHandle() }

There are other instances in the VCL in which things to not get initialized
properly for a VCL application because IsLibrary is initially set to true when
the VCL package is loaded.

Searching past newsgroups I came up with a report of this VCL initialization
technique causing errors as long ago as 1997 and a comment that Borland ignored
a bug submission about this and denied that it was a bug claiming that this was
as designed. I have no idea whether this is fixed in BCB5 but if it isn't I
think that Borland has a serious problem in the VCL code on their hands that
they really need to fix finally.

I have mentioned this problem in 2 posts in the past with little results and as
far as I am concerned it is like there is a conspiracy of silence to ignore this
rather large hole in the VCL.

Finally I submitted a bug report of my own to Borland on this a few days ago but
I am not going to hold my breath waiting for a reply. I am betting that Borland
will come back, if I hear from them on my bug report at all, and say that this
is as "designed", even though it is a clear error in the VCL. I am hoping that
Borland will come back and tell me that it is fixed in BCB5. My past experience
in dealing with Borland's bug submission people is miserable to an extreme with
clear bugs and errors being denied.