[Java] Rozmiar i odświe?żanie panelu

0

Witam!
Przyszedł czas na zadawanie pytań (nikt tego nie lubi, bo to oznacza, że coś nie idzie po myśli :-8)

Od paru dni piszę program w Javie na zaliczenie (w czwartek rano :-8) i natknąłem się na parę problemów. Rozmawiałem już ze wszystkimi, których znam, a którzy kumają coś z Javy - i nic (na początku Kapustka trochę mnie nakierował - thnx).

A więc do rzeczy.
Piszę grę warcaby do prowadzenia rozgrywki on-line via internet. Ale problem leży w budowie interfejsu.

  1. Zdecydowanie ważniejszy kłopot, to ustawienie rozmiaru panelu na wybrany przeze mnie. Tu jest zrzut ekranu: http://www.marooned.neostrada.pl/pic/warcaby.gif.
    Potrzebuję, aby górny (pusty) panel miał wysokość 400 pikseli, a dolny ok. 25 (wysokość czcionki + marginesik).
    Jednak wszelkie próby ustawienia rozmiaru (poprzez metody setSize czy setBounds) spełzły na niczym.
    Na tej stronie: http://www.tek-tips.com/gviewthread.cfm/lev2/4/lev3/32/pid/269/qid/560301 jest informacja, że ów panel musi leżeć na innym o rozkładzie FlowLayout (tak to rozumiem). Ale nawet takie ustawienie nie działa.
    Byłbym wdzięczny za pomoc w tej kwestii. Zaliczenie zbliża się wielkimi krokami...

  2. A druga sprawa to odświeżanie panelu w metodzie mouseDragged. Problem w tym, że nie działa.
    Taki kod odświeża panel elegancko:
    [code]public void mousePressed(MouseEvent e)
    {Klient.pBoard.repaint();}[/code]ale już ten nie działa: [code]
    public void mouseDragged(MouseEvent e)
    {Klient.pBoard.repaint();}[/code]Macie może jakieś pomysły?
    Tutaj znalazłem jakiś przykład:
    http://www.dgp.toronto.edu/~mjmcguff/learn/java/04-mouseInput/
    i w nim jest repaint() w mouseDragged. Sam już nie wiem :|

0

Hejka.

Tym razem nie mam wiele czasu więc tylko po łebkach ...

  1. Rozmiar komponentu. Kurcze, ciekaw jestem ile razy mi się zdarzyło przez kilka godzin beznadziejnie walczyć z komponentem tak aby jego rozmiar był dokładnie taki jak chcę i aby się poprawnie zachowywał przy rozciąganiu.

Na szczęście w tym przypadku o rozciąganiu nie ma mowy.

Tak czy inaczej, są cztery ważne metody:
Component: (awt)
setSize(int,int)

JComponent: (a więc swing)
setMinimumSize(Dimension)
setPreferredSize(Dimension)
setMaximumSize(Dimension)

Przy czym to niestety nie wszystko. Równie ważny jest typ rozkładu, gdyż w niektórych przypadkach określenie rozmiaru jedną z powyższych metod nie jest w ogóle brane pod uwagę.

Kilka ważniejszych rozkładów:
FlowLayout
GridLayout
BorderLayout
BoxLayout

Generalnie wszelkie ustalenia rozmiaru są ignorowane w rozkładzie GridLayout (wolne miejsce jest po równo dzielone na każdy z komponentów) oraz (nie jestem tego pewien) BorderLayout.Center (przy czym w pozycji North już jest brane pod uwagę ustawienie PreferredSize ale tylko dotyczące wysokości)

Spoglądając na obrazki narzuca się BorderLayout. Popróbował bym z ustawieniem setPreferredSize. Metoda ta oczekuje referencji do obiektu klasy Dimension, którego dwuargumentowy konstruktor to:
Dimension(int x,int y)
czyli np. obiekt.setPreferredSize(new Dimension(300,180));

Ostatecznie ... niestety ... odsyłam do dokumentacji (można by rozważyć rozkład BoxLayout)

  1. Jestem zaskoczony. Ostatecznie jawne wywołanie repaint nie jest grzechem i jeżeli spowoduje to poprawne działanie kodu to jest to jak najbardziej do zaakceptowania.

... dokumentacja

acha - dokumentacja i tutoriale (wszystko dostępne na stronie sun'a) - to są tak doskonałe materiały, że z ich powodu chciałem podpinać pod komputer drugi monitor.

Pozdrawiam ... i powodzenia (bez eksperymentów się chyba nie obędzie)

0

No tak - zawsze czegoś się zapomni nadmienić. Nie napisałem, że nasz prowadzący narzucił nam korzystanie tylko z AWT :-[, więc metoda setPreferredSize odpada.

Piszesz o setSize, ale nie wiem dlaczego - napisałem, że ta funkcja nie działa (akurat w tym przypadku). Najprawdopodobniej związane jest to z nie odpowiednim rozkładem. Jednak próbowałem pójść tropem z ww. strony (FlowLayout). To nie dość, że dalej nie mogę zmienić rozmiaru, to jeszcze szachownica rysuje się tylko wokół połowy tego guzika :|

BorderLayout odpada, ponieważ docelowo mają być cztery rzędy (jeszcze na górze panel informacyjno-sterujący).

Ad. 2) Nie zakumałem Twojej odpowiedzi :|

A co do powtarzającego się świętego słowa 'dokumentacja'. Mam odpalonych z nią po kilka okien, znam już ją prawie na wylot (w zakresie przerabianego materiału). Również google ledwo się wyrabia.

A eksperymenty? Trwają już trzeci dzień.

Naprawdę nie zadawałbym tego pytania, gdyby odpowiedź była na wyciągnięcie ręki.
Jak komuś się nudzi, to może poszukać moich pytań na forum. Łatwo stwierdzić, czy umiem korzystać z pomocy czy dokumentacji. (Pamiętam jedno, na które sam sobie odpowiedziałem, ale każdemu może się zdarzyć ;-)).

