Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.gui > #3319

Re: two jframes, and a co

Show all headers | View raw

  To: comp.lang.java.gui
zikester wrote:
> Hi all--
> 
> I'm fairly new to swing programming, and am running into some problems
> with my design.  I'm writing a program that runs multiple trials of an
> experiment.  I have an initial JFrame which allows the users to set
> some settings; a second JFrame is used to show run-time results of the
> experiment, as well as receive user input during the experiment.   A
> non-controller class is used to separate out the "business logic" from
> the display logic, but I think this may be causing problems.
> 
> The control flow goes like this:
> - initial JFrame starts up
> - user hits "go!"
> - control is passed to the controller
> 
> Regarding the controller class:
> --- it initializes and displays the Results JFrame, setting up some
> event listeners to handle the user input from the Results widget
> ( swing events on the jframe are converted into "generic" non-swing
> events seen by the controller )
> --- each trial of the experiment is very linear: input is received, a
> calculation is performed, then an output is produced
> --- the experimental input is received in real-time from two possible
> sources, one is a widget on the results panel ( from the user ), the
> other is a timer thread from the controller class ( cpu AI )
> --- an input "lockbox" ( synchronized access to the input variable )
> is used to allow both input threads to write to the same place, and
> the experiment thread to read it as well
> --- the controller class runs the experiment, placing the trials in a
> for-loop.  At each iteration, it calls a "waitForInput()" method that
> loops peeks at the lockbox until input is received, sleeping for x ms
> at each iteration.  When the input is found, it processes the
> experimental input, calculates the output, updates the display frame,
> then iterates the trial count.
> --- when trialNum trials have completed, the experiment thread
> exits.

I recommend you print the above, put it in an envelope addressed to 
yourself marked "do not open until 2013". If it makes no sense to you 
then, you'll understand why people ask for SSCCEs.


> 
> Right now, the second frame hangs upon display ( while the controller
> is running ).  Note that if I ditch the initial frame and fire up the
> controller directly, no problems.  Why is this?

That's easy. Running non-GUI code on the EDT is the number one cause of 
GUI hang/freeze/lockups IME.

> 
> Secondly, is this a really messed up design?

To me, using sleep is a sign of messed up design. That's because I only 
ever use it to simulate the effect of slow databases on my GUI code so 
that I can smoke out timing issues. This doesn't mean there aren't good 
uses of sleep, but waiting for events probably isn't one of them.


> - I was trying to separate out business from display logic, and it
> does seem to be cleaner than munging both controller/display
> together.

I think most people would say that is good practise.


> - I decided for the controller to dominate the display, rather than
> vice versa.  Perhaps this is thinking too procedurally, but I was
> thinking that the display could totally change, and the controller
> could stay largely the same.  Fundamentally, I thought this modelled
> the natural dependency of the results display on the results logic.

?


> - Is there a way for me to run the experiments procedurally in a big
> for loop that waits for input, 

Yes.

> without causing headaches?  

No.


> The
> alternative I can think of is to have the controller be passive, and
> react to events.  That means instead of a for loop, I need to use
> promote some of those iterator variables into class members, and say,
> each time a user input is fired off

Your design sounds overly complicated to me. That's probably because I 
haven't understood your description.

I'd have a JFrame with TextFields, JSpinners, etc for user input and a 
big "Go" button that users would click every time they've entered a new 
set of "experimental input". An ActionListener on the "Go" button would 
open a modal JDialog with a JProgressBar and some component(s) that 
eventually displays the results. The "Go" button's ActionListener would 
also use SwingWorker to start a worker thread that "processes the 
experimental input". The done() method of the SwingWorker would update 
the "results" widgets. SwingWorker has provision for progress 
notifications that can be used to update a JProgressBar.

If necessary, I'd use Listeners of some sort to further organise the 
code according to MVC pattern. I suspect this wouldn't be needed.


> 
> Any good reading you might suggest as well related to this topic?
> 

http://java.sun.com/docs/books/tutorial/uiswing/concurrency/index.html
http://en.wikipedia.org/wiki/Model-view-controller
http://java.sun.com/blueprints/patterns/MVC.html

I'd use Google to search this newsgroup for book recommendations 
concerning OO design patterns.

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

Back to comp.lang.java.gui | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

two jframes, and a contro "zikester" <zikester@THRWHITE.remove-dii-this> - 2011-04-27 15:44 +0000
  Re: two jframes, and a co "RedGrittyBrick" <redgrittybrick@THRWHITE.remove-dii-this> - 2011-04-27 15:44 +0000
    Re: two jframes, and a co "zikester" <zikester@THRWHITE.remove-dii-this> - 2011-04-27 15:44 +0000

csiph-web