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 ...

(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 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...

Peter Duniho wrote:
> On Wed, 13 Aug 2008 21:35:50 -0700, zerg <> 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.

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 ...
>
> (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 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.

Peter Duniho wrote:
> On Wed, 13 Aug 2008 21:43:46 -0700, zerg <> 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/api/java/awt/Component.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?)

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.)

zerg wrote:
> Peter Duniho wrote:
>> On Wed, 13 Aug 2008 21:35:50 -0700, zerg <> 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.

You can get as mad as you want but people are really trying to help you.
And having been around here for a while, when someone asks "What
method do I use to repaint() a JComponent," we get sort of suspicious
because repainting is rarely the solution to anything.

And whether you believe it or not there IS a no-arg repaint() method.
It belongs to JComponent.

So, this is my last attempt to help you. Answer the questions or not,
your choice.

1) Are you updating your ListModel on the EDT?

2) Are you doing long running tasks on the EDT (in a listener for example)?

Knute Johnson wrote:
> You can get as mad as you want but people are really trying to help you.

That's not what bothers me. It's that they are often remarkably
unsuccessful at SUCCEEDING that bothers me, and in fairly silly ways.
For example, if you know, for sure, the exact answer to the question,
and you don't include it in your response, well, that's just plain silly!
> And having been around here for a while, when someone asks "What method
> do I use to repaint() a JComponent," we get sort of suspicious because
> repainting is rarely the solution to anything.

That's for the programmer to decide, not you. I know my code far better
than you do, and I don't see why you need to know jack about it in order
to provide a simple, straight answer for a simple question. If I had a
design-related conundrum I would ask a design-related question. When I
have a "how to do X very specific thing with Y" type of question, and
ask it, I want an equally specific answer, not some kind of inquest
based on some suspicion, based on very little evidence, that there's
some sort of problem with my design. I ask for what I want, but you
reply not with what I want but with your own mixture of suspicions, idle
questions, and sometimes outright insults.

My guess (and now I'm the one speculating about you with limited
information, instead of just giving a straightforward answer -- let's
see how you like it) is that it stems from a widespread belief among the
people here that nobody who asks a question here has the faintest clue
what the hell they're doing, and all need guidance as if from a teacher
or something instead of simple technical-support like responses that
directly answer specific questions.

Maybe many of the people who post here ARE that clueless. But it's
insulting to the rest of us when you treat us as if we ALL are, and it
obstructs just getting to the point as quickly as possible and then
moving on.
> And whether you believe it or not there IS a no-arg repaint() method. It
> belongs to JComponent.

JComponent has no no-arg repaint() method save, according to another
post to this thread, one it inherits from java.awt.Component. Of course,
since I was not looking at the AWT docs, only JList and JComponent, and
expecting anything generally useful for Swing components to be in the
latter in particular, I didn't know about it earlier.
> 1) Are you updating your ListModel on the EDT?
>
> 2) Are you doing long running tasks on the EDT (in a listener for example)?
>
> 3) Are you adding or removing components to your JList?

