mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2026-01-30 21:44:35 +01:00
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1434 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
40 lines
2.7 KiB
Plaintext
40 lines
2.7 KiB
Plaintext
[[Property:uuid|5422DF33-848E-491F-A761-21B545F425B4]]
|
||
[[Property:weight|0]]
|
||
[[Property:title|Graphics with concurrency]]
|
||
How can I build a concurrent graphical in application in Eiffel?
|
||
|
||
Eiffel has a great library for producing graphical applications: EiffelVision. Eiffel also has a powerful concurrency mechanism: SCOOP.
|
||
|
||
How do you make the two work together? This note gives you simple guidelines to ensure that the EiffelVision-SCOOP marriage is a harmonious and productive one.
|
||
|
||
The first question: why does the problem even exist? Let’s go back to the pre-SCOOP days. Any graphical application has an “event loopâ€, which keeps watching for graphical user events, such as a mouse click, and triggering the corresponding application responses, such as saving a file (if the user clicked “OK†on a File Save dialog). If you were using multithreading, the event loop would run in the main thread, also called the GUI (Graphical User Interface) thread.
|
||
|
||
Enter SCOOP. The old technique cannot work because a processor stuck in a loop cannot process any logged call! If you perform calls on a graphical widget, say the OK button, they will be logged right away, but they can only execute once the processor has exited its event loop. Not what you want.
|
||
|
||
So here is what you should do:
|
||
|
||
Since your application uses SCOOP, somewhere it creates a separate object. Let the creation instruction be
|
||
create s.make
|
||
where s is of a separate type (e.g. separate T).
|
||
|
||
In the "make" creation procedure, create an EV_APPLICATION object, using an instruction such as
|
||
create my_app
|
||
with my_app of type EV_APPLICATION.
|
||
|
||
Still in "make", create all the GUI elements. They will all be in the same processor that created the EV_APPLICATION object.
|
||
|
||
Also in "make", start the application, using
|
||
my_app.launch
|
||
In the pre-SCOOP world, launch would start the event loop. Here it only creates a separate object (of type EV_APPLICATION_HANDLER), which will run the event loop, forwarding events to the EV_APPLICATION object.
|
||
|
||
This is all the make procedure should do. Make sure it terminates with the preceding step. Otherwise, the event loop will never run!
|
||
|
||
Now you can start using EiffelVision as you are used to, by sending GUI requests to the EV_APPLICATION object:
|
||
|
||
o For requests coming from the same processor as s, just use the EV_APPLICATION object directly.
|
||
o For requests coming from another processor, you need access to that object; you can get it for example by through the feature ev_separate_application of class EV_SHARED_APPLICATION}.
|
||
|
||
|
||
That's all! Happy concurrent Eiffeling.
|
||
|