🚀 go-pugleaf

Thank U Mr. Lebeau!

Remy Lebeau (TeamB) wrote:
> 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.  

Well it seems this time I get into something impossible to do :(

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

Impossible the console application should continue its work in spite of 
what my form does ...

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

No the console application has a loop that does other than processing 
windows messages.. low level stuff with high priority

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

If I have to start coding all the windows in WinAPI the wonder of 
borland vanishes and I'd better use the MS VC++

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.

But if I create a window inside a thread spawned by the DLL, cannot 
those messages be received by the thread provided that window has its 
message queue?


Thank U again...
Stefano B.