From 68e63e50438d7049db697ca058aac4d45baf3e53 Mon Sep 17 00:00:00 2001 From: eiffel-org Date: Wed, 6 Apr 2016 07:10:01 +0000 Subject: [PATCH] Update wikipage How to build a concurrent graphical application: EiffelVision with SCOOP. (Signed-off-by:alexk). git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1533 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- ...-application--EiffelVision-with-SCOOP.wiki | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/documentation/trunk/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki b/documentation/trunk/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki index 58b679d3..d0a2c9cd 100644 --- a/documentation/trunk/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki +++ b/documentation/trunk/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki @@ -5,34 +5,34 @@ 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. +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. +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. +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). +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 +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. +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. +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 +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. +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: +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}. +* 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.