0

В отладке странного поведения в Swing я нашел следующие инструменты: CheckThreadViolationRepaintManager отредактировал версию Alex Ruiz. (Вы должны понять, что делает этот класс, прежде чем отвечать на мой вопрос, спасибо)Нарушение качающейся нити

И я устанавливаю нарушение потока в своем коде, но я не понимаю, почему, потому что я использую SwingUtilities.invokeAndWait() повсюду.

Вот код, вызывающий threadViolation. Только последняя строка вызывает ошибку:

protected void display() { 
    SwingUtilities.invokeLater(new Runnable() { 
     @Override 
     public void run() { 
      asyncDisplay(); 
     } 
    }); 
} 

private void asyncDisplay(){ 
    System.out.println("is in edt: " + SwingUtilities.isEventDispatchThread()); 
    this.printedComponent.setVisible(true); 
    this.printedComponent.setOpaque(false); 
    this.setVisible(true); 
} 

И результат:

is in edt: true 
exception: java.lang.Exception 
java.lang.Exception 
at fr.numvision.common.CheckThreadViolationRepaintManager.checkThreadViolations(CheckThreadViolationRepaintManager.java:31) 
at fr.numvision.common.CheckThreadViolationRepaintManager.addDirtyRegion(CheckThreadViolationRepaintManager.java:25) 
at javax.swing.JComponent.repaint(JComponent.java:4795) 
at java.awt.Component.imageUpdate(Component.java:3516) 
at javax.swing.JLabel.imageUpdate(JLabel.java:900) 
at sun.awt.image.ImageWatched$WeakLink.newInfo(ImageWatched.java:132) 
at sun.awt.image.ImageWatched.newInfo(ImageWatched.java:170) 
at sun.awt.image.ImageRepresentation.setPixels(ImageRepresentation.java:533) 
at sun.awt.image.ImageDecoder.setPixels(ImageDecoder.java:126) 
at sun.awt.image.GifImageDecoder.sendPixels(GifImageDecoder.java:447) 
at sun.awt.image.GifImageDecoder.parseImage(Native Method) 
at sun.awt.image.GifImageDecoder.readImage(GifImageDecoder.java:596) 
at sun.awt.image.GifImageDecoder.produceImage(GifImageDecoder.java:212) 
at sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:269) 
at sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:205) 
at sun.awt.image.ImageFetcher.run(ImageFetcher.java:169) 

Я действительно не понимаю, почему this.setVisible (правда); вызывает нарушение потока (это JComponent), а this.printedComponent.setVisible (true); dont.

Спасибо,

+0

Это вызывает нарушение, если поток, из которого был вызван 'setVisible', не был EDT. Причина, по которой может повлиять последняя строка, так как это может быть метод, соединяющий компонент с нативным равноправным узлом и запускающий процесс перерисовки, но это все угадывает работу, и для этого требуется пример выполнения. – MadProgrammer

+0

@MadProgrammer, пожалуйста, чтобы прочитать OPs вопрос и мои комментарии, чтобы ответить Марко Топольник – mKorbel

+0

У вас есть класс «CheckThreadViolationRepaintManager» и как он был установлен? – MadProgrammer

ответ

1

Код, который вызвал исключение не синхронизирован с вашей this.setVisible(true); линии. Эта строка просто помещает компонент как необходимый для перерисовки, и последнее событие перерисовывается позже, возвращается afer setVisible(). Похоже, что какой-то другой код, каким-то образом связанный с перекраской вашего компонента, представляет некоторый GUI-код для внешнего потока.

Детали всего этого невозможно получить из суммы отправленного вами кода.

+0

[SwingUtilities.invokeAndWait() вызывает исключение в случае, если EDT возвращает true] (http://stackoverflow.com/a/9796519/714968), должен использоваться из EDT, [то же самое для paintImmediatelly] (http://docs.oracle.com/javase/7/docs/api/javax/swing/JComponent.html#paintImmediately%28int,%20int,%20int,%20int% 29), оба могут вернуть awfull exception (когда RepaintManager может блокировать текущий JVM == addept только для убийств из TaskManager) – mKorbel

+0

код должен быть, он должен быть, если (! IsEDT) использовать invokeAndWait() else использовать invokeLater() :-) – mKorbel

+0

пожалуйста, удалите этот ответ здесь – mKorbel

 Смежные вопросы

  • Нет связанных вопросов^_^