Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   Best way to force a JComponent to repaint itself (http://www.velocityreviews.com/forums/t630690-best-way-to-force-a-jcomponent-to-repaint-itself.html)

zerg 08-14-2008 02:21 AM

Best way to force a JComponent to repaint itself
 
What's the best way to force a JComponent to repaint itself? I've got
three candidates:

revalidate()
repaint()
update()

Roedy Green 08-14-2008 02:33 AM

Re: Best way to force a JComponent to repaint itself
 
On Wed, 13 Aug 2008 22:21:17 -0400, zerg <zerg@zerg.org> wrote, quoted
or indirectly quoted someone who said :

>What's the best way to force a JComponent to repaint itself? I've got
>three candidates:
>
>revalidate()
>repaint()
>update()


look those words up in the Java glossary so you understand what each
are for.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Knute Johnson 08-14-2008 04:00 AM

Re: Best way to force a JComponent to repaint itself
 
zerg wrote:
> What's the best way to force a JComponent to repaint itself? I've got
> three candidates:
>
> revalidate()
> repaint()
> update()


Read Roedy's post and then tell us what you really want to do and what
you've been doing before that.

--

Knute Johnson
email s/nospam/knute2008/

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

zerg 08-14-2008 04:35 AM

Re: Best way to force a JComponent to repaint itself
 
Knute Johnson wrote:
> zerg wrote:
>> What's the best way to force a JComponent to repaint itself? I've got
>> three candidates:
>>
>> revalidate()
>> repaint()
>> update()

>
> Read Roedy's post and then tell us what you really want to do and what
> you've been doing before that.


I begin to suspect that there's some sort of unwritten code here that
forbids the giving of a straight answer.

In case it somehow matters, I've implemented a custom JList subclass
with a custom cell renderer and some other custom behavior. In response
to certain new set methods, the behavior of the cell renderer changes,
and the visible portion of the list obviously needs to be repainted when
this occurs.

I suppose I could do something hackish like set the list's ListModel to
the existing ListModel ... :P

(Also, is there a way to get the NetBeans GUI editor to recognize new
component classes? Or, perhaps better, to simply bypass it and code the
UI manually, but still get the FrameView saving and restoring of window
state? And is the list definitely only going to call on the cell
renderer to paint the visible cells at any given time? I would prefer
this to be able to scale well with large lists, potentially 10,000 items
or more, with the ListModel storing say 10,000 Integers or other such
handles rather than larger objects that may be retrieved from disk or a
DB on demand.)

zerg 08-14-2008 04:43 AM

Re: Best way to force a JComponent to repaint itself
 
zerg wrote:
> Knute Johnson wrote:
>> zerg wrote:
>>> What's the best way to force a JComponent to repaint itself? I've got
>>> three candidates:
>>>
>>> revalidate()
>>> repaint()
>>> update()

>>
>> Read Roedy's post and then tell us what you really want to do and what
>> you've been doing before that.

>
> I begin to suspect that there's some sort of unwritten code here that
> forbids the giving of a straight answer.


Which maybe extends to Sun itself -- I found the API docs less than 100%
clear here, and even the Java Tutorial.

Provisionally, I'm using "repaint(getBounds())"; why there isn't a
no-args repaint-the-whole-thing method will probably remain an enduring
mystery long after my app has matured, had its heyday, and become
obsolete...

zerg 08-14-2008 05:12 AM

Re: Best way to force a JComponent to repaint itself
 
Peter Duniho wrote:
> On Wed, 13 Aug 2008 21:35:50 -0700, zerg <zerg@zerg.org> wrote:
>> I begin to suspect that there's some sort of unwritten code here that
>> forbids the giving of a straight answer.

>
> Forgive us if we suspect that there's some sort of unwritten code among
> questioners that forbids the inspection of the relevant documentation
> before asking a question.


Suspect what you will, but I did indeed examine the JComponent API docs,
and there were three public methods associated with repainting -- not
counting that repaint() had two overloads.

I may have been somewhat biased by what I was specifically searching
for, namely a no-argument method for "repaint the whole component". It
looks like maybe that is simply lacking.

> Either you never bothered to even read the documentation, or there's
> something more to your question than simply "what's the API-approved to
> force a repaint?" Either way, your question isn't a well-formed one.


Anything that I say is well-formed, and I am not in the mood to be
publicly insulted by you or anyone else here. I came here asking for
advice in good faith and I don't appreciate being treated in such a manner.

> If I understand your follow-up correctly, you simply have some sort of
> custom component that needs to be redrawn when internal state changes
> that would be reflected visually. Assuming that's the correct
> interpretation, then the documentation does in fact provide all of the
> necessary information you need.


Perhaps it does, but it is less than clear, for whatever reason.
Probably because the API docs are organized around a
what-this-thingamajig-does scheme, while the tutorial, though organized
around a how-to-do-X scheme, rather glosses over repainting of
components, other than to make it clear that to paint custom stuff
(rather than just at custom times) you override paintComponent.

> If there's something about the documentation that is confusing you,
> there's no shame in being specific about that and asking for help with
> it.


That's more or less what I did, except that I simply asked directly for
the answer to the question that I had, instead of for clarification of a
particular bit of the docs.

> If you have read the documentation and need some help, then say so
> and be specific about what kind of help you need.


Fine. From now on, when I have a highly specific question like "what is
the best way to force a JComponent to repaint itself?", instead of just
asking "what is the best way to force a JComponent to repaint itself?",
I will do as you advise here and say "I've read the documentation, but
still have a question: what is the best way to force a JComponent to
repaint itself?" -- satisfied?

> If you simply ask a question that the documentation does in fact
> answer, the most obvious explanation is that you haven't bothered
> to look at the documentation at all.


Sometimes the most obvious explanation is wrong. Regardless, what the
explanation is is not relevant. The question I asked was about
JComponent painting, not about what the most likely explanation was for
why I asked the question. If you'd please just focus on the actual
content of a post asking a question, and refrain from speculating about
why the poster might have asked it or other unimportant things like that
that have no bearing on things, I think people might appreciate that.
People post questions here to get them answered, not to get sidetracked
into unrelated topics to satisfy your curiosity as to peoples' motives
in asking questions or for any similar such reason.

It's best to just take peoples' questions at face value, and give them a
simple, correct answer that they can apply immediately. I don't know
about you, but when I have a question, I'm generally interested in
getting an answer as quickly as possible, and one that can be applied
immediately. Therefore I've already read all the obviously-relevant
documentation, since if it has the answer in a clear and unambiguous
form that will get me moving much quicker than waiting for someone to
reply on a Usenet group. If that doesn't suffice, then I ask a question
here, and at that point I'm not going to be pleased if instead of the
one iteration of post-reply that it SHOULD take for me to get an answer
back, it ends up taking two or three because people want to satisfy
their idle curiosity as to why I'm asking the question, and of course if
they simply answered it straight away, I might go away and not answer
their questions! So they withhold my answer until they have satisfied
their curiosity -- wasting my time and everyone's bandwidth with matters
that are tangential, at best, to the purpose of this newsgroup.

Please don't do that any more. I find it annoying. If I ask "how to do
X", please just tell me, in simple terms, how to do X. If you think the
documentation should have answered it for me, well, apparently it
didn't. If you want, you can certainly point to the bit of the
documentation that you think unambiguously answers the question and ask
me why I didn't apparently one of find it relevant enough to look at or
find it clear and certain enough to use, AT THE SAME TIME as supplying
the actual answer. Then, since I'll have the answer I need to continue
with my work without delay, I am likely to be able to find some time
later to satisfy your curiosity a bit, and therefore I am likely to
answer, and to be much less annoyed and irritated when I do.

Thank you.

Knute Johnson 08-14-2008 05:15 AM

Re: Best way to force a JComponent to repaint itself
 
zerg wrote:
> Knute Johnson wrote:
>> zerg wrote:
>>> What's the best way to force a JComponent to repaint itself? I've got
>>> three candidates:
>>>
>>> revalidate()
>>> repaint()
>>> update()

>>
>> Read Roedy's post and then tell us what you really want to do and what
>> you've been doing before that.

>
> I begin to suspect that there's some sort of unwritten code here that
> forbids the giving of a straight answer.


Well forgive me but if you want to repaint() something repaint() it.

> In case it somehow matters, I've implemented a custom JList subclass
> with a custom cell renderer and some other custom behavior. In response
> to certain new set methods, the behavior of the cell renderer changes,
> and the visible portion of the list obviously needs to be repainted when
> this occurs.


So you are changing some data in your ListModel and it isn't being
reflected in your JList? You've got other problems than repaint(). Are
you adding or removing components? Are you making your changes to your
ListModel on the EDT?

> I suppose I could do something hackish like set the list's ListModel to
> the existing ListModel ... :P
>
> (Also, is there a way to get the NetBeans GUI editor to recognize new
> component classes? Or, perhaps better, to simply bypass it and code the
> UI manually, but still get the FrameView saving and restoring of window
> state? And is the list definitely only going to call on the cell
> renderer to paint the visible cells at any given time? I would prefer
> this to be able to scale well with large lists, potentially 10,000 items
> or more, with the ListModel storing say 10,000 Integers or other such
> handles rather than larger objects that may be retrieved from disk or a
> DB on demand.)



--

Knute Johnson
email s/nospam/knute2008/

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

Knute Johnson 08-14-2008 05:17 AM

Re: Best way to force a JComponent to repaint itself
 
zerg wrote:
> zerg wrote:
>> Knute Johnson wrote:
>>> zerg wrote:
>>>> What's the best way to force a JComponent to repaint itself? I've
>>>> got three candidates:
>>>>
>>>> revalidate()
>>>> repaint()
>>>> update()
>>>
>>> Read Roedy's post and then tell us what you really want to do and
>>> what you've been doing before that.

>>
>> I begin to suspect that there's some sort of unwritten code here that
>> forbids the giving of a straight answer.

>
> Which maybe extends to Sun itself -- I found the API docs less than 100%
> clear here, and even the Java Tutorial.


No doubt.

> Provisionally, I'm using "repaint(getBounds())"; why there isn't a
> no-args repaint-the-whole-thing method will probably remain an enduring
> mystery long after my app has matured, had its heyday, and become
> obsolete...


If you had looked at the docs you would have seen that the no-arg
repaint() belongs to Component.

So tell us, are you updating your ListModel on the EDT?

--

Knute Johnson
email s/nospam/knute2008/

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

zerg 08-14-2008 05:27 AM

Re: Best way to force a JComponent to repaint itself
 
Peter Duniho wrote:
> On Wed, 13 Aug 2008 21:43:46 -0700, zerg <zerg@zerg.org> wrote:
>> Which maybe extends to Sun itself -- I found the API docs less than
>> 100% clear here, and even the Java Tutorial.

>
> I admit that the Java SDK docs aren't the best docs I've ever seen. But
> in this case, you know the exact names of the methods in question and
> can easily examine the documentation for each to learn what each is
> for. I don't see any ambiguity that would lead to a misunderstanding here.


Let's see. And keep in mind that I was looking for "repaint the whole
shebang" here.

repaint(ints, or Rectangle)

Adds the specified region to the dirty region list if the component is
showing. The component will be repainted after all of the currently
pending events have been dispatched.

-- Looks promising, but I'm looking for something simpler than figuring
out some rectangle and then telling it to repaint that. Can't I just
tell it to repaint everything?

revalidate()

Supports deferred automatic layout.

Calls invalidate and then [technical details]

This method will automatically be called on this component when a
property value changes such that size, location, or internal layout of
this component has been affected.

-- My JList's internal layout may have changed, since the cell renderer
may be producing different-sized cells from before, but my set methods
don't actually change the cell renderer itself, only its behavior, so
this won't get called automatically without my doing something. Perhaps
I should call it, so that my JList subclass calls it automatically in
these circumstances? Another promising sign is that this is a zero-arg
method.

update(Graphics g)

Calls paint.

-- Calls paint. Called update. Issue: takes a parameter again, this time
a Graphics.


Perhaps now it's apparent why it's not clear from these whether, in this
particular case, I should use repaint itself or use one of these other
methods that are involved in getting the component to display itself
correctly after something has been updated.

>> Provisionally, I'm using "repaint(getBounds())"; why there isn't a
>> no-args repaint-the-whole-thing method will probably remain an
>> enduring mystery long after my app has matured, had its heyday, and
>> become obsolete...

>
> The only mystery is how you missed it:
> http://java.sun.com/javase/6/docs/ap....html#repaint()


See above, though I take it you agree that repaint(getBounds()) is the
best method.

It looks like the API is missing a no-arg "repaint()" with a doc comment
of "Repaints this component." for these kinds of cases. "Adds a
rectangle to the dirty rectangle list" suggests something that is mainly
intended for a) subclasses that have custom-painting code and are
implementing a container or something similar and b) delegation from
higher-level update-notification methods, perhaps update or revalidate.
If this is not actually the case, as you appear to be implying, then the
docs are indeed less than clear -- not on what repaint() DOES, but on
who should be using it rather than using something else, perhaps at a
higher level of abstraction.

