mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-07 23:32:42 +01:00
d1f56bf14d
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1528 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
40 lines
2.6 KiB
Plaintext
40 lines
2.6 KiB
Plaintext
[[Property:uuid|D1DDF411-5387-4A81-9A85-3EF8A2A4220D]]
|
|
[[Property:weight|0]]
|
|
[[Property:title|How to build a concurrent graphical application: EiffelVision with SCOOP]]
|
|
==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 <eiffel>EV_APPLICATION</eiffel>.
|
|
|
|
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:
|
|
|
|
* For requests coming from the same processor as s, just use the EV_APPLICATION object directly.
|
|
* 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.
|
|
|