0

wrrrrrrrrrrrrrrr.

Może źle to zinterpretowałem, ale odnoszę wrażenie że poświęcam swój czas i próbuję Tobie pomóc a ty w zamian się wściekasz ...

Tak czy inaczej, oczywiście BorderLayout mógłby przejść (i prawdopodobnie jest najlepszym rozwiązaniem) nawet pomimo tego, że chcesz zbudować cztery wiersze. Prosta sztuczka - swój panel informacyjny implementujesz w oddzielną klasę dziedziczącą po klasie Panel (domyślnie ta klasa będzie miała rozkład BorderLayout) i wkładasz pod-panel informacyjny na North a guziczki na South. Następnie obiekt tej całej klasy wkładasz na North (lub South) Applet'u

Czyli zagnieżdzony BorderLayout
(i wcale nie jest to takie "nietypowe" rozwiązanie jak mogłoby się wydawać)

Dlaczego tak się zapętliłem mówiąc o tej dokumentacji - między innymi dlatego, gdyż w nagłówku klasy BorderLayout jest sporo istotnych informacji o tym jak ten rozkład się zachowuje, a jego zachowanie jest specyficzne. (mam na myśli - komponenty umieszczone na North odmiennie się zachowują od tych umieszczonych na Center)

Chyba nie wiem co jest niezrozumiałe w drugiej odpowiedzi

Chyba nie wiem czemu się w ogóle szczypię w udzielanie wskazówek.

0

odnoszę wrażenie że poświęcam swój czas i próbuję Tobie pomóc a ty w zamian się wściekasz ...

To błędne wrażenie - jestem Ci bardzo wdzięczny za wszelkie wskazówki. Po prostu Java działa na mnie odpychająco. W BCB już bym ten program dawno zrobił i to pewnie w OpenGL ;-).

Chyba nie wiem co jest niezrozumiałe w drugiej odpowiedzi

Napisałeś tak:

Jestem zaskoczony. Ostatecznie jawne wywołanie repaint nie jest grzechem i jeżeli spowoduje to poprawne działanie kodu to jest to jak najbardziej do zaakceptowania.

Nie wiem, co Cię zaskoczyło. Kod kompiluje się i działa świetnie, ale - umieszczony repaint() w mouseDragged nie daje żadnego efektu, podczas ta sama metoda umieszczona np. w mousePressed robi to, co do niej należy.
Po prostu nie wiem, co mam zrobić, aby odświeżać panel w mouseDragged i tyle.

Chyba nie wiem czemu się w ogóle szczypię w udzielanie wskazówek.

Aby pomóc sfrustrowanemu koledze z forum?

0

Skontaktowałem się z prowadzącym zajęcia i dostałem rozwiązanie problemu. Wrzucę je tu, gdyby ktoś miał podobny kłopot.

  1. Aby stosować ustawienie ręcznie tzn. metodami setSize setBounds trzeba
    ustawić rozkład pusty tzn. setLayout(null) bo inaczej domyślnym jest
    setLayout(new FlowLayout()) i te metody nie zadziałaja bo komponenty są
    rozstawiane automatycznie.

  2. Jeżeli chodzi o odswiezanie to proponuje wejsc na strone
    www.studenci.prv.pl i przejzec kod zrodlowy apletu z cw 2. Zastosowano
    tam
    buforowanie i synchronizację i takie rozwiązanie jest optymalne tzn.
    działa
    na wszystkich syst. operac. Metoda która Pan przytoczył może powodowac
    migotanie całego apletu.

O ile rozkład przetestowałem (i działa) to na odświeżanie jeszcze nie miałem czasu - jak przetestuję, to zmienię ten post i napiszę, czy też działa.

[<font color="blue">dopisane</span>]
ech - Java zaliczona i już mi się nie chce tego testować :-P

0

Mój problem jest z tej samej beczki. Gierka saper z użyciem swinga. Przy zmianie poziomu gry powiększam ramkę (okno) jednak rozmiar panelu, w którym umieszczam pola pozostaje bez zmian. Co z tym zrobić?

0

Jak zwykle w takich przypadkach dokumentacja spieszy z pomocą :d.
Spróbuj tego użyć metody validate.

AWT uses validate to cause a container to lay out its subcomponents again after the components it contains have been added to or modified.

P.S.
Swinga nigdy nie używałem, ale metody z AWT powinny działać.

0

serdeczne dzieki. pomogło.

1 użytkowników online, w tym zalogowanych: 0, gości: 1