🚀 go-pugleaf

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
> 
> 
>