Cześć ;-)
Robię grę w kółko i krzyżyk,i mam problem z przeładowaniem planszy.
Próbowałem "plansza = new JPanel()",ale to nie usunęło wszystkich kontrolek z JPanel.
Co zrobić [???]
0
0
powinno pomóc:
plansza.getContentPane().removeAll();
plansza.setVisible(true);
0
Dzięki DooM77,ale dlaczego znowu setVisible()?
0
Użyłem setVisible, bo sam chciałem niedawno oczyścić panel i w mojej sytuacji dobrze działało tylko setVisible(true). W teorii powinno też działać plansza.repaint() i byłoby to w lepszym stylu, więc wypróbuj i to.
0
Dzięki ;-), zanim zapytałem na forum nie mogłem dokończyć projektu.
0
Dlaczego validate() lub pack(), a nie repaint()?
Ponieważ repaint odrysowuje bieżący stan komponentów graficznych. Natomiast dodawanie i usuwanie lub zmiana właściwości klas dziedziczonych po Swing nie uaktualnia na bieżąco tych komponentów. Nad komponentami pełną władzę ma JVM (komponenty lekkie) i system operacyjny (komponenty ciężkie). Swing oznacza do aktualizacji obiekty klas wywodzących się ze Swing, przez wywołanie dla nich invalidate(). Natomiast zaktualizowanie komponentów graficznych na podstawie zmienionych właściwości klas Swing następuje przez rekursywne wywoływanie validate() dla wszystkich klas, które są związane z wyświetlonymi na ekranie komponentami i nie mają zaktualizowanego wyglądu (czyli dla których isValid() daje false).
To dlatego repaint() nie daje żadnego efektu. Metoda ta daje efekt tylko gdy samodzielnie podmieniamy metodę paint() i gdy jej rysowanie korzysta z bieżącego stanu klasy (a nie wewnętrznych danych komponentu graficznego).
Utożsamianie klasy wywiedzionej ze Swing z obiektem wyrysowanym na ekranie jest błędem i zbyt dużym uproszczeniem. W szczególności komponenty heavyweight, czyli kontrolowane bezpośrednio przez podsystem graficzny żyją własnym życiem, mocno niezależnym od klas, które je rzekomo reprezentują. Klasy te mają zazwyczaj jedynie przepis na konstrukcję.
Np. Jeżeli raz wywołamy setVisible() dla JFrame, co jest tłumaczone na wywołanie procedury createWindow() systemu, to dopóki któraś z metod nie zaktualizuje tego okna (w sensie wywołania API), to wszelkie zmiany najróżniejszych zmiennych klasy nie będzie miało na utworzone okno żadnego wpływu. Przynajmniej tak długo jak nie zostanie wywołana procedura aktualizacji stanu okna. A to ostatnie jest przez Swing stosowane bardzo oszczędnie najpierw zbierając wszelkie potrzebne zmiany, a potem robiąc je "hurtem" w trakcie wywołania validateTree(). W przypadku klas komponentów lekkich jest jeszcze ciekawiej bo dla systemu te wszystkie komponenty rysowane bezpośrednio przez Swing nie są żadnymi komponentami GUI, tylko swobodnymi artystycznymi bohomazami, które tylko przypadkiem wyglądają i zachowują się jak normalne okna systemu operacyjnego. Ich zamazanie przez okna systemu byłoby przez ten system w ogóle niezauważane gdyby nie to, że komponenty lekkie są umieszczane zawsze w jakimś ciężkim (właśnie dlatego ciężkimi są okna top-level), wobec czego Swing każdorazowo dowie się, że coś kontrolowane przez system (inne programy, np, natywne) zamazało ekran w miejscu gdzie powinny być rysowane komponenty lekkie. Wtedy też Swing reaguje tak jak każdy inny system okienkowy - odtwarza zawartość tych zamazanych miejsc. Dlatego jeżeli komponent lekki nie jest opaque, to komponent może wydawać się częściowo przezroczysty).