DLL and VCL problems
Clayton M. Arends
This post kind of goes along with my previous post "String Initialization
and DLLs".
I have found another situation that causes the problems with my application.
If I have a DLL with a function exported and then call that function in my
application then the TApplication::OnActivate, TApplication::OnDeactivate,
and minimization messages aren't processed. To avoid any confusion here is
my code.
The DLLMAIN files are part of the dll. The APPMAIN file is the CPP part of
the main form of the application. There is nothing special about the form
// ----DLLMAIN.H----
#ifndef dllmainH
#define dllmainH
#undef DLL_I_E__
#ifdef DLLMAIN_DEFINITIONS__
#define DLL_I_E__ __declspec(dllexport)
#else
#define DLL_I_E__ __declspec(dllimport)
#endif // #ifdef DLLMAIN_DEFINITIONS__
void __fastcall DLL_I_E__ ShowIt(int Message);
#endif
// ----DLLMAIN.CPP----
#include <vcl.h>
#pragma hdrstop
#define DLLMAIN_DEFINITIONS__
#include "dllmain.h"
#pragma package(smart_init)
void __fastcall ShowIt(int Message)
{
ShowMessage(IntToStr(Message));
}
// ----APPMAIN.CPP----
#include <vcl.h>
#pragma hdrstop
#include "appmain.h"
#include "dllmain.h"
#pragma package(smart_init)
#pragma resource "*.dfm"
TForm1 *Form1;
__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner)
{
ShowIt(0);
}
What am I doing wrong? This is in CBuilder 4 Pro, all patches. Both the
DLL and the application are set to build with packages and dynamic RTL.
- Clayton
Dirk Seifert
with the "use packages" option switched on ?
Than this is "normal" behaviour!
The problem is that both (EXE and DLL) share the same instance of the
VCL40.bpl (a Delphi package DLL). The Application object is in this case
created in and by the VCL40.bpl. The initialization behaviour of the
Application object differs somewhat if it is created for a DLL (your DLL).
Unfortunatly your DLL is (normally) initialized before your EXE file and so
the Application object is initialized for a DLL. Your EXE file is than
working
with an Application object that was initialized for a DLL. The difference is
small but visible. For a DLL Application.Handle is always zero, but for
an EXE it is <> zero. There are two ways to work around this problem:
1) Call Application.CreateHandle in your main CPP-file (of your EXE) before
any other method of Application is called. This creates the missing
Application.Handle.
(I do it this way)
2) Link your DLL dynamically and not statically. In this case the EXE is
initialized
before the DLL.
Hope this helps
Dirk Seifert
Clayton M. Arends <car...@evisions.com> schrieb in im Newsbeitrag:
80cmic$k3...@forums.borland.com...
Clayton M. Arends
Thanks for your suggestions. I guess I thought I knew all of what building
with the packages did for me but obviously I didn't. I thought packages
would just function as a DLL and put all the VCL code external so that my
executable sizes would be smaller. Thanks to your explanation I am slowly
gaining a better grasp of this stuff.
So since your second suggestion isn't an option for this application (it may
be for others) I can either turn building with run time packages off (and
increase all my EXE and DLL file sizes) or add one line of code. Hmmm...let
me think...
I put the Application->CreateHandle() before the automatic
Application->Initialize() and I have my events again. Thank you so much.
That is one thing I never would have found out on my own. Even the help
says not to call CreateHandle directly.
In your debt,
Clayton
Clayton M. Arends
Application->CreateHandle() method prior to initialization. However, I have
recently noticed that doing this causes the application icon (the one that
displays on the task bar and in the ALT-TAB window) is no longer my
application's icon. It is a default icon. I have "solved" this by setting
the application icon equal to my main form's icon when it's created but are
there anymore surprises that I should be aware of because of this trick?
- Clayton
Stefan Hoffmeister (TeamB)
>I thought packages
>would just function as a DLL and put all the VCL code external so that my
>executable sizes would be smaller.
They do - but packages initialize, too - and in your case the loading
order is
* DLL (statically linked)
* EXE
Since the DLL is loaded first, the DLL "gets" the Application object - and
that is the problem, because it should be in the EXE.
>I can either turn building with run time packages off
Nope. You just need to turn it off for either the DLL or the EXE.
>That is one thing I never would have found out on my own.
Hint: try a searching engine next time, for instance the one referenced
below. I posted a long analysis of this behaviour at least twice to these
groups in the past.
--
General information:
* Post to the right group - http://www.borland.com/newsgroups/
* Do not cross- or multipost
* Research at http://www.mers.com/searchsite.html
Stefan Hoffmeister - http://www.econos.de/
(TeamB - http://www.teamb.com/)
Stefan Hoffmeister (TeamB)
>are there anymore surprises that I should be aware of because of this trick?
Plenty - your application object is messed up.
Simply don't build the EXE with packages and all will be fine.
Dirk Seifert
trick?
>
> Plenty - your application object is messed up.
>
> Simply don't build the EXE with packages and all will be fine.
problem).
Can you explain further what you mean with messed up.
Dirk Seifert
(sorry Stefan I hit the wrong button yesterday, please apologize the email)
Stefan Hoffmeister (TeamB)
>I can't agree that it is messed up (although I did'nt notice the icon
>problem). Can you explain further what you mean with messed up.
In my book, the application is messed up if the Application VCL object is
not in the least properly initialized.
This has pretty subtle side-effects and the best solution is not to have
the DLL "own" the Application object.
Dirk Seifert
> not in the least properly initialized.
>
> This has pretty subtle side-effects and the best solution is not to have
> the DLL "own" the Application object.
In my application it seems to work (maybe I will take a look
at the icon problem).
At the first look into the VCL-source I just saw one line that cares
about EXE/DLL. Its "if not IsLibrary then CreateHandle;" in the
constructor of TApplication. This may result in side effects, but I
did not see any and did not hear about any besides the icon problem.
So I think I will stick to my solution until something else is proven.
But if it is such a problem, why does'nt Borland address it.
It should be possible, to share the standard packages between
an EXE and DLL's written in ObjectPascal.
Dirk Seifert
Stefan Hoffmeister (TeamB)
>I just saw one line that cares
>about EXE/DLL.
It is not about EXE/DLL. It is about who owns what, where.
>So I think I will stick to my solution until something else is proven.
Well, you are certainly free to do that.
>But if it is such a problem, why does'nt Borland address it.
>It should be possible, to share the standard packages between
>an EXE and DLL's written in ObjectPascal.
It definitely is. You have two options
a) Don't statically link the DLL(s) that have been built with packages
b) Don't use runtime packages in the DLL **and** the EXE.
If you do neither - no problem.