Perhaps I didn't make it clear enough in my previous post to this
thread. I have not finished the component and begun testing it yet. When
I do, I will of course observe normal Swing thread-safety procedures and
avoid doing long tasks on the EDT. (I am concerned about the need to
update the ListModel on the EDT though; it may be necessary eventually
to add large numbers of items, perhaps even tens of thousands, all in
one big bolus, which would tie up the EDT. Perhaps adding smaller
batches at a time, letting the EDT get some work done elsewhere, then
adding more, etc.; but then the list control is likely to keep
repainting itself until the job's done. Argh.)

The repaint issue has nothing to do with any observed problem with the
class. It occurred while still coding the first draft of the class, as I
wrote some methods to set some properties specific to my class that will
affect the cell renderer's rendering. Of course, this means that the
list should repaint itself, and at the same time since none of JList's
own setters have been invoked, the repaint won't have been triggered as
a side effect of anything in my setters, and so has to be scheduled
explicitly. (And I STILL don't know if I should revalidate in cases
where the cells may have changed size. Maybe it's time a better guide
specifically for component subclassers got written somewhere.)

(Convinced that I actually, honestly DO know what the heck I'm doing
now? )

Peter Duniho wrote:
> On Wed, 13 Aug 2008 22:27:01 -0700, zerg <> wrote:
>> 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,
>
> Yes, it does. In fact, it looks just like what you asked for.

Not quite, since "what I asked for" was a simple, no-arg "repaint-me".
>> 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?
>
> Yes, you can. Even ignoring the fact that if you don't know what
> rectangle describes the area in which you're drawing, you've got serious
> problems

Could you PLEASE knock it off with the insults and frequent insinuations
that I don't know what the hell I'm doing? Trust me -- I do. I just
didn't want to have to MESS with digging up the component's bounds and
then passing them around if I didn't have to.

Stop second-guessing my motives or reasons for doing things!! That is
not why I came to this newsgroup.
> there is in fact a "no parameter" overload of the method (see
> below).

In an AWT class, apparently, where I of course didn't go looking for it
since I'm working with Swing.
>> 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.
>
> As the description says, this method is for things that affect layout.

Internal layout. My cell renderer may have changed size under these
circumstances. That would seem to change the internal layout of the
rendered JList.
> Either the control itself has moved or changed size, or something in it
> needs to go through layout again. This obviously has nothing to do with
> simply forcing a repaint.

It "obviously" no such thing. It clearly has to do with circumstances
that also clearly require a repaint.

What may be obvious to people that have been digging around in the guts
of Swing for ages may be less so to people that are knowledgeable about
Java in general, knowledgeable about more commonplace uses of Swing than
custom component creation, and have access to the API docs, but haven't
done much actual custom-component implementation before.

Must you subject everyone who has not done much custom-component
implementation before and then asks about a related topic to public,
implied insults? It seems rather pointless for you to do so.
> Would you rather have a method that has no arguments, or one that does
> what you want?

I would rather have one that has both traits, of course, since what I'm
looking for is simply a "repaint me completely" method.
>> update(Graphics g)
>>
>> Calls paint.
>
> And when you looked at the description of the paint() method, what did
> you find?

Nothing. I didn't look at the description of the paint method, because I
was not interested in the implementation details of the JComponent
class, only its interface to subclasses and its public interface.
>> -- Calls paint. Called update. Issue: takes a parameter again, this
>> time a Graphics.
>
> Honestly, I don't know what your deal about the parameter is. The fact
> is, a method that does exactly what you want exists, but you need to be
> doing a better job looking at what the methods _do_

I don't need to be doing a better job of anything, and I'll thank you to
quit publicly insuinuating or outright asserting otherwise!

I read all of the descriptions of what the methods do. It was clear that
repaint() could be employed to do what I wanted. What was NOT clear was
whether, for this case, that was the BEST way or if there was a
higher-abstraction-level method that was better-suited instead.
Unfortunately, getting an actual honest, friendly answer to that
question has proven to be unexpectedly difficult, though certainly not
for lack of trying on my part.
> Once you find a method that has
> _functionality_ that you want, then you can look for an overload with a
> signature you prefer.

I did that, and saw none in JComponent's method list. So I looked for
methods with other names that might call one of those two repaints.
>> 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.
>
> No, it's not apparent to me at all why it's not clear to you.

Fine. It doesn't matter. I don't need you to understand why something
isn't clear to me or why I'm asking a particular question, just so long
as you're willing to ANSWER that question, as straightforwardly as
possible, and with none of the attitude or curmudgeonliness that most of
your replies veritably REEK of.

If you'd prefer not to answer a question, for some particular reason,
you could always not post any kind of response to it at all. One thing I
will certainly not tolerate, however, is any sort of response that
implies, in front of a worldwide audience no less, that you think I'm in
some way incompetent. Stop doing that!
> Of those three methods, two are obviously not what you want

They are not "obviously" not what I want, not based on a quick reading
of their Javadocs. Perhaps to someone with a lot of experience working
with Swing's internals, but not to someone who hasn't previously needed
to directly tell a component to repaint itself and is only now checking
the most obviously-relevant docs.

Since I didn't see a no-arg repaint() listed next to the two with
arguments, I looked for other methods that might represent a higher
level of abstraction for managing repainting than specifying particular
subsets to repaint. I don't think that I was in any way, shape, or form
wrong for doing so, and I resent your repeatedly and publicly
insinuating otherwise. Stop doing so.
> and of one of those two, the documentation related to it even
> _explicitly_ says to not call it directly and instead use the repaint()
> method for what you're trying to do.

That may be true in the copy of the documentation you looked at, but it
is not in mine. Don't assume that everyone is reading the same copy!

But why assume? I stated in an earlier post what my copy of the docs
said for those methods. To reiterate and elaborate, they said:

-- method #1 --

Supports deferred automatic layout.

Calls invalidate and then adds this component's validateRoot to a list
of components that need to be validated. Validation will occur after all
currently pending events have been dispatched. In other words after this
method is called, the first validateRoot (if any) found when walking up
the containment hierarchy of this component will be validated. By
default, JRootPane, JScrollPane, and JTextField return true from
isValidateRoot.

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. This automatic updating differs from
the AWT because programs generally no longer need to invoke validate to
get the contents of the GUI to update.

-- method #2 --

Calls paint. Doesn't clear the background but see ComponentUI.update,
which is called by paintComponent.

-- end --

The above are the full description blocks, quoted verbatim, from my copy
of the docs (Javaâ„¢ Platform Standard Ed. 6 DRAFT rc-b104, so pretty up
to date I think, for what it's worth) -- no mention of calling repaint
instead in either block. See for yourself.

It's bad enough that you frequently and inexplicably insult me, even
though I've never done you any harm or been mean to you at all. It's
worse when you do so based on completely faulty premises, as occurred in
this particular instances. Please stop doing that. I did not ask anyone
here for their opinions on my competence or any other such opinions that
they might hold. I asked, instead, what the best method was for
repainting a component. A simple, straightforward question. So why the
heck have you turned it into an inquisition? It's like I asked whether
or not the Sun goes around the Earth during the goddamn Spanish
Inquisition! I thought humanity had outgrown that kind of behavior five
hundred goddamn years ago! Sheesh!
>> See above, though I take it you agree that repaint(getBounds()) is the
>> best method.
>
> You keep saying you want a method without arguments. Did you bother to
> look at the description of the method at the URL I provided?

You pointed to an AWT method for some reason. I was looking for a Swing
method, specifically a JComponent method. There were two repaint methods
in JComponent. Why would I go looking somewhere else entirely for a third?
> really, you have no excuse

This is exactly the kind of nasty, insulting, counter-productive, and
off-the-topic pointlessness that I have asked you repeatedly to dispense
with. Can we not focus on only what's relevant here? (Your personal
opinion of me is emphatically NOT relevant to ANYTHING here. By now, I'm
well aware of it, so the only reason I can think of for your repeating
it is that you want to ensure it reaches the widest possible audience,
which I emphatically do NOT want, so STOP IT. Grrr.)
>> It looks like the API is missing a no-arg "repaint()" with a doc
>> comment of "Repaints this component." for these kinds of cases.
>
> I don't know how much clearer I can be. I gave you the URL for the
> exact method you're looking for.

(The insulting and off-topic twaddle from the end of your post has been
deleted unread. Please don't waste my time with that sort of crap again.)

In a place where I didn't look, and where I had no reason to look, since
it's in a completely different section of the API documentation. Perhaps
if it had been listed right next to the other two repaint methods? But
no, it can't possibly be the case that the docs are GENUINELY not 100%
perfect in structure and content, can it? Oh, no, if anyone has a
question that the docs do sorta-obscurely answer, then that person is
automatically a complete idiot and the only reasonable response to their
question is to announce this, loudly and publicly!

No, of course not. The only reasonable response to their question is to
answer it, maybe also mention where in the docs the answer IS found, and
leave your personal opinion of the person who asked the question
completely out of it. Those sorts of opinions should be kept to
yourself. It accomplishes nothing useful to publicly broadcast it, let
alone to do so frequently and repetitiously, and it does annoy people
and may even provoke a flamewar.

Fortunately for you, I'm not the type to stoop to that level and open up
with both barrels. Next time you behave this way when someone asks a
question in good faith, you may not be so fortunate, so watch it.

And while we're off-topic:
1. Is there a way to edit quoted text in Thunderbird to reflow it
after trimming it that doesn't cause it to get mangled OR
require jumping through hoops to make the edited quoted text
all stay blue?
2. Why does selecting something in Firefox and hitting control-C
seem to copy the selected text to the clipboard only some of
the time? This is a repeated nuisance when excerpting from
the javadocs for threads like this one.

Peter Duniho wrote:
> On Wed, 13 Aug 2008 22:30:57 -0700, zerg <> wrote:
>> I DID look at the docs -- the JList and JComponent docs. Why would I
>> be poking around in the AWT docs? I'm obviously using Swing.
>
> Because Swing is built on top of AWT.
>
> JComponent inherits Component. You can't understand JComponent without
> understanding Component.

The same mistake you've made several times before. You assume that I
seek to thoroughly understand JComponent. I don't. I seek to use it in a
particular way at this particular time.

You're not teaching school. You're answering specific questions posed in
a technical newsgroup. The object of the game is for the guy asking the
question to get a precise and specific answer in the shortest time
possible, not for you to turn them on to the wonders of learning and
ensure that they are prepared to pass the end-of-term exam.

There is no end-of-term exam. There is only whether or not, at the end
of the day, they have gotten their work done and have not fallen behind
any schedule that might apply. To whatever extent you waste their time
with irrelevancies and to-you-fascinating side diversions such as
learning the implementation and internals of a Java class in depth, you
are doing them a disservice.

Please just answer the question forthrightly, with perhaps a pointer to
any docs you found relevant that the question's asker apparently missed
or found unclear, and leave it at that, or else ignore the question
entirely.

If I want to thoroughly understand the internals of something from the
standard library I have the source and I'll go there before I ask you.
If I want to be insulted and have my motives questioned, I'll look up
psychologists in the yellow pages. They charge money but they also don't
blab their speculations and beliefs about their patients in a public
forum.

(If I ever want to be insulted and have my motives questioned IN PUBLIC,
I'll run for public office. And start seeing a psychologist with a
self-evaluation-prompted suspected diagnosis of masochism. )
>> I'm not updating it at all yet; I haven't gotten this class finished
>> yet. Testing begins tomorrow, and yes, I fully intend to only update
>> things on the EDT.
>
> "Fully intend to" is silly. There's no excuse for not doing it that way
> from the outset.

There you go again. I now suspect that you're intentionally twisting and
misinterpreting things purely for the purpose of insulting me.

If you'd bother to actually read my post IN ITS ENTIRETY, you'd know
that I haven't written any code that USES the new class at all yet. In
particular, nothing yet actually calls the thing with an actual
ListModel or does anything else to an instance either on or off the EDT.
I stated that I intend to only access these things on the EDT once I
have code that access them at all. You purposely selectively quoted and
twisted that to imply that I had non-working code that updates stuff off
the EDT that I plan to change tomorrow, which is emphatically NOT the case.

Stop this nonsense at once. I am no longer interested in anything you
have to say, and I have finally gotten answers to most of my questions,
so please do not post to this thread again.
> It's _harder_ to write the code wrong and then fix it
> than it is to just do it right in the first place.

I fully intend to do it right in the first place. The code you claim I
wrote wrong I have in fact not yet written at all, and I said as much in
my earlier post. You even quoted that bit, above: "I'm not updating it
at all yet".

Now, since it's become apparent that now your sole purpose in posting to
this thread is to insult me (whatever it might have been earlier) and
try to provoke a flamewar, and it should now be becoming quite apparent
to you that I refuse to oblige by losing my cool, perhaps you can let
this drop and go insult some OTHER newcomer to this newsgroup?

Peter Duniho wrote:
> On Wed, 13 Aug 2008 22:12:33 -0700, zerg <> wrote:
>
>> 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 count FIVE overloads of repaint().

In the classes themselves, yes. In the JComponent method listing in the
API documentation, there are two. It is the JComponent method listing in
the API documentation that I was consulting, for obvious reasons.
> Java is object-oriented programming. You have to look at

Rest of pedantic and rather insulting paragraph deleted. Have I not made
it abundantly clear by now that your condescending and insulting
attitude is unwelcome and you should not reply to me with such an
attitude again? Either reply neutrally, or reply in a friendly manner,
or do not reply at all. (How you reply to somebody other than me is, of
course, between you and them.)
>> 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.
>
> Well, unfortunately for you, you're not in a position to dictate

Rest of hostility deleted.

What the hell is your problem? Why are you being hostile toward me, when
I had never done anything malicious to you, or even inadvertently
slighted you?

Actually, don't answer that. It doesn't matter. Your opinion of me is
not of any interest to me. Only the answer to whatever question I asked.
When you have a nasty opinion of someone, for whatever reason, and it's
not a politician or some other important public figure, you should keep
it to yourself -- didn't your mother teach you any manners?

Please just answer each question or ignore it, WITHOUT slipping in any
snide remarks, off-topic asides, hostility, or other pointlessness that
can serve no useful purpose but does risk starting a fight.
> People get tired of responding to questions that are easily answered
> simply by looking at the documentation.

The problem is when people form opinions of PEOPLE, based on their
OPINION of what is "easily" answered "simply" by looking at the
documentation, and then BROADCAST that opinion for some stupid reason
instead of just keeping it to themselves!
> When you make your question look like one of those, you're not going
> to get the answer you want

I didn't make my question look like anything in particular. I simply
posted a good-faith question that had a simple and straightforward
answer, but not one that *I* found obvious from perusing the portions of
the docs that were immediately relevant.

If you will not answer properly questions that YOU THINK, in YOUR HUMBLE
OPINION, are "stupid", then you should not post any follow-up to those
questions at all. You should NOT post a bunch of insults, or pry into
other peoples' business, or tell the world that you refuse to answer
"stupid" questions like you just did above. You should simply ignore it
if you are unwilling to answer it properly, with an actual, honest answer.

What about that is so goddamn difficult for you to understand? It's
Manners 101, for God's sake. Everyone is supposed to learn basic manners
by the time their age is two digits long. Unfortunately, the internet
appears to be populated with a lot of people who either somehow missed
out on that particular part of their grade-school curriculum or seem to
think they needn't bother when they're online because "it's all just
numbers and code, not real people" (yes, I've actually heard this lame
excuse, and on more than one occasion, in various places for various
online misbehaviors) or because they simply feel they can get away with
it because whoever they're treating poorly isn't physically present to
punch them in the goddamn nose.

To which my answer is, "Would you be this rude over the goddamn phone?
No? Then you shouldn't be over the goddamn Internet, either!"
>> 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.
>
> Or, in other words, what I said you should do is MUCH more than what you
> actually did.

What you said I should do was completely irrelevant to the question that
I asked. (To be relevant, it would have to have taken the form of a
snippet of Java code.)
> There's nothing at all in your original post to suggest
> that you had bothered to look at anything in the documentation.

How utterly fascinating. And irrelevant. I asked a question about
something other than the documentation. Your role is then to answer it
or ignore it, whichever you please, not to answer something completely
unrelated to the question actually asked, ask questions of your own, or
(especially) start badmouthing people in public for no good reason.

If you insist that every question contain some remark asserting that the
poster did read some documentation, then I will happily oblige and add
boilerplate to that effect to every question that I ask here in the
future, silly though that seems to me.

And to top it off, you are WRONG. There IS something in my original post
to suggest that I looked at the documentation. There are three method
names. Where did you think I got my three candidates? Out of a hat? Of
course not -- I got them by browsing the list of JComponent methods in
the JComponent API docs. If I saw a question asking what method was best
to address a particular issue at a particular level of abstraction, and
that listed several that the poster thought might be applicable, my
first guess as to how they came by the list would be "by perusing the
class's API docs, specifically the method listing", if it occurred to me
to even wonder how they constructed the list at all. It probably
wouldn't, seeing as it's not relevant; I'd probably just answer the
question, given that I knew the answer or found the docs easier to
interpret than they presumably did.

I think a bit of IETF wisdom is applicable to human interaction online
every bit as much as it is to machine interaction online: "you should
very strictly follow the standard in what you send, but be liberal in
what you'll accept".

The former, applied to humans, means mind your manners; the latter means
try to remain civil and don't reject peoples' good-faith questions with
nasty responses analogous to error messages just because YOU think
there's something they should have done differently.

I follow that particular bit of advice. It is becoming quite apparent
that you not only do not, but seem to explicitly and willfully REFUSE to
do so out of sheer bloody-mindedness. I'd plonk you, but I have to wait
for this thread to die down first so that I can respond to any more
insulting nonsense you post to it and thereby reduce the risk of anyone
coming away from this thread with the mistaken impression that there's
any truth to what you've said about me.
>> 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?
>
> It's not a question of whether I'm satisfied.

It sure seems like it, particularly when you threaten, above, to respond
in a way that someone "won't like" to any question that you find
unsatisfactory according to fairly vague criteria. Criteria that you
don't state up-front before attacking people, I might add, and that
furthermore can very easily be innocently violated by someone that is
acting in good faith.

Shame on you!
> It's a question of
> whether you have any interest in asking questions in a way that is
> likely to get them answered.

At this point, I couldn't possibly care less what ways of asking
questions will be most likely to get you to answer them. Indeed, I
couldn't care less if you never answered another question of mine again.

In fact, based on how you chose to answer this last one, I'd PREFER it
if you never answered another question of mine again!

Oh, and another unsolicited manners lesson for you: it is considered
rude when someone presumes to speak for everyone else in a large forum
of any sort. As you do above, when you say "likely to get them answered"
rather than "likely to get me to answer them", even though the only
person whose policy on answering questions that you can either control
or speak about with authority is your own personal one. Others will
answer whatever questions they please, including ones that you wouldn't
answer (or would answer in a nasty and useless way instead of properly),
whether you like it or not.
> As for your proposed alternative question format, no...that's not going
> to get your question answered with any more enthusiasm.

Fine, then please killfile me. Obviously you won't like my questions,
for whatever reason and despite the fact that there's nothing at all
wrong with them in any objective sense, and obviously you don't like me,
so do us both a favor and simply ignore me from now on. (That means
don't bother replying to this post, either.)
> If you have a question about what you've read in the documentation,
> you need to be specific about that.

I had a question about which method was best to do a particular job at a
particular level of abstraction, and I was specific about that. If you
interpreted it differently, that's down to YOU. If that interpretation
led you to conclude that there was a problem, then it is YOUR problem.
It is YOUR SUBJECTIVE OPINION. Your subjective opinions should have no
bearing on any technical information you post here, nor should it have
any influence on how polite you are to someone here -- you should either
be polite or say nothing at all. If you can't stand someone and can't
stomach making the effort to reply to them civilly then exercise the
latter option, and if you feel a knee-jerk impulse to lash out every
time you see a post by some person, you should killfile them. That is
Usenet etiquette 101.
> Simply saying "I've read the documentation and I'd
> like you to tell me the answer to this question that was answered by the
> documentation" doesn't encourage people to be motivated to help you.

But of course I never suggested that I'd say that. I said that I'd say
"I've read the documentation, but still have a question: <something
specific about doing something in Java>".

To this, the proper response (other than to write none at all) is a
straightforward answer to the question. If, for some reason, it
irrelevantly occurs to you to wonder why I didn't find the answer in the
documentation, then you may ask that AS WELL AS answering my question,
POLITELY, in particular this means WITHOUT implying that I'm some sort
of idiot or clueless newb. Perhaps, if you ask nicely, I'll even answer
your question, asked irrelevantly out of idle curiosity. Of course, it's
possible that for whatever reason you won't like the answer. If that
occurs, don't lash out at me; you asked, you got an answer to exactly
the question you asked.

If you are not willing to answer politely, or you are not willing to
answer without the answer being 100% irrelevant, then please do not post
any reply at all.
>>> 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.
>
> True, and irrelevant.

No, it is not irrelevant. The question of whether or not I read the
documentation, or why I didn't find some particular thing there (despite
looking), is what's irrelevant here. You don't need to know in order to
answer. You just need to know the answer to the question you were
actually posed.

Why are you so interested in who's read what documentation and why they
didn't find such-and-such in it, anyway? It has no bearing on what
someone asked, in typical cases, and you aren't to my knowledge involved
in any effort to actually improve the documentation quality, either.
> The problem of people asking RTFM questions is far too common

There is no problem here except for people like you being impolite
without cause, answering with purely off-topic and useless responses,
and generally being all-around jerks!
> for you to expect anyone to give you the benefit of the doubt.

I expect you to give EVERYONE the benefit of the doubt or else NOT REPLY
TO THEM! I expect you to do so because I expect you, as I expect all
human beings, to BE POLITE, ESPECIALLY IN PUBLIC! What part of that is
so difficult for you to understand?
>> 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.
>
> This isn't about satisfying curiosity.

Then why did you ask me questions whose answers you did not need in
order to correctly and concisely and politely answer MY question?
> It's about trying to help you understand why people aren't going
> to answer RTFM questions.

Now you're being arrogant, rude, and condescending again.

Arrogant: presuming to speak for everyone in the world yet again.
Rude: I know bloody well what the "F" in "RTFM" stands for, among other
things.
Condescending: you are again assuming the role of patient teacher trying
to make backwards student understand something in time for the exam.

Let me make myself perfectly clear:

I DO NOT >>>CARE<<< WHY >>>YOU<<< AREN'T GOING TO ANSWER PARTICULAR
QUESTIONS.

Just answer them or not, as you see fit, but either answer them politely
and accurately or don't post any reply at all!

It's really that simple!

If someone wants to know what questions YOU are going to answer, they
will ask you what questions YOU are going to answer. If they do not ask
you what questions YOU are going to answer, don't tell them unsolicited,
especially not if you have some kind of inherited inability to do so
politely.

And if someone asks you what questions "people" are going to answer, the
only correct response will obviously be "whatever questions they,
individually and separately, FEEL like answering".
>> 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. [...]
>
> The very fastest way for me to get the answer to any question would be
> to just ask the expert.

Funny -- I find it's faster to try to find the needed information in the
docs before posting something and then waiting for ages for an
as-likely-or-not snarky-and-unhelpful response from some jerk who thinks
his modem and sorta-anonymity gives him carte blance to tell all and
sundry exactly what he thinks of them and why.
> But, that can be a waste of the expert's time,
> and as well I will learn more about the subject if I do some research
> myself.

And when you do so, but the answer is not apparent from the docs that
were most obviously relevant (such as, say, the long list of JComponent
methods)?

You ask, right?

Yet you fault me for doing the same in the same circumstances.

Shame on you!
> Personally, I don't like wasting other people's time.

Then please don't waste mine with any more useless, flamey, or otherwise
off-topic responses. In the future when you see a question by me please
either give it a straight answer with no extra added bonus "baggage" or
ignore it completely. And if you find me completely intolerable for any
reason please say nothing and just killfile me. Thank you.
> But the fact is, other people don't like YOU wasting their time.

If you think answering a particular question is a waste of your time,
then the most time-efficient thing you can possibly do is just mark it
read (or even killfile the thread) and move on, without posting any
reply at all.

The only reason to post snarky, useless, and insulting replies is if you
WANT to waste time, and your preferred form of time-wasting is to pick a
fight and then slug it out with someone.

If that's your cup of tea, there are newsgroups expressly for that sort
of purpose; comp.lang.java.programmer, however, is not one of them.
> When it looks like that's what you're doing,
> they tend to ignore you rather than answering the question you want
> answered.

Fine. It's when you do neither that I get bothered.
> Again, I've no interest here in making you feel bad about your choices.

Then why keep harassing and berating me? In public, at that?
> I'm simply trying to offer advice that will help you understand better
> techniques for getting your questions answered.

I didn't ask for advice on "better techniques for getting my questions
answered" by you. (And you can only speak with authority on what YOU
like in a question. You seem to be conflating your own opinion of what
questions YOU think are worth YOUR while to answer with some peculiar
idea of some sort of universally-held opinion on the matter, as if there
even were such a thing. I don't know why.

The gratuitously insulting paragraph where you imply that I'm some sort
of a child has been completely ignored, save to make this remark calling
you on your own childish behavior in including such pointless flamebait
in your post.

And since there's nothing left, I guess this is goodbye.

Unless, of course, you for some reason think there's anything left to
say here that you haven't already repeated several times.

Peter Duniho wrote:
> On Wed, 13 Aug 2008 23:50:50 -0700, zerg <> wrote:
>> Not quite, since "what I asked for" was a simple, no-arg "repaint-me".
>
> Had you actually looked at all five overloads for repaint(), you would
> have found the one you wanted.

I told you to stop posting attack posts, and to killfile me if you had
to in order to achieve that objective.

Where I looked, the JComponent method listing, I saw two overloads, not
five. I acted reasonably based on what I saw in the obvious place to
look. That I did not additionally look in some non-obvious place is of
no importance; furthermore it is no skin off your nose.
>> Nothing. I didn't look at the description of the paint method, because
>> I was not interested in the implementation details of the JComponent
>> class, only its interface to subclasses and its public interface.
>
> Well, I hope you've learned from that mistake.

I did not make any mistake. I do not make mistakes. Stop lying about me
in public.

The whole purpose of API documentation and object-oriented design, of
course, is to make users of a class not need to concern themselves with
the implementation details. Therefore, not concerning myself with the
implementation details when using object-oriented classes is not a
mistake; it is expected and normal behavior.
> The next time you are reading the documentation for a method and it says
> that it basically just calls some other method, now you know that you
> need to go read the documentation for that other method.

I don't share your opinion on what I do or do not need to do. I don't
care what your opinion is regarding what I do or do not need to do. I
doubt anyone else reading this newsgroup cares what your opinion is,
either. Why are you wasting time and bandwidth by broadcasting your
irrelevant, small-minded, and boring opinion to the world? If you want
your own personal soapbox from which to broadcast your own personal
opinions, blogger, livejournal, and several other web sites provide free
blogging space where you can opine away without wasting anyone's time
that isn't specifically interested in hearing your opinions. (Of course,
if you badmouth random ordinary peopl on your blog, it may come back to
haunt you in the form of the site getting yanked by the provider, or
even legal action, so you'd do so at your own risk!)
> Otherwise, you still don't know what the first method actually does.

That means that the docs are poorly written. I do not need to do
anything. The documentation writers need to better document that method.
Each public method's own javadoc should state what that method does,
without reference to the implementation; it may add supplementary
information regarding the implementation but it should never say ONLY
implementation-dependent things.
>> If you'd prefer not to answer a question, for some particular reason,
>> you could always not post any kind of response to it at all. One thing
>> I will certainly not tolerate, however, is any sort of response that
>> implies, in front of a worldwide audience no less, that you think I'm
>> in some way incompetent. Stop doing that!
>
> You will not tolerate?

You heard me. If I ever want your opinion of me I'll explicitly ask you
for it -- BY PRIVATE E-MAIL. This is a newsgroup for the discussion of
Java programming, not your own private pulpit from which to preach on
any random topic that pops into your head. Kindly remember that fact in
the future.
> Do you have any choice in the matter?

I don't take kindly to being threatened. If you don't like me, the
proper behavior is to killfile me, not to publicly badmouth me nor to
threaten to do so. This is not alt.flame. Please do not treat it as if
it were.

Another paragraph of insulting nonsense had come next, but I don't see
any reason to include it here. Suffice it to say that I have not made
any mistake, except, apparently, in your HUMBLE opinion, which a polite
person would have kept to himself.
>> That may be true in the copy of the documentation you looked at, but
>> it is not in mine. Don't assume that everyone is reading the same copy!
>
> I'm reading the same documentation you are.

Obviously not, as I have just demonstrated that the thing you said was
in your javadoc for one of those methods was not in the description text
for either of them in my copy of the javadoc.
> It's just that I took the time to actually follow the links

Are you now saying that you LIED when you said that the javadocs for one
of those two methods stated to use repaint instead? Because that IS what
you said.
> From the description of JComponent.paint()

That is not either of the two methods whose javadocs are at issue.

So, you DID lie.

I am definitely going to plonk you now, just as soon as this thread has
died down. It is now obvious that you are morally bankrupt and that
nothing that you write in response to any of my posts can be expected to
be at all useful to me.
> Invoked by Swing to draw components. Applications should not
> invoke paint directly

Invoking update() is, of course, not invoking paint() directly, and I
was, as I'd already stated, coding a custom JList descendant rather than
an application that was merely USING a JList, so this would not have
been relevant ANYWAY.
> If you'd read that paragraph, didn't understand, and had posted a
> question asking for clarification, that would have been one thing. But
> you obviously never got as far as even reading that paragraph.

No, I didn't, for reasons that I already explained. The javadoc for
update should have said all that it needed to say. If it did not, and
apparently in your opinion it did not, then that is a problem with the
documentation, not a problem with me.

And in neither case is it at ALL relevant to the question that I
originally asked!
>> It's bad enough that you frequently and inexplicably insult me, even
>> though I've never done you any harm or been mean to you at all.
>
> I'm sorry if you feel insulted. It's not my intent.

I now know that that is a lie, from your behavior in a couple of other
recent posts, so please don't bother with empty platitudes like this
again. It wastes bandwidth.

(The remainder of that paragraph went on to quite deliberately insult me
several more times, including by erroneously accusing me of having made
mistakes. I have not.)
> So far, you've failed miserably

In your ever-so-humble opinion, which I never asked you for and which,
if you'd not apparently been raised in a goddamn BARN, you would have
known to keep to yourself!
>> It's worse when you do so based on completely faulty premises, as
>> occurred in this particular instances.
>
> You've yet to show that I've made any false assumptions.

Well, apparently they weren't merely false assumptions after all -- they
were outright lies.

But you said that the javadoc for one of two specific methods stated
something that they did not. I charitably attributed this to your
version of the docs differing from mine, and your falsely assuming that
my version contained something if your version did. And then, on the
basis of that false assumption, you berated me for some supposed stupidity.

Now I know that what really happened was much worse -- worse for you,
that is. What actually happened was that you said that the javadocs for
one of two specific methods stated something that they didn't, period;
in your copy, AS WELL AS in mine, that something appears only in the
javadocs for a third method, not in either of the two methods for which
you claimed one of their javadocs mentioned it.

In other words, you didn't make a false assumption about my version; you
simply lied baldly about something being in a place where it wasn't!

And then, on the basis of that outright fabrication, you berated me.

I have now demonstrated that you are being intentionally hostile and
dishonest. Clearly your only purpose here is to try to provoke a
full-blown flamewar. Were I a lesser man, you might well have actually
succeeded.
> It turns out that you did in fact not read all of the documentation
> that you should have

In your humble opinion. The only documentation I can reasonably be
expected to read is what's obviously of immediate relevance to the
matter at hand. Particularly for a class with as large a list of methods
as JComponent.

My question was "which method to do X"; I quickly determined that JList
didn't deal with such matters directly but delegated to JComponent; so
the JComponent method list was the place to look. So I looked at the
JComponent method list, picked the likeliest candidates, clicked on
each, and thus looked at the descriptions of each. That I did not read
the whole thing cover-to-cover or read any OTHER classes' docs just
proves that I am not a man of infinite, saintly patience and possessed
of unlimited time. Hardly a crime.
> in order to research your question, and that the answer to your
> question is in fact stated clearly in the documenation.

No, it is not. I submit that the documentation does not, to my knowledge
based on any of this, state clearly what method should be used to
repaint an entire component, from inside a subclass, when coding a
library rather than an application.

Also, I would consider that for it to truly state something CLEARLY, it
must state it where people looking for that information are very likely
to FIND it, as well as state it unambiguously. Why would I look at a
method that wasn't one of the three I'd come up with, or look at the
superclass when it looked like JComponent had its own repaint methods
that, perhaps, superseded the AWT ones?

It doesn't even matter. It's not up to YOU to decide what I should or
should not have done. You can believe that I should have read every byte
of the entire api docs tree, for all that it matters -- it's completely
irrelevant! I asked a simple question with a straightforward answer. The
only correct ways to respond are a) with that answer or b) not at all.
There is nothing further to discuss.
>> You pointed to an AWT method for some reason.
>
> I pointed you to the AWT method BECAUSE IT IS THE ANSWER TO YOUR QUESTION.

