Listeners and validation/repainting

Question

So I have this problem. I have a program that creates and load files.

When I load a file into my program, I rely on a component listener that tells me when is the specific component "full", and then moves all of the components according to that.

I add each component on the top, and then listener register when parent component is "filled" and moves the bottom compoennt to a new parent it also creates. Think of it as adding a new line of text to the begining of a houndred page MSWord document.

That listener also relys on the GUI setup - if everything in memory is not painted to the screen, it grabs wrong component heights (usually being 0) and uses them in it's calculations which then come out wrong, and everything gets messed up.

Here is a flow chart of that part of my program:

(everytning happens on a JPanel in a JFrame)

trigger opening method:
{
    repeat this x (lets say e.g. 100) times:
    {
        trigger addComponent method
        {
            add component
            {
                adding component triggers the component listner 8if there is no more room in parent)
                {
                    move all of the components one place down, move the ones out of bounds to next "page"
                    repaint and revalidate whole JFrame (inside listener)
                }
            }
            repaint and revalidate whole JFrame (part of addComponent method)
        }
        repaint and revalidate whole JFrame(part of opening methid, after component addition)       
    }
    repaint and revalidate whole JFrame (as a part of opening method, final repaint/validate)
}

The reason for this may repaint/validate is that addComponent method, as well as the listener has other functions and is called in other places where that is the only (optimal) place for repainting/validating.

The problem is that JFrame doesn't get repainted until the very last(final) validate/repaint call in opeoning method. I tried adding Thread.sleep(1000) to several places in the code (after validate/repaint) to proved this.

Also, as far a I know, when a component listener is triggered, it stops at the line which triggerd it, then executes itself, and then continues from that line, right?

How do I fix this? How do I force my program to repaint/validate after each new component was added ant then again after the listener did it's job?

Reply to the first two comments: Firstly, Thread.sleep(1000) was just to diagnose the problem. Right before Thread.sleep(1000) method was repaint/validate method, so I thought if I pause the program right after reapint() was called, after every pause, GUI would be repainted ad I would see new element added, which was not the case.

Secondly, regarding to the lengthy calculations, those calculations aren't that long (executing this with 20 components gets momentary results, though not ones that are desired). Also, that calculations require removing and adding components to the GUI quite often (every 10-20 lines), so Incorporating SwingWorker in that is close to impossible, and not needed.

Thirdly, I think you missed the whole point. Length of execution is not the real problem here, nor the freezing of the GUI (whic doesn't really occurr, not long enough to be noticable, anyway). The problem is that repaint/validate was called in the loop for total of 3-4 times for every component (cca. 60-80 times if I open a file with 20 components), and the only time I saw it being executed is when the last time it was called, after the loop...

I even put System.out.println("something") method right before and right after the repaint/validate. It printed out "something" twice, but repaint/validate never happened.

It smells to me as if you're doing a long-running process on your GUI's event thread (or even worse, calling `Thread.sleep(...)` on the event thread), and that this is putting your GUI to sleep. Since this is a Swing GUI, are you using a SwingWorker to do your background work? If not, I strongly recommend that you do this. — Hovercraft Full Of Eels, Sep 29 '12 at 13:58
+1 to HFOE comment definitely sounds like you ar sleeping on your EDT. We could help much faster if you post a [SSCCE](http://sscce.org) — David Kroukamp, Sep 29 '12 at 14:00
`repaint()` likely is being called, but you're likely not seeing any effect due to threading issues as has been mentioned above. — Hovercraft Full Of Eels, Sep 29 '12 at 17:38
-1 for the umpteenth: you.do.something.completely.wrong. Start listening to the advices given and fix your threading mess. Without that, you'll never solve your problem. — kleopatra, Sep 30 '12 at 09:15

score 2 · Answer 1 · edited May 23 '17 at 11:43

2

I can see any issue with add / remove / modify JComponents in the container (JFrame --> JPanel e.i.)
depends if container (JPanel e.i.) is placed in JScrollPane
depends if you need to call pack() after add / remove / modify JComponents in the container, and then to change size of JFrame (for example) on the screen

edited May 23 '17 at 11:43

Community

1
1

answered Sep 29 '12 at 14:00

mKorbel

109,525
20
134
319

1

@David Kroukamp these are the moments when I'm not a slave to my endless laziness – mKorbel Sep 29 '12 at 14:02
Container, in fact, is in a JScroolPane (JFrame has a JScrollPane in which the JPanel container is set as Viewport). Is that bad and how can I fix it? I don't need to call pack(), and JFrame is not resized during the process, none of the components are (except for the Filler that reduces when component is added, listener is triggerd when it's height reaches 0 - that how I'm detecting the overflow). – Karlovsky120 Sep 29 '12 at 14:18

Listeners and validation/repainting

1 Answers1