Prev: Translate between managaed java and unmanaged jvm
Next: Use Processes instead of Threads for Performance
From: jason on 14 May 2010 10:34
On May 14, 10:26 am, jason <jason.mell...(a)gmail.com> wrote:
> On May 14, 9:51 am, Lew <no...(a)lewscanon.com> wrote:
>
>
>
> > jason wrote:
> > > I have looked more closely at the page you referenced and my main
> > > question is the following:
> > > how would i [sic] go about creating a GUI that accepts input values? i [sic]
> > > envision this second GUI as some sort of function operating in the
> > > following:
> > > [code]
> > > //coming from GUI-1 class:
>
> > > public void actionPerformed(ActionEvent arg0) {
>
> > > for (int i=0;i<=someMaxSize;i++){
>
> > >      MyGUI2class.main(i);
>
> > You definitely will not want to start a new instance of your second "GUI"
> > every time you update a progress bar!
>
> > You aren't talking about two GUIs.  GUI means "graphical user interface".  You
> > have one of those.
>
> > The 'actionPerformed()' method should simply update the value used by the
> > progress bar.  This will take negligible time and thus not tie up the EDT.
>
> > --
> > Lew
>
> i know what a gui is, i have programmed many in different languages
> but am having a hard time updating this progressbar.
>
> currently i have a progressbar in my main gui set to 50 (just so that
> i can see it is registering, which it is). once i click my action
> button the gui animation ceases and the gui becomes a static image of
> itself (progress bar looks like an image of itself as of when i
> clicked the action button). also, the value on the progressbar seems
> unable to be changed.

let me be more specific.

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

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.

with this i thought: maybe if i make a secondary popup window and
allow this second window to house my progressbar and update
accordingly i may have better luck. this is currently where i find
myself. i am not assuming this is the way to go about doing so, but in
my experiments with my first gui i am trying to see what works and
therefore i am not assuming i have the best solution, but am just
trying to reach a solution in general.

any pointers as to how to go about solving this would be appreciated
as my insight into GUI manipulation in java is minimal.

yet, thanks to the help i have received on here so far i have been
able to enlarge my understanding quickly.
From: Lew on 14 May 2010 10:37
jason wrote:
> i [sic] know what a gui is, i [sic] have programmed many in different languages
> but am having a hard time updating this progressbar.

My point wasn't to explain what a GUI is but that you only have one of them,
not two as you've been saying.

If you were such an expert you'd know that already.

> currently i [sic] have a progressbar in my main gui set to 50 (just so that
> i [sic] can see it is registering, which it is). once i [sic] click my action
> button the gui animation ceases and the gui becomes a static image of
> itself (progress bar looks like an image of itself as of when i [sic]
> clicked the action button). also, the value on the progressbar seems
> unable to be changed.

No doubt because you're invoking a new 'main()' each time rather than updating
the one progress bar, as I mentioned in my previous post.

Why don't you provide an SSCCE? This discussion is unlikely to progress far
without it at this point.

<http://sscce.org/>

--
Lew
From: jason on 14 May 2010 10:43
On May 14, 10:37 am, Lew <no...(a)lewscanon.com> wrote:
> jason wrote:
> > i [sic] know what a gui is, i [sic] have programmed many in different languages
> > but am having a hard time updating this progressbar.
>
> My point wasn't to explain what a GUI is but that you only have one of them,
> not two as you've been saying.
>
> If you were such an expert you'd know that already.
>
> > currently i [sic] have a progressbar in my main gui set to 50 (just so that
> > i [sic] can see it is registering, which it is). once i [sic] click my action
> > button the gui animation ceases and the gui becomes a static image of
> > itself (progress bar looks like an image of itself as of when i [sic]
> > clicked the action button). also, the value on the progressbar seems
> > unable to be changed.
>
> No doubt because you're invoking a new 'main()' each time rather than updating
> the one progress bar, as I mentioned in my previous post.
>
> Why don't you provide an SSCCE?  This discussion is unlikely to progress far
> without it at this point.
>
> <http://sscce.org/>
>
> --
> Lew

Lew,
thanks for your input. no need to poke fun at my lack of expertise
with java, i come from a numerical computation background and
therefore the user interface aspect was never really an issue and
those languages which facilitate computation make it easier to
initialize and implement progress bars than more application oriented
languages.

i will provide an example when i am at the machine the code is on.
java is a language i have decided to learn on my own, so any help i
receive is a great help.

i will update this post later today with a ssce.
thanks
From: Lew on 14 May 2010 10:52
jason wrote:
Lew,
> thanks for your input. no need to poke fun at my lack of expertise
> with java [sic], i [sic] come from a numerical computation background and

You misconstrue. I totally am not making fun of your lack of expertise in
Java. My comment about having only one GUI is not Java-specific.

What I was making fun of is your ego reaction to the advice. By taking
offense at some imagined insult not present in the messages, you missed the
points entirely.

--
Lew
From: Eric Sosman on 14 May 2010 10:56
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
esosman(a)ieee-dot-org.invalid
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