[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GUI-Model communication



Tom Hilinski wrote:
> Martin Waller recently posted a question regarding methods used to =
> communicate between a simulation class instance and a controlling GUI. I =
> have done this recently for a model, in which the model updates a =
> progress bar, displays a message in a text canvas displaying the =
> simulation time and recent actions, and accepts a "cancel" request =
> generated by the user pressing a "cancel" button on the progress bar =
> dialog.=20

Interestingly, we are working on the same problem, but distributed
and in Java.  It works great so far, except for annoying visual
bugs (Java = write once, debug everywhere).

> Essentially it works like this:
> 
> 1. The GUI class makes an instance of the simulation class, and gives it =
> pointers to global functions to which will either send or receive =
> messages from the simulation instance.
> 
> 2. The GUI class tells the simulation to run, and concurrently displays =
> a progress bar with a Cancel button.
> 
> 3. The simulation has a time-step loop, within which it sends a message =
> to the progress bar dialog containing the simulation time, sends =
> messages as needed to be displayed to the user, and checks for received =
> ("posted") messages at each time step.

Our solution is more robust.  Simulation runs as a separate 
process
and gives feedback via stderr (which is routed via a socket).  The
client just displays a timer and whatever feedback it received.
Cancel is called `Abort' to discourage female users. ;-)

Bugs in the simulation do not affect the client and vice versa.
There is no need to deal with asynchronous events and error 
recovery.
The simulations can be written in any language (Fortran in our 
case).

-- 
Drive^H^Hnk safely!
Alex Verstak                 averstak.campus.vt.edu
1078 Ambler Johnston East             Virginia Tech
Blacksburg, VA 24060-0022       Tel. (540) 232-1389



Reply to: