Need to create form in separate thread
Yorai Aminov (TeamB)
>I'm trying to create a program in Delphi that can create a form that runs
>in it's own thread.
The VCL is not thread safe. Certain areas assume they are running in the
context of the process' main thread. You can create non-VCL application with
multiple input queue threads.
Why do you need to create the form in another thread? It's quite possible to
handle program logic in multiple threads, and interface in the main thread.
--
Yorai Aminov (TeamB)
http://ourworld.compuserve.com/homepages/yaminov
(TeamB cannot answer questions received via e-mail)
Peter Montgomery
existing component) to do this? I've searched the web and have only found
two Thread components, but neither seemed to do quite what I need.
Thanks,
PeterM
--
Bogus X added to address. Remove for reply.
Fernando Colombo
Peter Montgomery escreveu na mensagem
<01bdc4c9$b6020c20$9497aec7@desktop>...
To create a form (or any message-processor control) in a thread isn't an
easy task, because in Delphi all messages are processed by the main global
object Application (an instance of TApplication), wich is not prepared for
multiple threads. But you can create a form in the main thread and this form
can comunicate with your thread with simple mutual exclusion algorithm. This
will allow the main thread to process the form messages, and your thread to
control other tasks with that form. This works pretty well in status forms,
and might work in other cases too.
You can also create another instance of TApplication inside your thread,
then use the method CreateForm (used by own Delphi in the .DPR file) and
then call your TApplication.Run, like the example:
procedure TMyThread.Execute;
var
xApp: TApplication;
begin
xApp := TApplication.Create(nil);
try
xApp.CreateForm(TForm2, Form2);
xApp.Run;
finally
xApp.Destroy;
end;
end;
I have tested, and it works fine. The only trouble is that the application
seems to get into an infinite loop when the program finished, but I didn't
tested it too deeply. Also, you might want to atach a method to the event
"OnIdle" of your TApplication (xApp in the example) to quit gracefully when
the thread is terminated (or canceled) by his caller. You must test it more,
because VCL might have some lacks in multithread processing.
Best regards!
FC (fcol...@bnu.zaz.com.br)
Gilles Koffmann
What's the advantage of having a second instance of TApplication ?
Don't you think you'll have the thread synchronization constraint still
active ?
And what about the side effects ?
Anyway I'm really interested by your feedback on this.
Bye.
Gilles Koffmann.
Fernando Colombo a écrit dans le message <6qpb6j$il...@forums.borland.com>...
Gilles Koffmann
What do you mean by "the VCL is not thread safe" ?
Is it when it comes to displaying on the screen and querying on a SQL Server
?
Is there other areas ?
I have an application that has to do automatic refresh queries on several
forms. It runs on a PC with a double screen (that means that the user can
watch several windows at the same time).
Several ways of doing this are :
- one connection in the app. The user can not work properly because he
is interrupted each time a query triggers.
- one connection/thread per form. The advantage is that the user can
work nicely (with no SQL cursor). The constraint is that I do not have any
control on the connections (what about the licences ?) and the display will
not be very nice (because of the synchronization).
- Two apps in one (better than shampoo) with one application dealing
with real-time.
- .............. I'm interested by any other ideas
Bye.
Gilles Koffmann.
Yorai Aminov (TeamB) a écrit dans le message
<6qoc5t$sv...@forums.borland.com>...
Peter Montgomery
You're right. I approached the problem from a different angle and
discovered that I can indeed have a thread handling internal logic, while
the main program keeps running. It actually simplified a number of issues.
On big win is that my new thread can update the form displaying status and
then go to sleep without causing any disruption in the interactivity of the
various windows in my application. Prior to that I was having to use
"ProcessMessages" right before putting my mainthread to sleep which at
least kept the window repainted periodically. Now the windows all behave
normally.
Thanks,
PeterM
--
Bogus X added to address. Remove for reply.
Yorai Aminov (TeamB) <yam...@no.spam.trendline.co.il> wrote in article
<6qoc5t$sv...@forums.borland.com>...
> Peter Montgomery wrote in message <01bdc4c9$b6020c20$9497aec7@desktop>...
> >I'm trying to create a program in Delphi that can create a form that
runs
> >in it's own thread.
>
Yorai Aminov (TeamB)
>What do you mean by "the VCL is not thread safe" ?
I mean the VCL was not written with multiple threads in mind, with several
exception. So thread-safe code is the exception, not the rule. Database
access is thread safe, for example, as long as you create a separate
TSession for each thread. TCanvas can be made thread-safe by using the
Lock/Unlock methods.
>I have an application that has to do automatic refresh queries on several
>forms. It runs on a PC with a double screen (that means that the user can
>watch several windows at the same time).
If you're using visual data aware controls, you can only do this in a single
thread. Additional threads may be used for database access, as long as they
don't need user interaction. If you are executing the query automatically
(using a timer, I guess), try no to do it too often. Find a balance between
the desire to provide live data and the delay forced by the database access.
--
Yorai Aminov (TeamB)
http://ourworld.compuserve.com/homepages/yaminov
(TeamB cannot answer question received via e-mail)
Gilles Koffmann
Yorai Aminov (TeamB) a écrit dans le message
>I mean the VCL was not written with multiple threads in mind, with several
>exception. So thread-safe code is the exception, not the rule. Database
>access is thread safe, for example, as long as you create a separate
>TSession for each thread. TCanvas can be made thread-safe by using the
>Lock/Unlock methods.
But one TSession for each thread means also one TDatabase (and one
connection) for each TSession ?
If not, how can you manage to access the unique TDataBase/connection ?
By writing concurrency code ?
>If you're using visual data aware controls, you can only do this in a
single
>thread. Additional threads may be used for database access, as long as they
>don't need user interaction.
Is it because you can't control when the canvas of the data aware controls
will be changed
(after a query is refreshed for example) ?
>If you are executing the query automatically
>(using a timer, I guess), try no to do it too often. Find a balance between
>the desire to provide live data and the delay forced by the database
access.
I'm using an Oracle feature called the Dbms_Alert. It is the Interbase
equivalent of TIBEventAlerter.
Thanks for your help Yorai.
Gilles Koffmann
Yorai Aminov (TeamB)
<gkof...@capgemini.fr> wrote:
>But one TSession for each thread means also one TDatabase (and one
>connection) for each TSession ?
Yes.
>Is it because you can't control when the canvas of the data aware controls
>will be changed
>(after a query is refreshed for example) ?
No. The data access components themselves are thread safe - they can
be used in any thread, provided they use a session created in that
thread. Visual controls should always be used in the main thread
(including data aware controls). This means they can only use data
access components that are created in the main thread.
---
Yorai Aminov (TeamB)
http://ourworld.compuserve.com/homepages/yaminov
(TeamB cannot answer questions received via email.
To contact me for any other reason remove nospam from my address)