And I am not disputing that. I am disputing your implicit claim that I
should have looked there instead of at the JComponent repaint method
cluster.

And the only reason I am doing so, given that where I should have looked
is completely irrelevant to my original question, is that since you have
publicly maligned me in a baseless manner, I must now point out, equally
publicly and in the same place, why you are wrong and the reason why
your maligning of me is, indeed, baseless.
>> I was looking for a Swing method, specifically a JComponent method.
>> There were two repaint methods in JComponent. Why would I go looking
>> somewhere else entirely for a third?
>
> Because, as I already pointed out, Java is an OOP language

Ridiculous. Where does it stop? All the way up at Object? I was asking a
question about a Swing JComponent. I think stopping at JComponent and
not looking into the IMPLEMENTATION DETAIL that JComponent is
implemented using AWT base classes is perfectly goddamn reasonable.

Oh, you disagree? So what? Go ahead and disagree. You have every right
to. It's your opinion. Where you cross the line into being a rude little
prig and a waste of time is when you decide, on the basis of A MERE
PERSONAL OPINION OF YOURS, to start badmouthing other people in public,
to post time-wasting useless unhelpful responses to questions, and to
generally act like a jerk in public!

I think maybe I need to drill it in directly and emphatically.

YOU ARE NOT GOD.

YOU do not decide what is or is not a good question, period; only what
is or is not a question that you, personally, feel like answering.

