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? :-P)