Remote Data Module, ActiveX and DLL problems.

Hi
I have got an exe with a remote data  data module which is going to provide data to various forms which are contained in various dlls - which in turn get called by a main application.

Now some of the dlls - due to various reason need to be converted to activeX dlls- which in turn are loaded as required by the main application by calling a normal dll which in turn initialize the ActiveX dll.
Now When I load the ActiveX dll, everything is OK, the remote data server
starts up, the forms in the activex dlls are show to the user and so on. But when I shut down the main application everything goes haywire, the activeX dll refuses to be unloaded, and I get too many exceptions- lots and lots of access violation.The application and most of the thime windows simply hang. When I try to close the remote server, I get the warning that there are still objects connected to the server- even though I have explicitely destory the activeX dll.
I am using Windows 98 Second Edition, Delphi 5 enterprise Edition and I am connecting to a Access 2000 Database using the ADO Components. In addition I am using InfoPower 2000 components. I am using code like this:
 
The name of the interface in the automatiom Object is IMBCif
In the activeX dll we have code like this:
the datamodule is dmCIF
The Form is FrmCIf

In the ActiveX dll I have got code like this:
var
...
Procedure CreateTheForm;
  if not assigned(dmCIF1) then
    dmCIF1 := DMCIF.create(nil);
    dcomConnection.connected := true;
    open various ClientDataSet;
  if not assigned(FrmCIF1) then
     frmCIF1:=TFrmCIF.create(nil);
   frmcIF.show;
end;


Procedure DestoryTheForm;
  if assigned(FrmCIF1) then
     frmCIF1.free;
  if  assigned(dmCIF1) then
    close various ClientDataSet;
    dcomConnection.connected := false;
    dmCIF1.free;
end;

Now I import the type library in the dll(LoadCIF.dll) and write sometning like this;

var
  IMiCIF : IMBCif;

Procedure loadForms;
begin
if IMiCIF <> nil then
  IMicif := CoMiCIF.create;
IMiCIF.CreateTheForms;
end;

Procedure CloseTheForms;
begin
  if imicif <> nil then

  begin
   imicif.FreeTheForms;
   imicif:=nil;
  end;
end;

From is;
MyMain app I call the dll like this

on click event of a button;
if not dllLoaded then
  DllHandle := LoadLibrary('LoadCIf.dll');
@ShowForm := getProcAddress(DllHandle,'
loadForms');
@closForms := getProcAddress(DllHandle,'CloseForms');
....
ShowForm;

on the destory event of the form.
ClosForms;
FreeLibrary(DllHandle);

Can Anybody please help, It is driving me crazy.
Paras
paraskafleyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

LischkeCommented:
Just a quick shot. Shouldn't that be:

Procedure loadForms;
begin
if IMiCIF = nil then
  IMicif := CoMiCIF.create;
IMiCIF.CreateTheForms;
end;

(Note the change equal sign).

Ciao, Mike
0
LischkeCommented:
Further tips:

Always check your procedural variables whether they contain valid values before using them. E.g. ClosForm might be nil in which case the application badly crashes.

Keep in mind the GetProcAddress call is case sensitive. Is this line just a typo:

@closForms := getProcAddress(DllHandle,'CloseForms');


or shouldn't it rather be:

@closForms := getProcAddress(DllHandle,'CloseTheForms');

?

Don't start your application if any of the load functions already fails. Check that!

Ciao, Mike
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
paraskafleyAuthor Commented:
mike
that was a typo(in the first comment, I didn't cut & paste it from my source)
Secondely thanks for telling me that getProcAddress is case - sensetive(I will check it tomorrow- it is already 10:00 here). I always check whether getProcAddress return valid value or not by  testing whether it is null or not.
But I thought Delphi and Windows will take care of unloading the activeX dll when I call FreeLibrary to unload the Calling dll.
Is there any reason why it shouldn't work? Is there any problem in placing ADO dataset in remote data modules or placing the forms that connect to a remote data module in an activeX dll?

Regards
Paras
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

LischkeCommented:
I can't tell you anything about ADO what you don't already know, but an important aspect to consider are forms in DLLs. Usually there should not be a problem using them as long as you create and free them in the DLL exclusively. Otherwise you need to pass the application object of your main application to the DLL as this contains an own application object which is wrongly accessed in the very special case that you either create or free forms not in the same module (application/DLL).

This might not be an issue for your application, but, just in case, pass your main application object to all DLLs which create forms.

Ciao, Mike
0
paraskafleyAuthor Commented:
thanks I will remember that.I haven't been able to try what you sugested because of the weekend but I am hoping that they do work.
0
paraskafleyAuthor Commented:
thanks
0
LischkeCommented:
Thanks too :-)

Ciao, Mike
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Delphi

From novice to tech pro — start learning today.