🚀 go-pugleaf

"Stefano Bonifazi" <stefboombastic@email.it> wrote in message
news:4592cf7c$1@newsgroups.borland.com...

>   Hi Mr Lebeau! Thank U for Ur reply, and above all for the full
> working code! Anyway that is exactly what I wished to avoid! :) ...

Then you can't use a TForm (or any other type of window) in a console
application.  A message queue is required in order for messages to work
properly.  A DLL has no way of knowing whether it is being loaded by a GUI
application that has a message queue, or a console application that does
not.

If you want the DLL to run its own queue, then you should export a separate
blocking function from the DLL that console applications call but GUI
applications do not call.  If you don't want to implement the message queue
manually, you could use TForm::ShowModal() to handle it for you.

> I should minimize the code that launches my forms from inside the
> console application!

Then you will have to export a separate function specifically for console
applications to use, and let the function do all of the work internally.

> I cannot modify the main such way.. it already sits on its loop doing
> other than windows messages processing..

If the console application already has an active message queue, then your
TForm should have already been working from the very beginning.

> I hoped I could do all in a separate thread..

VCL windowed components (including TForm) do not work well in worker
threads.  For the most part, the VCL is not thread-safe at all.  If you must
use a window in a thread, then you should use the Win32 API directly
instead.  And there must be a message queue in whatever thread is calling
the DLL.  Messages can be received for a window only in the same thread that
creates the window.


Gambit