YOU are not the official arbiter of how someone should use the
documentation.

YOU are not the sole person in charge of deciding what questions are
acceptable on this newsgroup.

YOU are nobody!

Got it?

Step down off your high horse and start behaving like a plain old
citizen, the equal of everyone else, whose opinion counts for exactly as
much as anyone else's (usually nothing) and who should be held (and
should hold himself!) to the exact same standards of polite and civil
behavior that almost everyone's mother teaches them.
> you cannot understand a given class without also understanding its base
> classes.

Once again, you make the mistake of thinking that I'm trying to
understand JComponent in its entirety, implementation details and all,
rather than trying to simply use a JList in a particular instance.

Either that, or you make the more severe mistake of thinking that I am
SUPPOSED TO, and that I am not permitted to proceed with my work until I
DO, understand all of that. Along with the even WORSE mistake of
thinking that someone has put YOU, personally, in charge of deciding
these things and granting or denying such permissions!

Here's some news for you: nobody has done anything of the sort. Nobody
died and made you God. Your opinions on such matters are exactly that --
YOUR OWN PERSONAL OPINIONS. And as such, they are worth exactly what
such opinions are usually worth. And like it or not, I will treat them
as such.
> and you will, if you continue your Java education

I have a fairly solid Java education, thank you very much. I just don't
have much experience subclassing JList! So sue me!
>>> really, you have no excuse
>>
>> This is exactly the kind of nasty, insulting, counter-productive, and
>> off-the-topic pointlessness that I have asked you repeatedly to
>> dispense with. Can we not focus on only what's relevant here?
>
> Forgive me if I find it relevant that I _answered_ your question