(I take it a JList doesn't need revalidating even if the cell size may
have changed?)

zerg 08-14-2008 05:29 AM

Re: Best way to force a JComponent to repaint itself
 
Knute Johnson wrote:
> zerg wrote:
>> I begin to suspect that there's some sort of unwritten code here that
>> forbids the giving of a straight answer.

>
> Well forgive me but if you want to repaint() something repaint() it.


The question was whether it's better to repaint() it directly or by
calling a method at a higher level of abstraction that in turn calls
repaint().

> So you are changing some data in your ListModel and it isn't being
> reflected in your JList?


No. I'm changing a subclass-specific setting that affects presentation
of the data, and the change is visible to the cell renderer but not, of
course, to the pre-existing JList code.

>> (Also, is there a way to get the NetBeans GUI editor to recognize new
>> component classes? Or, perhaps better, to simply bypass it and code
>> the UI manually, but still get the FrameView saving and restoring of
>> window state? And is the list definitely only going to call on the
>> cell renderer to paint the visible cells at any given time? I would
>> prefer this to be able to scale well with large lists, potentially
>> 10,000 items or more, with the ListModel storing say 10,000 Integers
>> or other such handles rather than larger objects that may be retrieved
>> from disk or a DB on demand.)


Nobody has yet answered any of this.


All times are GMT. The time now is 01:53 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.