O JPanel w stałym rozmiarze na JFrame

Jakiś czas temu poszukiwałem sposobu, aby zmodyfikowany przeze mnie JPanel zachowywał swój rozmiar niezależnie od wielkości okienka (obiekt JFrame), na którym bezpośrednio leżał. Kosztowało mnie to nieco nerwów. Nie wystarczyły metody setSize, setPreferredSize, setMaximumSize, setMinimumSize, użyte jak w poniższym przykładzie:

setSize(width, height);
setMaximumSize(getSize());
setMinimumSize(getSize());
setPreferredSize(getSize());

Niezależnie od moim starań potomek JPanel rozlewał się na całą powierzchnię obiektu JFrame. Winnym jest tutaj domyślny LayoutMenager obiektów JFrameBorderLayout (wniosek: warto zaglądać do dokumentacji). Osobiście uważam to za drażniące zachowanie rozszerzać na siłę element, łamiąc jego maksymalny ustawiony rozmiar, ale jak się nie ma co się lubi, to się lubi co się ma.

Rozwiązania widzę dwa: pierwsze to zmienić JFrame menadżera rozmieszczania elementów na np. FlowLayout. Drugim rozwiązaniem jest wstawienie naszego obiektu, nazwijmy go MyJPanel, w nowo utworzony obiekt JPanel i dopiero ten wstawić do JFrame. Zilustruje to małym przykładem:

JFrame frame = new JFrame("Test");
JPanel p = new JPanel();
p.add(new MyJPanel());
frame.getContentPane().add(p);

Teraz ten nowy, opakowujący JPanel jest rozszerzany przez obiekt okienka programu, a nasz – właściwy – pozostaje nietknięty. W sumie ta druga metoda to zastosowanie tej pierwszej w nieco inny sposób, ale może się przydać, jeśli z jakiegoś powodu nie mamy pełnego dostępu do obiektu JFrame.

Linki

Recipe for Java Cookies

Sztuka kulinarna jakoś nie jest kojarzona z informatyką. Jak jednak na to spojrzeć, to każdy przepis jest algorytmem – w końcu to jednoznaczny (uporządkowany nawet) zbiór instrukcji prowadzących do zamierzonego celu w skończonym czasie. Może przyczyną tego stanu rzeczy, jest fakt, iż przepisy są podawane w okropnej, dla ścisłych umysłów, formie tekstów wręcz “literackich”.

Wczoraj jednak, poszukując informacji na temat obsługi ciasteczek przez Javę, natrafiłem na poniższą stronę:

http://www.jibble.org/cookies.php

W tak przystępnej formie podany przepis, to kto wie, może i ja się kiedyś skuszę (o ile opanuje działanie piekarnika – ale o tym może i kiedy indziej).

Smacznego.

PS.: http://www.hccp.org/java-net-cookie-how-to.html – jakby ktoś poszukiwań na ten sam temat co i ja. Jeszcze nie skorzystałem, ale widzi mi się, że powinno zadziałać, jakby co – będzie kolejny wpis:)

Starym sposobem – mnemoniki w Swingu (Java)

Dziś ponownie Java; dotarło do mnie, że Swing nie obsługuje znak & w nazwach menusów i przycisków do nich, mają na to osobną funkcję, lub też przeładowane konstruktory. Ma to kilka swoich plusów, ma też kilka minusów. Ot chciałem w prosty sposób dorobić w moim programie klawisze skrótów w menu, z tym, że oczywiście teksty samego menu, byłby wczytywane z klasy zasobów – tutaj nieco szerzej o tym – nie mogę z tego powodu wklepać ich na stałe.

Postanowiłem więc dorobić na szybko taką małą metodę, która dorabiała by “mnemonic” na podstawie samego tylko stringu (dzięki zastosowaniu znaku &).

public JMenuItem newMenuItem(String label) {
	JMenuItem resItem = null;
	int tmp = label.indexOf('&');
 
	// Sprawdzamy, czy w ogóle w etykietce jest zaznaczony klawisz skrótu.
	if (tmp > -1) {
		// usuwamy znak & przez podział stringu label wedłu znaku ktoruy chcemy usunąc
		String[] strArray = label.split('&', 2);
		// teraz sklejamy obie połówki, ako skrót określamy znak, stojący na prawo od &
		res = new JMenuItem(strArray[0] + strArray[1], label.charAt(tmp +1));
	}
	else
		res = new JMenuItem(label);
	return res;
}

Kod jak widzicie dość prowizoryczny, ale mi wystarczył. Jeśli ktoś ma jakieś 3 grosze do niego, zapraszam tu na dole można je wklepać.

Pytanie do kogoś kto zna się na Javie (lub wzorcach projektowych).

Przyznam się bez bicia, że nie za wiele miałem okazji po programować w Javie. Stąd zastanawiam się, czy tak się robi, jak robię ja.

Chciałem w programie wykorzystać klasę ResourceBundle, jak wiemy, mniej więcej tak wygląda jej wykorzystanie:

Ja jednak chciałem uniknąć wklepywania z palca tych Stringów (parametrów metody getString, trochę dla wygody (dopełnienia w Eclipsie), trochę, żeby nie było błędów (literówek w nazwach).

Stworzyłem więc enuma (w końcu na Javie 1.6 – o pardon – 6.0, robię, a one nowością były w 5tce) nazwijmy go teksty:

Enum eTeksty {
	OkKey,
	CancelKey;
}

Dorobiłem do tego klasę, taką “nadbudówkę” (to się chyba ładnie dekorator nazywa) na klasę ResourceBundle, nazwę ją tutaj PobierzTekst:

public class PobierzTekst {
	private ResourceBundle resource;
 
	public PobierzTekst() {
		// Tutaj inicjowanie zmiennej resource - w normalny sposób, mamy potworzone w programie klasy obsługujące języki.
	}
 
	public String getTekst(eTeksty text) {
		try {
			return resource.getString(text.toString());
		}
		catch(...) {
			/*
				Tutaj w zależności od wypadku zwracam albo pusty tekst,
				albo krótką notkę np.: "[brak tekstu dla" + text.toString() + "]";
			*/
		}
	}
 
}

A w programie wykorzystanie tego wygląda następująco:

PobierzTekst myResources = new PobierzTekst();
button1 = new Button(myResources.getTekst(eTekst.OkKey));

Pytanie więc do osób, które się znają na Javie, czy to rozwiązanie jest w porządku? Czy zawsze będzie działać (np.: różne maszyny wirtualne różnie reagują na enumy) itp? Czy w ogóle, tak się robi, czy nie można prościej?

Jeszcze dopowiem, że mam też inne klasy zasobów, np.: z tekstami o błędach, do nich kolejnego enuma, i przeciążoną metodę getTekst.