That's not what's at issue here! I asked can we not focus on ONLY what's
relevant here. You are constantly mixing your personal beliefs and
opinions, including (especially unfortunately) your personal negative
opinions of other people, into things instead of leaving such things
where they belong: locked safe and sound inside your own cranium. NOBODY
CARES what you think of me. NOBODY CARES what you, personally, think
people should have read or done. NOBODY CARES! Get it? Nobody cares
about anything except the answer to the question-du-jour! So please,
either oblige them or don't post anything at all.
> and yet you refused to bother looking at the answer

Wrong. I have already used the answer in my code. What I refused to do
is submit to your claims regarding my competence, and what I should or
should not have done. And that's because I STILL DO NOT AGREE WITH YOU
ABOUT THOSE THINGS. Got it?
> because you made your own premature, uninformed and ill-advised
> judgment that my answer wasn't what you were looking for.

I did nothing of the sort, you liar. I explained why I didn't find it in
the documentation. Apparently even that is not enough to meet your
exacting standards for how other people should behave. Well, tough.
You'll find that lots of people don't meet your exacting standards, and
you will have to learn to accept that and get along with such people or
face the consequences.

That's not a threat, by the way; that's just a warning. Being as boorish
as you have been will get you nowhere in life except, perhaps, someday
into a world of hurt when you insult the wrong six-foot-three,
two-hundred-pound person or get fired from your job or something for
being a jackass whenever someone doesn't live up to your oh-so-perfect
standards.
> When you've already been given the answer, why would anyone do anything
> more than keep pointing out that you've been given the answer?

