🚀 go-pugleaf

It seems like there's no way. From what I googled I found this type of 
an application should always be built with runtime packages to be 
working properly. No matter if I use BPL or DLL.

How could I find out what files (BPLs I assume) my project needs to be 
deployed with ?

Sincerely
Ondrej Gratz

Ondrej Gratz wrote:
> Hello, everybody !
> 
> /*******************************************/
> ide: Borland C++ Builder 6 Build 10.166,
>  all actual updates applied.
> 
> Please download attachment from borland.public.attachments, "Form loaded 
> from dll ATTACH" post. It's only 10 kB. I've tried to keep paths 
> relative, so you should have no problem compiling it under BCB6.
> /*******************************************/
> I'll try to keep it short. I've created very simple application to 
> demonstrate my problem.
>     After you compile both projects (one of them is an EXE, the other is 
> a DLL), run server.exe.
>     On the main menu, press Show DLL form. Form loaded from the DLL 
> appears on the main form workspace.
> 
> Now in both projects uncheck "Build with runtime packages" on the 
> Packages tab in the project Options dialog.
>     Again, compile projects and run the application.
> 
> /* The problem: now you can't see the DLL form. */
> The function that shows the form is located in 
> client.bpr/client_main.cpp, r.49.
> 
> I know the actual application's bad. But it's my first implementation of 
> an application with dynamically loadable modules. That's a great concept 
> for me, but the first solution is bad.
> 
> Unfortunatelly I've found this problem after a big part of the 
> application has been completed. I don't want to ship all of the runtime 
> libraries with the project, so I appreciate any ideas.
> 
> Thanks very, very much for replies.
> 
> Sincerely
> Ondrej Gratz

From the help for TApplication->Handle :

"Note: When writing a DLL that uses VCL forms, assign the window handle of
the host EXE's main window to the DLL's
Application.HandleApplication->Handle property. This makes the DLL's form
part of the host application. Never assign to the Handle property in an
EXE."

In your DLL, implment a method where you can pass in a handle.  In the DLL,
save the existing TApplication->Handle value and replace it with the
passed-in handle.  On DLL shutdown, restore the original handle.

Mark

"Ondrej Gratz" <gratzo@atlas.cz> wrote in message
news:4284ec37@newsgroups.borland.com...
> Hello, everybody !
>
> /*******************************************/
> ide: Borland C++ Builder 6 Build 10.166,
>   all actual updates applied.
>
> Please download attachment from borland.public.attachments, "Form loaded
> from dll ATTACH" post. It's only 10 kB. I've tried to keep paths
> relative, so you should have no problem compiling it under BCB6.
> /*******************************************/
> I'll try to keep it short. I've created very simple application to
> demonstrate my problem.
> After you compile both projects (one of them is an EXE, the other is a
> DLL), run server.exe.
> On the main menu, press Show DLL form. Form loaded from the DLL appears
> on the main form workspace.
>
> Now in both projects uncheck "Build with runtime packages" on the
> Packages tab in the project Options dialog.
> Again, compile projects and run the application.
>
> /* The problem: now you can't see the DLL form. */
> The function that shows the form is located in
> client.bpr/client_main.cpp, r.49.
>
> I know the actual application's bad. But it's my first implementation of
> an application with dynamically loadable modules. That's a great concept
> for me, but the first solution is bad.
>
> Unfortunatelly I've found this problem after a big part of the
> application has been completed. I don't want to ship all of the runtime
> libraries with the project, so I appreciate any ideas.
>
> Thanks very, very much for replies.
>
> Sincerely
> Ondrej Gratz

Thanks.
However I've already tried this. It has no effect. This is probably 
needed when loading an MDI child form from a DLL.

The application works fine when it's built with runtime packages. I 
suppose there are problems with memory management. I added memmgr.lib to 
both projects but it has no effect too.

Sincerely
Ondrej Gratz

Mark Guerrieri wrote:
> From the help for TApplication->Handle :
> 
> "Note: When writing a DLL that uses VCL forms, assign the window handle of
> the host EXE's main window to the DLL's
> Application.HandleApplication->Handle property. This makes the DLL's form
> part of the host application. Never assign to the Handle property in an
> EXE."
> 
> In your DLL, implment a method where you can pass in a handle.  In the DLL,
> save the existing TApplication->Handle value and replace it with the
> passed-in handle.  On DLL shutdown, restore the original handle.
> 
> Mark
> 
> "Ondrej Gratz" <gratzo@atlas.cz> wrote in message
> news:4284ec37@newsgroups.borland.com...
> 
>>Hello, everybody !
>>
>>/*******************************************/
>>ide: Borland C++ Builder 6 Build 10.166,
>>  all actual updates applied.
>>
>>Please download attachment from borland.public.attachments, "Form loaded
>>from dll ATTACH" post. It's only 10 kB. I've tried to keep paths
>>relative, so you should have no problem compiling it under BCB6.
>>/*******************************************/
>>I'll try to keep it short. I've created very simple application to
>>demonstrate my problem.
>>After you compile both projects (one of them is an EXE, the other is a
>>DLL), run server.exe.
>>On the main menu, press Show DLL form. Form loaded from the DLL appears
>>on the main form workspace.
>>
>>Now in both projects uncheck "Build with runtime packages" on the
>>Packages tab in the project Options dialog.
>>Again, compile projects and run the application.
>>
>>/* The problem: now you can't see the DLL form. */
>>The function that shows the form is located in
>>client.bpr/client_main.cpp, r.49.
>>
>>I know the actual application's bad. But it's my first implementation of
>>an application with dynamically loadable modules. That's a great concept
>>for me, but the first solution is bad.
>>
>>Unfortunatelly I've found this problem after a big part of the
>>application has been completed. I don't want to ship all of the runtime
>>libraries with the project, so I appreciate any ideas.
>>
>>Thanks very, very much for replies.
>>
>>Sincerely
>>Ondrej Gratz
> 
> 
>