Prev: Translate between managaed java and unmanaged jvm
Next: Use Processes instead of Threads for Performance
From: jason on 14 May 2010 11:32
On May 14, 10:56 am, Eric Sosman <esos...(a)ieee-dot-org.invalid> wrote:
> On 5/14/2010 10:34 AM, jason wrote:
>
> > [...]
> > when i use my actionlistener on my button, i expect my progressbar in
> > GUI1 to update accordingly as updated by a component update call (ie:
> > component(11).setValue(i)). unforunately it is not doing so.
>
>      The "classical" reason for this behavior is that you are
> running the progress-making action on the Event Dispatch Thread,
> preventing it from responding to changes.  Here's the scenario:
>
>         1) user does mouse stuff
>         2) Swing deciphers mouse stuff
>         2) Swing decides your button has been clicked
>         3) Swing calls your ActionListener's actionPerformed()
>         4) your actionPerformed() runs and returns
>         5) Swing resumes monitoring events
>
> (I'm using "Swing" as shorthand for "Swing, AWT, assorted core
> classes, native code, O/S drivers, and miscellaneous whatnot.")
> The point is that during (4) above, "Swing" is *not* monitoring
> the mouse or the keyboard or anything else: *your* code runs and
> monopolizes the EDT until it returns.  So if your code tries to
> do things to the visible state of a component, nothing (much) will
> show up on the screen until *after* your code finishes.  Dollars
> to doughnuts this is the cause of your difficulty.
>
>      The cure is to avoid doing long-winded things on the EDT.
> If your ActionListener (or whatever) can do its job quickly and
> let any visual changes happen later, fine: Just go ahead and do
> it right there in actionPerformed() or in things it calls.  But
> if the job will take significant time, or if you need the GUI to
> remain responsive while the job makes progress, perform the work
> on a different thread.  Have your ActionListener start a new thread
> or send a "work order" to an existing thread, so actionPerformed()
> can return immediately while the work progresses in parallel.
>
>      All this is described in the on-line tutorial; begin with
> <http://java.sun.com/docs/books/tutorial/uiswing/concurrency/index.html>
>
> --
> Eric Sosman
> esos...(a)ieee-dot-org.invalid

eric,
perfect. that is EXACTLY my issue!
thank you very much!
From: markspace on 14 May 2010 11:35
jason wrote:

> GUI1 - i have approximately 10 components. all working as they should.


I have to echo Lew's advice here. You have one GUI. You have many GUI
components. Some of those components are Components, JComponents,
Windows, etc. But still only one GUI.

Off the top of my head, it sounds like you are trying to add a second
Window to the existing user interface. But I'm not really sure, because
you explain it oddly.

Your terminology makes it difficult to understand you. You say you've
only used GUI components from a client perspective, which I can believe.
Please try to learn a little from this post and use a more standard
(and precise) terminology. You sound like you are not a native English
speaker; is that true?


> when i use my actionlistener on my button, i expect my progressbar in
> GUI1 to update accordingly as updated by a component update call (ie:
> component(11).setValue(i)). unforunately it is not doing so.


As Eric just said, and we all said previously, that is because you have
locked up the EDT (the only means by which the GUI can update) and
prevent it from running.

Please refer to this page again.

<http://java.sun.com/docs/books/tutorial/uiswing/components/progress.html>

Especially this part:

<http://java.sun.com/docs/books/tutorial/uiswing/components/progress.html#bars>

and the source code for that example. It does this:

<http://java.sun.com/docs/books/tutorial/uiswing/examples/components/ProgressBarDemoProject/src/components/ProgressBarDemo.java>

public void actionPerformed(ActionEvent evt) {
startButton.setEnabled(false);
setCursor(Cursor.getPredefinedCursor(Cursor.WAIT_CURSOR));
//Instances of javax.swing.SwingWorker are not reusuable, so
//we create new instances as needed.
task = new Task();
task.addPropertyChangeListener(this);
task.execute();
}

where Task is a SwingWorker, which is just the easiest way of executing
code on a thread other than the EDT. Please review that code for how to
write a SwingWorker (the Task class declaration is right there with the
code).

From: jason on 14 May 2010 12:21
On May 14, 11:35 am, markspace <nos...(a)nowhere.com> wrote:
> jason wrote:
> > GUI1 - i have approximately 10 components. all working as they should.
>
> I have to echo Lew's advice here.  You have one GUI.  You have many GUI
> components.  Some of those components are Components, JComponents,
> Windows, etc.  But still only one GUI.
>
> Off the top of my head, it sounds like you are trying to add a second
> Window to the existing user interface.  But I'm not really sure, because
> you explain it oddly.
>
> Your terminology makes it difficult to understand you.  You say you've
> only used GUI components from a client perspective, which I can believe.
>   Please try to learn a little from this post and use a more standard
> (and precise) terminology.  You sound like you are not a native English
> speaker;  is that true?
>
> > when i use my actionlistener on my button, i expect my progressbar in
> > GUI1 to update accordingly as updated by a component update call (ie:
> > component(11).setValue(i)). unforunately it is not doing so.
>
> As Eric just said, and we all said previously, that is because you have
> locked up the EDT (the only means by which the GUI can update) and
> prevent it from running.
>
> Please refer to this page again.
>
> <http://java.sun.com/docs/books/tutorial/uiswing/components/progress.html>
>
> Especially this part:
>
> <http://java.sun.com/docs/books/tutorial/uiswing/components/progress.h...>
>
> and the source code for that example.  It does this:
>
> <http://java.sun.com/docs/books/tutorial/uiswing/examples/components/P...>
>
>      public void actionPerformed(ActionEvent evt) {
>          startButton.setEnabled(false);
>          setCursor(Cursor.getPredefinedCursor(Cursor.WAIT_CURSOR));
>          //Instances of javax.swing.SwingWorker are not reusuable, so
>          //we create new instances as needed.
>          task = new Task();
>          task.addPropertyChangeListener(this);
>          task.execute();
>      }
>
> where Task is a SwingWorker, which is just the easiest way of executing
> code on a thread other than the EDT.  Please review that code for how to
> write a SwingWorker (the Task class declaration is right there with the
> code).

>You sound like you are not a native English speaker; is that true?
....

>But I'm not really sure, because
> you explain it oddly.
>
> Your terminology makes it difficult to understand you.
it is difficult to explain something one is new to, and something that
one is expanding exposure to. it is easy to express a finite lexicon
of proper terms once one's exposure is complete. in the process of
exposure it is a bit difficult. ie: it is very easy to get the correct
search results when the proper terms are used.

> Off the top of my head, it sounds like you are trying to add a second
> Window to the existing user interface. But I'm not really sure, because
> you explain it oddly.
yes. this is what i am trying to do. a second window with a
JProgressBar.
as stated, i am not stuck on this solution, but it is just an
experiment i was trying which was unsuccessful.
From: Roedy Green on 14 May 2010 21:41
On Thu, 13 May 2010 18:43:17 -0700 (PDT), jason
<jason.mellone(a)gmail.com> wrote, quoted or indirectly quoted someone
who said :

> JProgressBar JProgressBar1=new JProgressBar(0,100);

see http://mindprod.com/jgloss/progress.html

you can't do your progress stuff on the same thread as your GUI work.
You need a SwingWorker or a background thread.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Beauty is our business.
~ Edsger Wybe Dijkstra (born: 1930-05-11 died: 2002-08-06 at age: 72)

Referring to computer science.
From: Arne Vajhøj on 15 May 2010 19:33
On 14-05-2010 21:41, Roedy Green wrote:
> On Thu, 13 May 2010 18:43:17 -0700 (PDT), jason
> <jason.mellone(a)gmail.com> wrote, quoted or indirectly quoted someone
> who said :
>> JProgressBar JProgressBar1=new JProgressBar(0,100);
>
> see http://mindprod.com/jgloss/progress.html
>
> you can't do your progress stuff on the same thread as your GUI work.
> You need a SwingWorker or a background thread.

The JProgessBar calls must be done on the same thread as the
GUI work.

The work taking a long time must be done in some other thread.

Arne


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Translate between managaed java and unmanaged jvm
Next: Use Processes instead of Threads for Performance