I have no idea. Why do you? Yet here you are, repeatedly posting just to
sling various insults at me, and when I reply to patiently explain to
you (and to whoever else is reading this -- if it were just you, I'd
probably just let you stew in your own ignorance) that you're wrong
about me (and why), instead of just accepting that, or agreeing to
disagree, and moving on, you post ANOTHER post full of pointless insults
and vitriole.

Please stop doing so, and please treat my question ("why do you?") as
rhetorical and simply not post to this thread any more. You've said your
piece, and I've said mine, and the only reason for you to continue now
is if you feel you have some childish need to get the last word or
something equally silly.
>> (The insulting and off-topic twaddle from the end of your post has
>> been deleted unread. Please don't waste my time with that sort of crap
>> again.)
>
> Not that your characterization of my post is accurate

You might not like it, but it was, indeed, accurate. It had nothing to
do with the original topic (to wit, "Best way to force a JComponent to
repaint itself") or Java and it was you once again expressing your
by-now-well-known nasty and small-minded opinion of me, formed hastily
on the basis of nothing but a smattering of usenet posts and therefore
about as trustworthy as a politician's big shit-eating grin on
meet-the-press day during election season.

Just drop it. It can do neither of us any good for you to continue.
> but, at worst, whatever I write is only a waste of your time if you
> read it. No one's forcing you to.

Unfortunately, I have to read all of your posts to this thread now
because there is a statistically high probability that any such post
contains some baseless slur or another against my good character that
will require public correction.
>> and where I had no reason to look,
>
> FALSE!

No, you're the liar, as we've established previously.
> Until you understand your mistake, you will keep making it.

I.
DID.
NOT.
MAKE.
ANY.
MISTAKE!

I looked exactly where I was supposed to. That not all of the relevant
methods were grouped together in the documentation indicates a problem
with the documentation.

Your opinion may be different, but it is just that -- YOUR OPINION, AND
NO MORE. It has no place in any public inquiry into whether or not I've
done something wrong. In fact, there should not be any such public
inquiry. I haven't done anything wrong, and I haven't requested any such
inquiry myself. Why you seem to think there should be one ... but again,
let's not go there. It's irrelevant. It's apropos of nothing. This is a
newsgroup for discussing Java, not for discussing zerg and whether or
not he's bad, evil, wrong, stupid, or some such. Please get back on
topic now.
> You think I'm sitting here trying to insult you when in fact I'm
> trying to point out the mistake so that you can LEARN from it.

That's a lie, as established earlier. I made no mistake, except perhaps
according to your own, ill-founded opinion. I made none in fact. And you
are not trying to get me to LEARN anything; you are trying to start a
big fight, and you are becoming increasingly frustrated and angry that I
won't take the bait, stoop to your level, and start throwing the F word
around like you have done. That this is your intent is apparent simply
from the fact that you keep repeating yourself long after I have made it
clear that I have no interest in learning what you want me to learn,
which is, in fact, a bunch of YOUR OPINIONS and not really anything to
do with Java at all.
>> since it's in a completely different section of the API documentation.
>> Perhaps if it had been listed right next to the other two repaint
>> methods?
>
> Define "right next to".

As in, the two were physically adjacent in the web page. The third was
on another page entirely. There may be a link to there on the JComponent
page, but if so, it's buried in one of those very dense blocks of
nothing but links far away from where the two methods were that I did find.

I don't have time to minutely examine every single link in a page the
size of that one when looking for a specific bit of information and when
it has (if perhaps falsely) implied that I've already found all that
page has to offer on the subject.

But why am I explaining myself to you yet again? If I thought that you
might actually be acting in good faith, and willing to actually LISTEN
to what I have to say and try to understand my point of view, it would
make sense for me to do so, but you're clearly only here to HOLD FORTH,
expressing YOUR opinion; you clearly consider your opinion to have
supremacy and as a result you are completely uninterested in my point of
view. That, of course, is why you don't actually bother to read and
understand most of what I write, but reply anyway.

You've worn out the "benefit of the doubt" in my case.

Shoo! Go away! Be gone with you!

I won't respond to any further posts from you except to deny, for the
record, that there's any truth to any insults that you've included in
them. Any more elaborate response is now clearly a waste of time and
bandwidth and will only serve to encourage you to post yet another long
diatribe all about how evil zerg is.
> There certainly are links to the Component
> repaint() overloads from the JComponent documentation page. I'd call
> that "right next to".

"On the same page" != "right next to" when a page is that size, of course.
>> But no, it can't possibly be the case that the docs are GENUINELY not
>> 100% perfect in structure and content, can it?
>
> No one's saying that the docs are perfect.

You are implying it when you blame ME for something that actually
resulted from the docs' limitations.
> But in this particular case, they did not fail to provide the
> information you wanted.

In a certain technical sense. They did fail to put it where it would be
likely to be seen, though, which means they only did half of the job.

Yes, I know, you disagree. I also don't care. Shut up about it, and shut
up about me. There is nothing further to say on this topic, so please
don't waste everyone's time.
> You simply failed to look.

Not true. I did look, in the appropriate place, alphabetically between Q
and S, under R. It simply wasn't there (between Q and S, under R, that is).
> The Java doc format is consistent.

Then it unfortunately might prove to be consistent in its flaws.
> Every class has a description, then a summary of all its members,
> followed by simple lists of each member of each base class, and
> finally the elaborated descriptions of each member.

And it is there, where I was supposed to, that I did indeed look. I
failed at nothing. I carried out the extent of my responsibility. And I
don't care that your opinion is otherwise, so don't bother saying so yet
again.
> All you had to do was scroll down to the base classes for
> JComponent, looking at the members listed there, and you would have
> found the other repaint() methods.

But why would I do that, particularly when it's an unpleasantly dense,
run-together solid block of links? (Someone clearly didn't read any
style guides about writing for readability or easy skimming/scanning!)
> If you are inexperienced and did not understand that, that's not a
> problem at all as long as you're willing to own up to that. But when
> you repeatedly assert that you've made no mistake, that the method
> you're looking for doesn't exist, even when someone has specifically
> pointed you to it, then we come to...

I have not done anything of the sort, you liar. I have only asserted
that I made no mistake (true) and that the method that I was looking for
wasn't listed in the obvious place, right beside the others. I never,
EVER claimed that it didn't even exist. I did, at one time or another,
indicate that someone ELSE had IMPLIED that it didn't in one or two
places, but that's a completely different matter. Evidently those
someone elses were wrong. Hardly my fault.
>> Oh, no, if anyone has a question that the docs do sorta-obscurely
>> answer, then that person is automatically a complete idiot and the
>> only reasonable response to their question is to announce this, loudly
>> and publicly!
>
> I have announced nothing of the sort.

You have implied it.

Now take your unwelcome and off-topic opinions about me and shove them.
This is a Java programming newsgroup, not Geraldo and certainly not
Peter Duniho's Personal Soapbox.

repaint is sometimes used in client context, and sometimes in component
context.

revalidate is/should be for component context only.

update is only for paint context.

revalidate is functionally different from repaint and update.

-.-

If you want the engine to redraw your Component* completely, use
repaint() without arguments. If you want it to redraw a particular
section within its bounds, use the repaint overload that takes bounds
(directly or via a Rectangle).

In either case, if you're calling repaint very often**, you might want
to allow the calls to coalesce by calling one of the repaint overloads
that take a long as their first argument (something like hundred or two
hundred millisecs should be adequate).

If your custom component's layout (bounds, positions within) was
modified, call invalidate() and let the framework do the rest. Don't
call revalidate() at that point. The difference between revalidate() and
invalidate() is validate(), and that should be in client code.

Never call update unless you're in the paint() method chain -- i.e.
doing custom painting -- and even then only exceptionally.

Peter Duniho wrote:
> On Thu, 14 Aug 2008 00:01:41 -0700, zerg <> wrote:
>
>>> JComponent inherits Component. You can't understand JComponent
>>> without understanding Component.
>>
>> The same mistake you've made several times before. You assume that I
>> seek to thoroughly understand JComponent. I don't. I seek to use it in
>> a particular way at this particular time.
>
> I never suggested you intend to "thoroughly understand" the class

You suggested that either I intended to or that I actually MUST do so;
neither is correct.
> But you do _need_ to at least understand the parts you're using.
> My statement stands valid as is.

No. Nothing that you have said about me "stands valid", at least, not so
far.

To understand the parts I'm using I went and read the javadocs for the
two repaint methods that were in the expected place in the alphabetical
list, the revalidate method, and the update method, exactly as I should
have.

That your opinion differs is of no importance whatsoever. Your opinions,
in general, are of no importance whatsoever. Why you persist in
believing otherwise remains a mystery, given that you've had this
explained to you repeatedly now.
>> You're not teaching school.
>
> I suppose that depends on your definition of "school".

It depends on nothing. You're not teaching school here. You're
participating in an online community of Java programmers. Unfortunately,
your idea of participation is apparently to be really rude and boorish
to anyone whose opinions you happen to disagree with.
> But if you think
> this newsgroup is a place for you to just ask whatever questions pop
> into your head, without any expectation that you should have to
> perform due diligence to find the answer yourself first

I don't think anything of the sort and I DID perform due diligence. And
yes, once again, I have a pretty good guess what your opinion is on that
matter and yes, once again, I don't give a shit, and neither does anyone
else in all likelihood.
> you are in for a huge disappointment.

Threats are wasted on me. I don't care if you never answer a question
from me again. In fact, I'd prefer it if you didn't; I'd dearly love it
if you'd just killfile me right now. Obviously we mix about as well as
oil and water, and most of that is down to your abrasive and opinionated
nature and refusal to keep negative opinions to yourself in polite company.
> Here's the deal: people answer your questions at their own pleasure.

No problem. I'd just like it if they either answered straight, and
civilly, or said nothing at all, rather than writing any nasty thought
about me that might be suggested to them by whim!
> We're not here to serve your whims, nor to be ordered about by you.

Fine. The only time I've ordered anybody about rather than said "please"
was when someone pushed me far enough and I stopped prepending "please"
before "don't be rude to me" and the like, because it had become clear
that politeness was wasted on that person.

You being one such person.

The only "whim" I am "ordering" you about is my personal preference NOT
to be the subject of a lot of off-topic, pointless nonsense. This is a
Java newsgroup, not a zerg newsgroup. Stop posting about zerg and start
posting about Java please.
> We do as we please, and your ability to get a question answered will
> depend heavily on your willingness to adhere to community standards
> and expectations.

Hoo boy. It doesn't get much more arrogant than this.

Nobody died and appointed YOU supreme arbiter of community standards!
Your SOLE authority here is to decide what questions meet YOUR PERSONAL
standard for answering them, NOT to decide EVERYONE ELSE'S AS WELL.
Please get that through your thick skull and thereby save us all a lot
of grief.

In your OPINION my question may not have been up to some standard or
another. Fine. Ignore it, then. But don't accuse me of acting in bad
faith, especially in public, and don't waste countless hours and
megabytes BROADCASTING your stupid little narrow-minded irrelevant
opinions in a newsgroup where the topic is not "Peter Duniho's opinions"
but rather "Java programming"!
>> You're answering specific questions posed in a technical newsgroup.
>> The object of the game is for the guy asking the question to get a
>> precise and specific answer in the shortest time possible, not for you
>> to turn them on to the wonders of learning and ensure that they are
>> prepared to pass the end-of-term exam.
>
> You're simply mistaken about that.

NO. I AM NOT MISTAKEN.

If your OPINION about what this newsgroup is for differs radically from
the above, which states what this newsgroup ACTUALLY is for, then
perhaps you are better off not posting to this newsgroup at all.

Perhaps you actually teach a class in your working hours. It would
explain a few things. But if so, learn to separate your role at work
from your role on this newsgroup. They are distinct. Your classroom is
full of clueless newbies who need guidance and who need to learn a
course curriculum and not just get specific answers to specific
questions. This newsgroup is full of knowledgeable Java programmers (and
probably the occasional clueless newbie) who do not need guidance unless
they say they do, who do not need to learn a well-rounded curriculum
unless they say they do, and who do need to get specific answers to
specific questions.

Take specific questions at face value. Don't read anything else into
them, like imagined hidden pleas for help understanding some broader
thing or asking what your personal opinion is on how much digging into
the docs someone should arse around with before asking elsewhere. If
someone has such a question here I am sure they will ask it outright. I
know I will.
> When the opportunity to help teach a person to fish comes up, many
> of us will choose to do that, rather than to just hand out fish.

Not everyone has time to play your little scavenger hunt (or play to
your ego). Please answer a question directly, in your first reply to its
thread, if it hasn't already been answered. If you wish, go ahead and
ALSO point out any research tips or documentation things you think the
poster might have overlooked -- WITHOUT implying that they are an idiot
for having overlooked any such and without any other uncivil behavior.
That way EVERYONE gets their wish, you your stated desire to teach
someone and the original question asker an answer to their question,
plus what may or may not be a useful bonus for them.

Well, except that this assumes that you are acting on good faith. All
the evidence now indicates that your REAL wish is to start fights. Of
course, what I suggested is too reasonable and too non-fight-starting to
pass muster with you. (Prove otherwise -- accept it. I dare you! If you
reject it, I and doubtless many others here will take it as your tacit
admission that your real wish is, indeed, to start fights, and that
being reasonable just isn't your bag.)
> This isn't a game

Exactly. Someone asking a question here may be under time pressure. Did
you ever think of that?
> Meaning, if we can somehow help you help yourself, then that's more
> efficient in the long run and is a worthwhile effort.

That's for me to decide. It's for each individual person to decide what
is more efficient FOR THEM in terms of getting their particular tasks
accomplished. It is arrogant in the extreme for you to presume that YOUR
opinion of what would be most efficient for THEM supersedes THEIR
opinion of same. Particularly when you do not have direct knowledge of
their particular situation and context, while they do. Nor is that
context frankly any of your beeswax; you should just trust them to ask
where something might be documented/ask where something might be BETTER
documented/ask for research tips when that's what they feel will be most
efficient for them and to ask specific questions when THAT's what they
feel will be most efficient for them.

Second-guessing them instead only serves to insult them, work at
cross-purposes to them, and delay their getting what they ACTUALLY ASKED
FOR.

We are not children. We do not need you to play the parent and give us
"what we need, not what we want". We are adults that can make our own
choices without any more nannying from arrogant SOBs like yourself. We
decide what we need AND what we want, not you. If we want to eat food
high in saturated fat, we will do so and we will not be interested in
your opinion on the matter. If we want to ride without a helmet, we will
do so and we will not be interested in your opinion on the matter. If we
want to load up on sweets and skimp on fruits and vegetables, we will do
so and we will not be interested in your opinion on the matter. If we
want to only do the most basic, reasonably quick documentation searching
before asking a question on Usenet, we will do so and we will not be
interested in your opinion on the matter. If ever one of us actually IS
interested in your opinion on any such matter, rest assured that he will
actually ASK you your opinion on the matter. Until and unless someone
has done so, consider that it might be seen as unwelcome, ESPECIALLY if
it is condescendingly offered IN LIEU OF, instead of AS WELL AS, the
actual thing that was requested!

I think that is all that needs to be said on the matter. I don't think
there is any point in discussing the matter further; you have made your
opinion plain and I have done likewise. Killfile me if you must, and
move on.
> More importantly though, I will point out once again: you do not have
> the privilege of dictating how your question is answered.

I am doing no such thing. I am reminding you of how you should behave in
polite society, since you are repeatedly and flagrantly failing to
behave politely within my notice and your doing so is proving to be a
bother to me. I am putting you in your place, because you seem to have
gotten it into your head that you're in charge around here in some way,
and that your personal opinions somehow constitute "community standards"
that somehow even override the basic standards of how adults should
behave towards one another in polite company. I am reminding you that if
you prefer not to give a straight answer to a question, you can always
leave that "follow up" button alone instead of telling the world your
personal opinion of its asker. I am alerting you that your behavior is
offensive and rude. And last but not least I am reminding you that we
are adults that don't care to be condescended to, not school-children in
need of parenting and guidance whether we like it or not. We are grown
up. We will ask for what we think we need, and what we think we need is
more important to us than what YOU think we need.

Thank you for considering the above, if consider it you ever actually do.
> The best you can do is simply ignore answers you don't like.

No. The best YOU can do is simply ignore QUESTIONS you don't like.
(Responding to them to attack whoever posted them is certainly something
you can do, for shame, but it is certainly not anywhere near the BEST
thing you can do, nor even a good thing for you to do at all.)
> Throwing a tantrum

I didn't do anything of the sort and I resent this blatant and
intentional mischaracterization.
>> Please just answer the question forthrightly, with perhaps a pointer
>> to any docs you found relevant that the question's asker apparently
>> missed or found unclear, and leave it at that, or else ignore the
>> question entirely.
>
> This, coming from the person who refused to look at the pointer that was
> in fact provided to him.

I'm speaking generally now, in case you hadn't noticed. When someone
asks a question, in the future, please just answer the question
forthrightly, with perhaps a pointer to any docs you found relevant that
the question's asker apparently missed or found unclear, and leave it at
that, or else ignore the question entirely.
>>> "Fully intend to" is silly. There's no excuse for not doing it that
>>> way from the outset.
>>
>> There you go again. I now suspect that you're intentionally twisting
>> and misinterpreting things purely for the purpose of insulting me.
>
> Your suspicion is unfounded.

You have made it increasingly clear, if not by frank admission, that my
suspicion is indeed true. You are posting to this thread solely to
insult me in public, and your statement otherwise above is a bald-faced
lie, one of several I have now caught you in.

You are not acting in good faith at all. This discussion is pointless to
continue, since you are determined not to be reasonable or to act in
good faith, and since you have now been blatantly dishonest on several
occasions as well as ignoring repeated polite requests to keep your
negative opinions of me to yourself and to comport yourself in a
civilized and polite manner when out and about in public.

You are pointless. Your posts are pointless. I have no further interest
in anything that you have to say. Please do not say anything to, about,
or in a public reply to me again. Thank you.
> If I misunderstood you, it's only because
> most programmers aren't in the habit of describing code that's been
> written as not actually doing something until it's been executed in the
> target environment.

The code in question HAS NOT been written, as I have stated repeatedly.
Stop lying by implication! It is EXTREMELY rude to be dishonest like that.

I have been developing a JList-derived class. I have not yet written a
single line of code that actually instantiates one and calls upon it to
do anything, on any thread. All of the code that I HAVE written will run
on the EDT unless the caller to the JList-derivative's methods calls one
on another thread.

When I DO write code that instantiates one and uses it, I plan NOT to
make that error.

Clear enough now, asshole?

Oh, why do I bother. You have no intention of replying in good faith;
probably you never did. You don't read what I write, and when you do,
you intentionally misunderstand it and then attack it. All you're really
doing, of course, is attacking your own apparent stupidity in
misunderstanding it, and in public at that, but what do you care? This
is all just an entertaining game to you. You're a troll, as near as I
can figure from your steadfast refusal to actually be in the least bit
reasonable or to recognize the difference between universal FACTS and
YOUR PERSONAL OPINIONS.
> But by your way of speaking, that code doesn't do anything! It hasn't
> been run yet, and I only "fully intend" for it to iterate the variable
> and execute the empty block with the values of 0 through 4.

This is, of course, a complete mischaracterization, and what I have
heard called a "straw man argument". I never said anything remotely like
that. I said that code that HADN'T BEEN WRITTEN YET didn't do anything
YET. A completely different claim.

It IS true that my JList derivative will misbehave if its methods are
called from off the EDT. So what -- JList itself also will.
>> Stop this nonsense at once. I am no longer interested in anything you
>> have to say, and I have finally gotten answers to most of my
>> questions, so please do not post to this thread again.
>
> Again, I will do as I please. Having you tell me NOT to do things just
> makes me want to them all the more.

Your threats and admissions of childish motives do not help your case
any. Your explicit, repeated, and vehement refusals to abide by EITHER
a) the rules of polite society OR b) this newsgroup's charter* make you
look even worse. Stop now, before you dig yourself into an even deeper hole!

* where it says that the topic of this newsgroup is Java programming,
and zerg's purported evilness is therefore implied to be OFF-topic

Peter Duniho wrote:
> On Wed, 13 Aug 2008 22:56:48 -0700, zerg <> wrote:
>> Maybe many of the people who post here ARE that clueless. But it's
>> insulting to the rest of us when you treat us as if we ALL are, and it
>> obstructs just getting to the point as quickly as possible and then
>> moving on.
>
> What's your definition of "clueless"? Because my definition, it
> includes the kinds of people that _quote_ the answer they are looking
> for, while at the same time claiming that what they are looking for does
> not exist.
>
> Maybe your definition is different.

It isn't. However, nobody in this thread has done such a thing (at
least, not yet). You have claimed otherwise, but your claim was a lie.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!