Komponenty nie pojawiają się po 2. utworzeniu okna
Bogdan (bogdro)
Mam następujący problemik: gdy tworzę okno z metody main(), to
wszystko działa (tzn. pojawiają się: Label, TextField i Button). Zaś gdy
tworzę to samo okno z metody actionPerformed(), to nie pojawia się nic.
Tylko kursor myszy się zmienia, gdy najadę na niewidzialne TextField.
Okienko nie reaguje nawet na zamknięcie, mimo iż wcześniej reagowało.
Dlaczego tak się dzieje i jak temu zaradzić?
--
Pozdrawiam, Bogdan (Linux & FreeDOS)
Grupy dyskusyjne o assemblerze: news:alt.pl.asm news:alt.pl.asm.win32
Kurs assemblera x86 (DOS i Linuks): http://rudy.mif.pg.gda.pl/~bogdro
Używam: www.firefox.pl www.thunderbird.pl http://dev.null.pl/ekg/
Człowiek z uchwytem od wiadra
> Zaś gdy
> tworzę to samo okno z metody actionPerformed(), to nie pojawia się nic.
> Tylko kursor myszy się zmienia, gdy najadę na niewidzialne TextField.
> Okienko nie reaguje nawet na zamknięcie, mimo iż wcześniej reagowało.
Prawdpodobnie blokujesz wątek zdarzeń w jakiś sposób. Wyizoluj problem i
rzuć kawałek kodu na grupę, to się zobaczy.
--
Zbyszek Malec Ustronie 104 gg:2756100
Bogdan (bogdro)
Wszystko jest możliwe. Tym bardziej, że (jak widać?) jestem
początkujący (czytaj: nie śmiać się z kodu).
Opis problemu: program albo czyta 1 parametr z linii poleceń, albo
(jeśli go nie ma) otwiera okienko z zapytaniem. To okienko działa
prawidłowo. Drugie okienko (to bez komponentów) pojawia się po
kliknięciu na pozycję w menu w oknie głównym, tworzonym przez
otworz_plik(). Okno główne przed kilknięciem "Otwórz..." w menu też
działa prawidłowo, a po - także przestaje reagować.
Oto istotne fragmenty kodu (trochę wyciąłem, żeby linie się nie łamały
zbytnio):
public static void main ( String args[] ) {
if ( args != null && args.length > 0 ) {
nazwaPliku = args[0];
} else {
// OknoPliku wczytuje nazwaPliku
OknoPliku op = new OknoPliku();
while ( nazwaPliku == null ) {};
op = null;
};
try {
otworz_plik ( nazwaPliku );
} catch ( IOException ex ) {
// OknoBlad() zamknie program, stąd while(true);
OknoBlad ob = new OknoBlad ( "Wyjatek " + ex );
while (true);
};
};
// tu jest obsluga menu
public void actionPerformed ( ActionEvent e ) {
String nazwa = e.getActionCommand();
if ( nazwa.equals ( "Zamknij" ) ) {
dispose();
System.exit(0);
} else
if ( nazwa.equals ( "Otworz..." ) ) {
nazwaPliku = null;
OknoPliku op = new OknoPliku();
while ( nazwaPliku == null ) {};
op = null;
try {
otworz_plik ( nazwaPliku );
} catch ( IOException ex ) {
OknoBlad ob = new OknoBlad ("Wyjatek");
while (true);
};
}
};
};
class OknoPliku extends Frame implements ActionListener {
private Button otworz = null;
private TextField tf = null;
public OknoPliku () {
setTitle ( "Podaj nazwe pliku do przetworzenia" );
setLayout ( new FlowLayout() );
setLocation ( 200, 100 );
setSize ( 600, 100 );
this.addWindowListener ( new WindowAdapter () {
public void windowClosing ( WindowEvent e ) {
dispose();
System.exit(0);
};
});
add ( new Label ( "Plik z danymi:" ) );
tf = new TextField ( 50 );
tf.setEnabled ( true );
tf.setEditable ( true );
tf.setVisible ( true );
add (tf);
otworz = new Button ( "Otworz" );
otworz.setEnabled ( true );
otworz.addActionListener(this);
otworz.setVisible ( true );
add (otworz);
setVisible ( true );
};
public void actionPerformed ( ActionEvent ev ) {
String nazwa = ev.getActionCommand();
if ( nazwa.equals("Otworz") ) {
if ( tf.getText().length() > 0 ) {
Wykresy.nazwaPliku = tf.getText();
dispose();
};
};
};
};
Dzięki za zainteresowanie.
Człowiek z uchwytem od wiadra
> Wszystko jest możliwe. Tym bardziej, że (jak widać?) jestem
> początkujący (czytaj: nie śmiać się z kodu).
Spokojnie. O ile ktoś się nie mądrzy za bardzo, albo nie zrobi czegoś
naprawdę głupiego, to nikt się z nikogo nie śmieje. Conajwyżej możesz
liczyć na konstruktywną krytykę ;)
> Oto istotne fragmenty kodu (trochę wyciąłem, żeby linie się nie łamały
> zbytnio):
Wydaje mi się, że wyciąłeś dość istotny fragment. Ale o tym dalej.
> OknoPliku op = new OknoPliku();
> while ( nazwaPliku == null ) {};
> op = null;
Nie jest dobrze. Takie aktywne oczekiwanie zarżnie ci kompa. Nie masz
przypadkiem użycia procesora na poziomie 100%? :> Jeżeli już aktywne
oczekiwanie chcesz zrobić, to musisz dać szansę innym.
while( nazwaPliku == null)
Thread.yield(); //ewentualnie sleep z jakąś małą wartością
Przy okazji takie gołe miejsca są dosyć niebezpieczne, może być problem z
dostępem między wątkami (nie jestem pewien, czy nie zachodzi tu ten sam
problem, co double checking idiom, może ktoś mądrzejrzy się wypowie).
Rozumiem, że chcesz wstrzymać program do czasu, aż nazwa pliku będzie
wczytana. Jeżeli tak, to lepiej zastosuj modalny dialog zamiast ramki
(Frame) jako okienko do wczytania pliku (jest też gotowy komponent do
otwierania plików, nazywa się FileChooser lub JFileChooser). Taki modalny
dialog wstrzyma wątek rodzica do czasu swojego zamknięcia. Możesz
ewentualnie też zrobić wait na jakimś wspólnym obiekcie, a w OknoPliku na
koniec dać notifyAll.
Najlepiej jednak poczytaj o klasie Dialog.
> try {
> otworz_plik ( nazwaPliku );
> } catch ( IOException ex ) {
> // OknoBlad() zamknie program, stąd while(true);
Dlaczego i w jaki sposób OknoBlad zamknie program? Wywołujesz dispose czy
System.exit? Zresztą jak nie chcesz, żeby okno zamykało ci aplikację, to po
prostu usuń taką akcję z tego okna. Aplikacja nie powinna się zakończyć
przed zamknięciem twojego okienka błędu.
> OknoBlad ob = new OknoBlad ( "Wyjatek " + ex );
> while (true);
Znowu aktywne oczekiwanie. Takie rozwiązanie nie jest dobre, ba, jest
bardzo złe. Na 100% da się inaczej to rozwiązać (problem z zamykaniem), to
nie jest dobre rozwiązanie.
> nazwaPliku = null;
> OknoPliku op = new OknoPliku();
>
> while ( nazwaPliku == null ) {};
> op = null;
To nie ma prawa tu być. Właśnie zablokowałeś wątek zdarzeń. Aktywne
oczekiwanie jest ogólnie złe, natomiast w tym miejscu nie ma absolutnie
prawa się pojawić. Zastosuj jedno z rozwiązań które ci podałem wcześniej, a
najlepiej właśnie Dialog modalny.
> OknoBlad ob = new OknoBlad ("Wyjatek");
> while (true);
Aktywne oczekiwanie... Zmień kod tak, żeby nie było potrzebne.
> class OknoPliku extends Frame implements ActionListener {
...
> this.addWindowListener ( new WindowAdapter () {
>
> public void windowClosing ( WindowEvent e ) {
> dispose();
> System.exit(0);
> };
> });
Czy naprawdę chcesz zamknąć całą aplikację zamykając okno wyboru pliku?
> tf.setEnabled ( true );
> tf.setEditable ( true );
> tf.setVisible ( true );
To jest zbędne. Domyślnie są właśnie na true. Podobnie jest z przyciskiem.
> Wykresy.nazwaPliku = tf.getText();
Ja bym to rozwiązał trochę inaczej. Albo zrobic statyczną metodę w klasie
okna do pobierania pliku zwracającą nazwę pliku (a jeszcze lepiej obiekt
File)
File getFileFromUser();
czy coś takiego, która się zatroszczy o utworzenie takiego okna, potem to
okno zamknie i zwróci odpowiedni plik, lub też stworzyć metodę
niestatyczną, File getFile(), którą będziesz wywoływał, aby pobrać z
obiektu okna plikowego wybrany plik.
OknoPliku op = new OknoPliku();
File file = op.getFile();
if(file != null)
mamy plik.
coś na kształt. Pozbędziesz się wtedy odwołań do klas niezwiązanych
bezpośrednio z samym pobieraniem pliku (Wykresy).
Człowiek z uchwytem od wiadra
> class OknoPliku extends Frame
A w ogóle to zainteresu się Swingiem, bo AWT ma raczej skromne możliwości i
nie jest właściwie rozwijane. Przejrzyj pakiet javax.swing. Komponenty z
AWT maja tam swoje odpowiedniki, natomiast swing oferuje ich więcej i
trochę w innej filozofii. U ciebie sprowadzi się to właściwie do wymiany
klas Component na JComponent (np Button na JButton), więc przejście na tym
etapie projektu nie będzie bolesne.
Bogdan (bogdro)
Słyszałem o tym Swing. Podobno łatwo i szybko się w nim pisze. Masz
jakiś link do kursu dla amatorów pod ręką, czy będę musiał zapuścić
google? Tylko nie ten ze stron Sun - nie odpowiada mi, zbyt duże
przeskoki między jednym programem a drugim.
Oczywiście, z *dokumentacji* na stronach Sun'a korzystam i na pewno
tam zajrzę.
Człowiek z uchwytem od wiadra
> Słyszałem o tym Swing. Podobno łatwo i szybko się w nim pisze. Masz
> jakiś link do kursu dla amatorów pod ręką, czy będę musiał zapuścić
> google?
Niestety.
Może masz pod ręką jakąś bibliotekę informatyczną? Bardzo dobrą książką
jest Java2: Podstawy wydawnictwa Core. Prawdopodobnie w Thinking in Java
też będzie Swing (nie wiem, nie czytałem). To drugie w wersji angielskiej
jest do ściągniecia za darmo ze strony autora.
a1
<ciah>
>> nazwaPliku = null;
>> OknoPliku op = new OknoPliku();
>>
>> while ( nazwaPliku == null ) {};
>> op = null;
>
>
> To nie ma prawa tu być. Właśnie zablokowałeś wątek zdarzeń. Aktywne
> oczekiwanie jest ogólnie złe, natomiast w tym miejscu nie ma absolutnie
> prawa się pojawić. Zastosuj jedno z rozwiązań które ci podałem wcześniej, a
> najlepiej właśnie Dialog modalny.
Drobna korekta, wait w tym miejscu zrobi dokladnie to samo co while(),
tutaj moze zastosowac tylko i wylacznie modal'a.
--
a1
Bogdan (bogdro)
>
>> Wszystko jest możliwe. Tym bardziej, że (jak widać?) jestem
>>początkujący (czytaj: nie śmiać się z kodu).
>
>
> Spokojnie. O ile ktoś się nie mądrzy za bardzo, albo nie zrobi czegoś
> naprawdę głupiego, to nikt się z nikogo nie śmieje. Conajwyżej możesz
> liczyć na konstruktywną krytykę ;)
Cieszę się. Różni ludzie się szwędają po różnych grupach.
>> Oto istotne fragmenty kodu (trochę wyciąłem, żeby linie się nie łamały
>>zbytnio):
>
>
> Wydaje mi się, że wyciąłeś dość istotny fragment. Ale o tym dalej.
Co najwyżej mogłem go nie wkleić. Powycinałem tylko długie komentarze,
długie komunikaty. Stwierdziłem, że poza tym nie ma nic
"niestandardowego" w moim programie, co rzuciłoby więcej światła.
>> OknoPliku op = new OknoPliku();
>> while ( nazwaPliku == null ) {};
>> op = null;
>
>
> Nie jest dobrze. Takie aktywne oczekiwanie zarżnie ci kompa. Nie masz
> przypadkiem użycia procesora na poziomie 100%? :> Jeżeli już aktywne
> oczekiwanie chcesz zrobić, to musisz dać szansę innym.
>
> while( nazwaPliku == null)
> Thread.yield(); //ewentualnie sleep z jakąś małą wartością
Nie używam wątków, nie zagłębiałem się w nie. Wait() nie można wywołać z
metody statycznej, o sleep() zapomniałem (bo też nigdzie jakoś nie
zwróciłem uwagi, że taka metoda istnieje). Tak więc
while ( nazwaPliku == null ) {
sleep (/* 0.5 sekundy */);
};
byłoby lepsze (gdzie jest definicja sleep()?) od pustej pętli?
> Przy okazji takie gołe miejsca są dosyć niebezpieczne, może być problem z
> dostępem między wątkami (nie jestem pewien, czy nie zachodzi tu ten sam
> problem, co double checking idiom, może ktoś mądrzejrzy się wypowie).
>
> Rozumiem, że chcesz wstrzymać program do czasu, aż nazwa pliku będzie
> wczytana. Jeżeli tak, to lepiej zastosuj modalny dialog zamiast ramki
> (Frame) jako okienko do wczytania pliku (jest też gotowy komponent do
> otwierania plików, nazywa się FileChooser lub JFileChooser). Taki modalny
> dialog wstrzyma wątek rodzica do czasu swojego zamknięcia. Możesz
> ewentualnie też zrobić wait na jakimś wspólnym obiekcie, a w OknoPliku na
> koniec dać notifyAll.
>
> Najlepiej jednak poczytaj o klasie Dialog.
To był mój pierwszy "większy" program. Nie zagłębiałem się bardziej,
chciałem tylko, żeby działało. Klasę Dialog widzę teraz. Kilka
nieciekawych metod - np. jak wiedzieć, że już mam, to co trzeba itp?
Jeszcze trochę nauki przede mną. Dlatego też chciałem zacząć od czegoś
prostego.
>> try {
>> otworz_plik ( nazwaPliku );
>> } catch ( IOException ex ) {
>>// OknoBlad() zamknie program, stąd while(true);
>
>
> Dlaczego i w jaki sposób OknoBlad zamknie program? Wywołujesz dispose czy
> System.exit? Zresztą jak nie chcesz, żeby okno zamykało ci aplikację, to po
> prostu usuń taką akcję z tego okna. Aplikacja nie powinna się zakończyć
> przed zamknięciem twojego okienka błędu.
OknoBlad wyśwetla tekst. Po naciśnięciu przycisku "Zamknij" lub
krzyżyka w oknie, zamykany jest program poprzez dispose() i
System.exit(). Chyba się wzajemnie nie wykluczają?
Tak więc aplikacja jest zamykana w chwili zamknięcia okienka błędu.
[...]
>> nazwaPliku = null;
>> OknoPliku op = new OknoPliku();
>>
>> while ( nazwaPliku == null ) {};
>> op = null;
>
>
> To nie ma prawa tu być. Właśnie zablokowałeś wątek zdarzeń. Aktywne
> oczekiwanie jest ogólnie złe, natomiast w tym miejscu nie ma absolutnie
> prawa się pojawić. Zastosuj jedno z rozwiązań które ci podałem wcześniej, a
> najlepiej właśnie Dialog modalny.
Dobrze, spróbuję coś wykombinować. To już jest niestatyczna metoda, więc
może wait()+notifyAll() w drugim okienku.
>>class OknoPliku extends Frame implements ActionListener {
>
> ...
>
>> this.addWindowListener ( new WindowAdapter () {
>>
>> public void windowClosing ( WindowEvent e ) {
>> dispose();
>> System.exit(0);
>> };
>> });
>
>
> Czy naprawdę chcesz zamknąć całą aplikację zamykając okno wyboru pliku?
Działanie programu opiera się na czytaniu danych z pliku. Bez tego nie
ma co dalej uruchamiać. Na razie taki jest mój wybór.
>> tf.setEnabled ( true );
>> tf.setEditable ( true );
>> tf.setVisible ( true );
>
>
> To jest zbędne. Domyślnie są właśnie na true. Podobnie jest z przyciskiem.
Domyślałem się, że tak jest. Tutaj widać przykład aktu desperacji.
>> Wykresy.nazwaPliku = tf.getText();
>
>
> Ja bym to rozwiązał trochę inaczej. Albo zrobic statyczną metodę w klasie
> okna do pobierania pliku zwracającą nazwę pliku (a jeszcze lepiej obiekt
> File)
>
> File getFileFromUser();
>
> czy coś takiego, która się zatroszczy o utworzenie takiego okna, potem to
> okno zamknie i zwróci odpowiedni plik, lub też stworzyć metodę
> niestatyczną, File getFile(), którą będziesz wywoływał, aby pobrać z
> obiektu okna plikowego wybrany plik.
>
> OknoPliku op = new OknoPliku();
> File file = op.getFile();
> if(file != null)
> mamy plik.
>
> coś na kształt. Pozbędziesz się wtedy odwołań do klas niezwiązanych
> bezpośrednio z samym pobieraniem pliku (Wykresy).
OK, pomyślę. Najpierw mam większy problem do rozwiązania.
Dzięki za rady, wkrótce postaram się znów usiąść do mojego programu.
a1
<ciah>
> Nie używam wątków, nie zagłębiałem się w nie. Wait() nie można wywołać z
> metody statycznej, o sleep() zapomniałem (bo też nigdzie jakoś nie
> zwróciłem uwagi, że taka metoda istnieje). Tak więc
>
> while ( nazwaPliku == null ) {
> sleep (/* 0.5 sekundy */);
> };
> byłoby lepsze (gdzie jest definicja sleep()?) od pustej pętli?
Nie :) lepsze by bylo:
OknoPliku dialog = new OknoPliku(mainFrame);
dialog.setModal(true);
dialog.show();
// tutaj program sie zatrzyma az do zakonczenia dzialania modala
// przez hide lub dispose
<doc>
If the dialog is modal and is not already visible, this call will not
return until the dialog is hidden by calling hide or dispose. It is
permissible to show modal dialogs from the event dispatching thread
because the toolkit will ensure that another event pump runs while the
one which invoked this method is blocked.
</doc>
> To był mój pierwszy "większy" program. Nie zagłębiałem się bardziej,
> chciałem tylko, żeby działało. Klasę Dialog widzę teraz. Kilka
> nieciekawych metod - np. jak wiedzieć, że już mam, to co trzeba itp?
Patrz wyzej, bez dialoga ani rusz :D.
>
>>> try {
>>> otworz_plik ( nazwaPliku );
>>> } catch ( IOException ex ) {
>>> // OknoBlad() zamknie program, stąd while(true);
>>
>>
>>
>> Dlaczego i w jaki sposób OknoBlad zamknie program? Wywołujesz dispose czy
>> System.exit? Zresztą jak nie chcesz, żeby okno zamykało ci aplikację,
>> to po
>> prostu usuń taką akcję z tego okna. Aplikacja nie powinna się zakończyć
>> przed zamknięciem twojego okienka błędu.
>
>
> OknoBlad wyśwetla tekst. Po naciśnięciu przycisku "Zamknij" lub
> krzyżyka w oknie, zamykany jest program poprzez dispose() i
> System.exit(). Chyba się wzajemnie nie wykluczają?
> Tak więc aplikacja jest zamykana w chwili zamknięcia okienka błędu.
> [...]
Chodzi o to ze tak dlugo jak masz aktywne watki, aplikacja sie nie
zakonczy, a poki masz przynajmniej jedno okno to masz watek kolejki
komunikatow, po usunieciu ostatniego okna (przez dispose), watek kolejki
AWT i tak sie zakonczy wiec sam sie zamknie, System.exit to nadmiar
szczescia pozatym jest nieelegancki.
>
>>> nazwaPliku = null;
>>> OknoPliku op = new OknoPliku();
>>>
>>> while ( nazwaPliku == null ) {};
>>> op = null;
>>
>>
>>
>> To nie ma prawa tu być. Właśnie zablokowałeś wątek zdarzeń. Aktywne
>> oczekiwanie jest ogólnie złe, natomiast w tym miejscu nie ma absolutnie
>> prawa się pojawić. Zastosuj jedno z rozwiązań które ci podałem
>> wcześniej, a
>> najlepiej właśnie Dialog modalny.
>
>
> Dobrze, spróbuję coś wykombinować. To już jest niestatyczna metoda, więc
> może wait()+notifyAll() w drugim okienku.
Efekt bedzie ten sam, wait rowniez zatrzyma ci kolejke watkow AWT, tutaj
musisz zrobic modal'a
--
a1
Bogdan (bogdro)
> Bogdan (bogdro) wrote:
>
> <ciah>
>
>> Nie używam wątków, nie zagłębiałem się w nie. Wait() nie można wywołać
>> z metody statycznej, o sleep() zapomniałem (bo też nigdzie jakoś nie
>> zwróciłem uwagi, że taka metoda istnieje). Tak więc
>>
>> while ( nazwaPliku == null ) {
>> sleep (/* 0.5 sekundy */);
>> };
>> byłoby lepsze (gdzie jest definicja sleep()?) od pustej pętli?
>
>
> Nie :) lepsze by bylo:
> OknoPliku dialog = new OknoPliku(mainFrame);
> dialog.setModal(true);
> dialog.show();
>
> // tutaj program sie zatrzyma az do zakonczenia dzialania modala
> // przez hide lub dispose
> <doc>
> If the dialog is modal and is not already visible, this call will not
> return until the dialog is hidden by calling hide or dispose. It is
> permissible to show modal dialogs from the event dispatching thread
> because the toolkit will ensure that another event pump runs while the
> one which invoked this method is blocked.
> </doc>
No, wydaje się to fajna rzecz, ale:
1. okienko przecież można zamknąć bez podawania informacji, którą
potrzebuję (krzyżykiem). Czyli znów muszę sprawdzać w pętli, czy
nazwaPliku != null ?
2. moja (najnowsza) Java nie rozpoznaje tej funkcji.
(3. ponoć należy używać setVisible(bool), ale to nieistotny szczegół )
[...]
[zamykanie programu:]
> Chodzi o to ze tak dlugo jak masz aktywne watki, aplikacja sie nie
> zakonczy, a poki masz przynajmniej jedno okno to masz watek kolejki
> komunikatow, po usunieciu ostatniego okna (przez dispose), watek kolejki
> AWT i tak sie zakonczy wiec sam sie zamknie, System.exit to nadmiar
> szczescia pozatym jest nieelegancki.
Czyli jak prawidłowo zamknąć program, ale np. nie z okna głównego, a z
okienka wyświetlającego jakiś błąd?
[...]
> Efekt bedzie ten sam, wait rowniez zatrzyma ci kolejke watkow AWT, tutaj
> musisz zrobic modal'a
I tak się nie udało, bo jakieś metody trzeba posynchronizować (ech,
muszę doczytać). Co prawda komponenty się pojawiły, ale nic nie
działało, tylko sypało wyjątkami.
a1
jest deprecated.
> [zamykanie programu:]
>
>> Chodzi o to ze tak dlugo jak masz aktywne watki, aplikacja sie nie
>> zakonczy, a poki masz przynajmniej jedno okno to masz watek kolejki
>> komunikatow, po usunieciu ostatniego okna (przez dispose), watek
>> kolejki AWT i tak sie zakonczy wiec sam sie zamknie, System.exit to
>> nadmiar szczescia pozatym jest nieelegancki.
>
>
> Czyli jak prawidłowo zamknąć program, ale np. nie z okna głównego, a z
> okienka wyświetlającego jakiś błąd?
Po zamknieciu wszyskich okien aplikacja sama sie zamknie... wiec jezeli
to okienko z bledem bylo jedynym twoim okienkiem (a tak mi sie z kodu
cos wydaje), to apikacja sama sie zamknie.
--
a1
Człowiek z uchwytem od wiadra
> Drobna korekta, wait w tym miejscu zrobi dokladnie to samo co while(),
> tutaj moze zastosowac tylko i wylacznie modal'a.
Faktycznie. To bym dopiero pomógł :D
Bogdan (bogdro)
Wiem. Zanim cokolwiek napisałem, przejrzałem trochę archiwum. A w
czytniku news jako jeden z najstarszych dostępnych wątków pojawił się
"dobry kurs javy" czy jakoś tak. Książkę TiJ więc już mam. Po krótkim
spojrzeniu okiem, rozdział o tworzeniu okien itp. korzysta ze Swinga,
więc też sobie poczytam.
Pytałem się o kurs, bo prawie wszystko, co napotkałem to kopie tego
samego tłumaczenia kursu Sun'a. Tutaj jednak jest coś fajnego:
http://www.man.koszalin.pl/~rataj/java/. Po lekturze tego krótkiego
kursiku od razu mogłem zacząć pisać programy. I to mi się spodobało.
Człowiek z uchwytem od wiadra
>> Czy naprawdę chcesz zamknąć całą aplikację zamykając okno wyboru pliku?
>
> Działanie programu opiera się na czytaniu danych z pliku. Bez tego nie
> ma co dalej uruchamiać. Na razie taki jest mój wybór.
Z tego co widzę, to akcję otwierania pliku podejmuje ręcznie użytkownik.
Być może lepiej by było, gdyby po prostu program nie podejmował żadnej
akcji gdy użytkownik zamknie okienko wyboru pliku.
Rozumiem że chwilowo nie jest to najważniejsza część twojego programu ;)
Człowiek z uchwytem od wiadra
>> Nie :) lepsze by bylo:
>> OknoPliku dialog = new OknoPliku(mainFrame);
>> dialog.setModal(true);
>> dialog.show();
>>
>> // tutaj program sie zatrzyma az do zakonczenia dzialania modala
>> // przez hide lub dispose
>> <doc>
>> If the dialog is modal and is not already visible, this call will not
>> return until the dialog is hidden by calling hide or dispose. It is
>> permissible to show modal dialogs from the event dispatching thread
>> because the toolkit will ensure that another event pump runs while the
>> one which invoked this method is blocked.
>> </doc>
>
> No, wydaje się to fajna rzecz, ale:
> 1. okienko przecież można zamknąć bez podawania informacji, którą
> potrzebuję (krzyżykiem). Czyli znów muszę sprawdzać w pętli, czy
> nazwaPliku != null ?
"Otwórz" udostępniasz z poziomu menu. Jeżeli user nie poda informacji, to
nic nie rób. Poczekaj aż użytkownik w końcu wybierze.
> 2. moja (najnowsza) Java nie rozpoznaje tej funkcji.
Której funkcji? Uwaga terminologiczna - metoda, nie funkcja.
>> Efekt bedzie ten sam, wait rowniez zatrzyma ci kolejke watkow AWT, tutaj
>> musisz zrobic modal'a
>
> I tak się nie udało, bo jakieś metody trzeba posynchronizować (ech,
> muszę doczytać). Co prawda komponenty się pojawiły, ale nic nie
> działało, tylko sypało wyjątkami.
W twoim przypadku nie ma tam co synchronizować. Modal wstrzyma ci wątek
głównego okna do czasu jego schowania, więc tutaj masz synchronizację
zapewnioną. Podaj stack trace (exc.printStackTrace()) otrzymanego wyjątku i
fragment kodu którego dotyczy, to coś się poradzi.
Bogdan (bogdro)
[...]
>>> OknoPliku dialog = new OknoPliku(mainFrame);
>>> dialog.setModal(true);
>>> dialog.show();
>> No, wydaje się to fajna rzecz, ale:
>> 1. okienko przecież można zamknąć bez podawania informacji, którą
>> potrzebuję (krzyżykiem). Czyli znów muszę sprawdzać w pętli, czy
>> nazwaPliku != null ?
>> 2. moja (najnowsza) Java nie rozpoznaje tej funkcji.
>> (3. ponoć należy używać setVisible(bool), ale to nieistotny szczegół )
>> [...]
>
> Ktorej metody setModal ??? nie moze byc :> a z setVisible to racja, show
> jest deprecated.
No mam teraz taką funkcję:
public void actionPerformed ( ActionEvent e ) {
String nazwa = e.getActionCommand();
if ( nazwa.equals ( "Zamknij" ) ) {
dispose();
System.exit(0);
} else
if ( nazwa.equals ( "Otworz..." ) ) {
nazwaPliku = null;
OknoPliku op = new OknoPliku();
op.setModal(true); // linia 301
op.setVisible(true);
op = null; // to sie skasuje
try {
otworz_plik ( nazwaPliku );
} catch ( IOException ex ) {
System.out.println ( "Wyjatek ");
ex.printStackTrace();
OknoBlad ob = new OknoBlad ("Wyjatek");
while (true);
};
}
};
i javac wyrzuca:
Wykresy.java:301: cannot find symbol
symbol : method setModal(boolean)
location: class OknoPliku
op.setModal(true);
^
1 error
>> [zamykanie programu:]
>>
>>> Chodzi o to ze tak dlugo jak masz aktywne watki, aplikacja sie nie
>>> zakonczy, a poki masz przynajmniej jedno okno to masz watek kolejki
>>> komunikatow, po usunieciu ostatniego okna (przez dispose), watek
>>> kolejki AWT i tak sie zakonczy wiec sam sie zamknie, System.exit to
>>> nadmiar szczescia pozatym jest nieelegancki.
>>
>>
>>
>> Czyli jak prawidłowo zamknąć program, ale np. nie z okna głównego, a
>> z okienka wyświetlającego jakiś błąd?
>
> Po zamknieciu wszyskich okien aplikacja sama sie zamknie... wiec jezeli
> to okienko z bledem bylo jedynym twoim okienkiem (a tak mi sie z kodu
> cos wydaje), to apikacja sama sie zamknie.
Nie musi być. Mogę już mieć otwarte okno klasy Wykresy i próbować
otworzyć kolejny plik (podając złą nazwę). Nie wymuszam zamykania okien
klasy Wykresy. W chwili błędu przy przetwarzaniu danych do piątego okna
mogę mieć 4 już otwarte. Co wtedy? Wyszukać wszystkie okna i na każdym
wywołać dispose()?
Człowiek z uchwytem od wiadra
> OknoPliku op = new OknoPliku();
> op.setModal(true); // linia 301
> op.setVisible(true);
A czy OknoPliku dziedziczy z Dialog? Może ciągle dziedziczysz z Frame?
> Nie musi być. Mogę już mieć otwarte okno klasy Wykresy i próbować
> otworzyć kolejny plik (podając złą nazwę). Nie wymuszam zamykania okien
> klasy Wykresy. W chwili błędu przy przetwarzaniu danych do piątego okna
> mogę mieć 4 już otwarte. Co wtedy? Wyszukać wszystkie okna i na każdym
> wywołać dispose()?
Moim zdaniem wtedy nie powinieneś zamykać całej aplikacji a jedynie nie
generować piątego wykresu.
Bogdan (bogdro)
>
>
>
>>>Nie :) lepsze by bylo:
>>>OknoPliku dialog = new OknoPliku(mainFrame);
>>>dialog.setModal(true);
>>>dialog.show();
>>>
>>>// tutaj program sie zatrzyma az do zakonczenia dzialania modala
>>>// przez hide lub dispose
>>><doc>
>>> If the dialog is modal and is not already visible, this call will not
>>>return until the dialog is hidden by calling hide or dispose. It is
>>>permissible to show modal dialogs from the event dispatching thread
>>>because the toolkit will ensure that another event pump runs while the
>>>one which invoked this method is blocked.
>>></doc>
>>
>>No, wydaje się to fajna rzecz, ale:
>>1. okienko przecież można zamknąć bez podawania informacji, którą
>>potrzebuję (krzyżykiem). Czyli znów muszę sprawdzać w pętli, czy
>>nazwaPliku != null ?
>
>
> "Otwórz" udostępniasz z poziomu menu. Jeżeli user nie poda informacji, to
> nic nie rób. Poczekaj aż użytkownik w końcu wybierze.
Albo jeśli zamknie krzyżykiem, nie będę robił nic (tak jak poradziłeś).
Istotnie, najważniejsza częśc mojego programu (rysowanie wykresu) już
jest zrobiona. Chciałem dorobić taki bajerek jak otwieranie kolejnych
plików już z programu, a tu takie przeszkody mi wyrastają. Z drugiej
strony poza tym, co jast napisane w kursie (czyli tworzenie okna i
dodawanie komponentów), wszystko wyszukałem/zgadłem sam, więc i tak nie
jest źle :)
>
>
>>2. moja (najnowsza) Java nie rozpoznaje tej funkcji.
>
>
> Której funkcji? Uwaga terminologiczna - metoda, nie funkcja.
Racja, zbyt dużo C :) Tymbardziej, że teraz też piszę coś w C. Nie
rozpoznaje setModal(boolean), tak jak napisałem w innym poście. A z tego
co zauważyłem: czyżby OknoPliku powinno extends Dialog?
>>>Efekt bedzie ten sam, wait rowniez zatrzyma ci kolejke watkow AWT, tutaj
>>>musisz zrobic modal'a
>>
>> I tak się nie udało, bo jakieś metody trzeba posynchronizować (ech,
>>muszę doczytać). Co prawda komponenty się pojawiły, ale nic nie
>>działało, tylko sypało wyjątkami.
>
>
> W twoim przypadku nie ma tam co synchronizować. Modal wstrzyma ci wątek
> głównego okna do czasu jego schowania, więc tutaj masz synchronizację
> zapewnioną. Podaj stack trace (exc.printStackTrace()) otrzymanego wyjątku i
> fragment kodu którego dotyczy, to coś się poradzi.
O synchronizacji mówiłem, gdyby nie było modala.
A sypie tym:
Exception in thread "AWT-EventQueue-0"
java.lang.IllegalMonitorStateException
at java.lang.Object.notifyAll(Native Method)
at OknoPliku.actionPerformed(Wykresy.java:376)
at java.awt.Button.processActionEvent(Button.java:388)
at java.awt.Button.processEvent(Button.java:356)
at java.awt.Component.dispatchEventImpl(Component.java:3955)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
...
co jest zgodne z teorią opisującą funkcję wait().
Człowiek z uchwytem od wiadra
> A z tego
> co zauważyłem: czyżby OknoPliku powinno extends Dialog?
Wręcz musi. Klasa Dialog posiada właśnie metodę setModal, tak więc z niej
musisz dziedziczyć. Poza tym api tej klasy jest niemal identyczne jak
Frame, więc powinieneś sobie poradzić.
> O synchronizacji mówiłem, gdyby nie było modala.
jednak modal to najlepsze wyjście. Użycie wait w wątku zdarzeń (tak jak
słusznie zauważył a1), jest złym rozwiązaniem.
Bogdan (bogdro)
>
>
>> OknoPliku op = new OknoPliku();
>> op.setModal(true); // linia 301
>> op.setVisible(true);
>
>
> A czy OknoPliku dziedziczy z Dialog? Może ciągle dziedziczysz z Frame?
Tak, właśnie się zakumałem. Ale teraz pluje się o konstruktory:
Wykresy.java:339: cannot find symbol
symbol : constructor Dialog()
location: class java.awt.Dialog
public OknoPliku (Frame f) {
^
i tak samo, gdy:
public OknoPliku () {
Oczywiście obojętnie, czy w konstruktorze dałem to Frame f, czy nie.
W konstruktorze musi się pojawić też jedno z: Frame, Dialog. Co więc mam
wpisać w uruchomieniu z metody main(), bo 'this' oczywiście nie działa.
I czy konstruktor powinien zawierać wszystko to, co miał poprzedni (do
Frame): ustalanie pozycji i rozmiaru okna, dodawanie komponentów i metod
obsługi zdarzeń?
>> Nie musi być. Mogę już mieć otwarte okno klasy Wykresy i próbować
>>otworzyć kolejny plik (podając złą nazwę). Nie wymuszam zamykania okien
>>klasy Wykresy. W chwili błędu przy przetwarzaniu danych do piątego okna
>>mogę mieć 4 już otwarte. Co wtedy? Wyszukać wszystkie okna i na każdym
>>wywołać dispose()?
>
>
> Moim zdaniem wtedy nie powinieneś zamykać całej aplikacji a jedynie nie
> generować piątego wykresu.
To był przykład. A może chcę krzyżykiem w jednym oknie móc zamknąć
wszystkie? Albo dorobić przycisk/pozycję w menu do zamykania wszystkich
okien?
Trudne pytania zadaję :). W razie potrzeby użyj "To jest zbyt
skomplikowane. Koniec dyskusji". :)
Człowiek z uchwytem od wiadra
> Oczywiście obojętnie, czy w konstruktorze dałem to Frame f, czy nie.
> W konstruktorze musi się pojawić też jedno z: Frame, Dialog. Co więc mam
> wpisać w uruchomieniu z metody main(), bo 'this' oczywiście nie działa.
Najpier utwórz swoje główne okno (to z menu), potem utwórz to do otwierania
pliku i podaj jako rodzica to główne okno. Przy czym oczywiście maina ci to
nie zatrzyma, ale to nie powinien być problem.
> I czy konstruktor powinien zawierać wszystko to, co miał poprzedni (do
> Frame): ustalanie pozycji i rozmiaru okna, dodawanie komponentów i metod
> obsługi zdarzeń?
Dialog to taki Frame który może być modalny i który nie ma swojego paska na
pasku zadań graficznego interfejsu użytkownika systemu operacyjnego. Tak
więc wszytko co byś zrobił dla Frame musisz zrobić dla Dialog.
> To był przykład. A może chcę krzyżykiem w jednym oknie móc zamknąć
> wszystkie? Albo dorobić przycisk/pozycję w menu do zamykania wszystkich
> okien?
> Trudne pytania zadaję :). W razie potrzeby użyj "To jest zbyt
> skomplikowane. Koniec dyskusji". :)
Trudne pytania zadajesz, to jest zbyt skomplikowane. Koniec dyskusji.
A tak na poważnie, jak chcesz bezwarunkowo zamknąć całą aplikację i nie
musisz przed jej zamknięciem nic więcej robić, to możesz użyć System.exit.
Zdarza sie jednak, że trzeba pozamykać jakieś połączenia do bazy, albo coś
komuś jeszcze wysłać, albo zapisać do pliku. A wtedy samo System.exit nie
będzie tym, o co ci chodzi.
Bogdan (bogdro)
>
>
>>Oczywiście obojętnie, czy w konstruktorze dałem to Frame f, czy nie.
>>W konstruktorze musi się pojawić też jedno z: Frame, Dialog. Co więc mam
>>wpisać w uruchomieniu z metody main(), bo 'this' oczywiście nie działa.
>
>
> Najpier utwórz swoje główne okno (to z menu), potem utwórz to do otwierania
> pliku i podaj jako rodzica to główne okno. Przy czym oczywiście maina ci to
> nie zatrzyma, ale to nie powinien być problem.
To trochę do bani, bo zamiarem było, że OknoPliku pojawia się przed
głównym. Ale stwierdziłem, że może to i lepiej będzie, gdy najpierw
pojawi się główne (bez rysunku), a potem prośba o plik. W każdym razie
warto spróbować. Choć muszę przyznać, że czuję lekki zawód. Miało być
tak pięknie, a tu się nagle okazało, że "muszę to, muszę tamto", bo
inaczej nie zadziała. Może kiedyś zrozumiem, czemu nie zadziała.
Ale dokonałem w końcu przeróbek i dalej jest problem z konstruktorem:
Wykresy.java:316: cannot find symbol
symbol : constructor Dialog()
location: class java.awt.Dialog
public OknoPliku (Frame f) {
^
Taki jaki mam jest chyba dopuszczalny, więc o co chodzi?
>>I czy konstruktor powinien zawierać wszystko to, co miał poprzedni (do
>>Frame): ustalanie pozycji i rozmiaru okna, dodawanie komponentów i metod
>>obsługi zdarzeń?
>
>
> Dialog to taki Frame który może być modalny i który nie ma swojego paska na
> pasku zadań graficznego interfejsu użytkownika systemu operacyjnego. Tak
> więc wszytko co byś zrobił dla Frame musisz zrobić dla Dialog.
OK.
>> To był przykład. A może chcę krzyżykiem w jednym oknie móc zamknąć
>>wszystkie? Albo dorobić przycisk/pozycję w menu do zamykania wszystkich
>>okien?
>> Trudne pytania zadaję :). W razie potrzeby użyj "To jest zbyt
>>skomplikowane. Koniec dyskusji". :)
>
>
> Trudne pytania zadajesz, to jest zbyt skomplikowane. Koniec dyskusji.
> A tak na poważnie, jak chcesz bezwarunkowo zamknąć całą aplikację i nie
> musisz przed jej zamknięciem nic więcej robić, to możesz użyć System.exit.
I o to chodziło.
> Zdarza sie jednak, że trzeba pozamykać jakieś połączenia do bazy, albo coś
> komuś jeszcze wysłać, albo zapisać do pliku. A wtedy samo System.exit nie
> będzie tym, o co ci chodzi.
No tyle to ja też wiem.
Człowiek z uchwytem od wiadra
> To trochę do bani, bo zamiarem było, że OknoPliku pojawia się przed
> głównym. Ale stwierdziłem, że może to i lepiej będzie, gdy najpierw
> pojawi się główne (bez rysunku), a potem prośba o plik. W każdym razie
> warto spróbować. Choć muszę przyznać, że czuję lekki zawód. Miało być
> tak pięknie, a tu się nagle okazało, że "muszę to, muszę tamto", bo
> inaczej nie zadziała. Może kiedyś zrozumiem, czemu nie zadziała.
Tak jest po prostu prościej. To co byś chciał zrobić, też by dało się
zrobić, ale było by trudniej. I tylko o to chodzi.
> Ale dokonałem w końcu przeróbek i dalej jest problem z konstruktorem:
>
> Wykresy.java:316: cannot find symbol
> symbol : constructor Dialog()
> location: class java.awt.Dialog
> public OknoPliku (Frame f) {
> ^
>
> Taki jaki mam jest chyba dopuszczalny, więc o co chodzi?
Nie w tym miejscu jest problem. Jeżeli nie wyspecyfikujesz jawnie
konstruktora nadklasy, wywoływany jest ten bezparametrowy, a Dialog nie ma
bezparametrowego:
public OknoPliku(Frame parent, Boolean modal)
{
super(parent, modal); //czy inny z nadklasy
Przy okazji, to ja bym jednak polecił książkę zamiast kursu. Spędzisz
więcej czasu na czytaniu, jednak dowiesz się wielu rzeczy, czasem mało
istotnych, które kształtuja obraz języka jako całości.
> No tyle to ja też wiem.
Po prostu na grupę trafiają ludzie o różnym poziomie świadomości. Więc nie
obrażaj się, jak będę ci pisał jakieś truizmy, bo po prostu nie wiem czy
dla ciebie jest to oczywiste, czy też może nie.
Bogdan (bogdro)
>
>
>
>> To trochę do bani, bo zamiarem było, że OknoPliku pojawia się przed
>>głównym. Ale stwierdziłem, że może to i lepiej będzie, gdy najpierw
>>pojawi się główne (bez rysunku), a potem prośba o plik. W każdym razie
>>warto spróbować. Choć muszę przyznać, że czuję lekki zawód. Miało być
>>tak pięknie, a tu się nagle okazało, że "muszę to, muszę tamto", bo
>>inaczej nie zadziała. Może kiedyś zrozumiem, czemu nie zadziała.
>
>
> Tak jest po prostu prościej. To co byś chciał zrobić, też by dało się
> zrobić, ale było by trudniej. I tylko o to chodzi.
OK, rozumiem. Już mi lepiej :) Tym bardziej że program już działa!
>> Ale dokonałem w końcu przeróbek i dalej jest problem z konstruktorem:
>>
>>Wykresy.java:316: cannot find symbol
>>symbol : constructor Dialog()
>>location: class java.awt.Dialog
>> public OknoPliku (Frame f) {
>> ^
>>
>>Taki jaki mam jest chyba dopuszczalny, więc o co chodzi?
>
>
> Nie w tym miejscu jest problem. Jeżeli nie wyspecyfikujesz jawnie
> konstruktora nadklasy, wywoływany jest ten bezparametrowy, a Dialog nie ma
> bezparametrowego:
>
> public OknoPliku(Frame parent, Boolean modal)
> {
> super(parent, modal); //czy inny z nadklasy
Aha. Nauczyłem się nowej rzeczy. Już to super gdzieś widziałem, ale
wtedy (tj. w oknie) jego działanie było wzrokowo równoważne z
setTitle(), więc przestałem stosować.
> Przy okazji, to ja bym jednak polecił książkę zamiast kursu. Spędzisz
> więcej czasu na czytaniu, jednak dowiesz się wielu rzeczy, czasem mało
> istotnych, które kształtuja obraz języka jako całości.
To prawda. I chyba rzeczywiście ostro zabiorę się za "Thinking in Java".
>>No tyle to ja też wiem.
>
>
> Po prostu na grupę trafiają ludzie o różnym poziomie świadomości. Więc nie
> obrażaj się, jak będę ci pisał jakieś truizmy, bo po prostu nie wiem czy
> dla ciebie jest to oczywiste, czy też może nie.
Fakt. Na szczęście mam już za sobą jakieś 5 lat gorszego lub lepszego
C, ponad 3 lata assemblera, dobre podstawy PHP, Fortrana i podstawy C++,
więc w zbieraniu i poprawianiu (nie tylko własnych) błędów już mam
trochę doświadczenia :)
Choć nie powiem, zdarzają się głupie wpadki.
A wcale się nie obraziłem. To stwierdzenie to miało być coś w stylu
"Spoko, wiem o tym.".
W każdym razie wielkie dzięki za całą pomoc i cierpliwość :)
a1
> To trochę do bani, bo zamiarem było, że OknoPliku pojawia się przed
> głównym.
No to zaden problem... przeciez nie musisz pokazywac tego okna.
Wystarczy ze utworzysz okno a potem podasz go jako ownera do dialogu i
pokazesz sam dialog. A okno glowne dopiero potem.
--
a1
Człowiek z uchwytem od wiadra
> No to zaden problem... przeciez nie musisz pokazywac tego okna.
> Wystarczy ze utworzysz okno a potem podasz go jako ownera do dialogu i
> pokazesz sam dialog. A okno glowne dopiero potem.
Ale jak tak zrobi to nie zatrzyma wątku z mainem, co wymusi na nim
pokazanie głównego okna z poziomu okna wyboru pliku. Trzeba jeszcze jakoś
zsynchronizować maina z tym okienkiem wyboru.
nigh
isShowing() ?
nigh
a1
> a1 wrote (tak! stara dobra wrotka!):
> Ale jak tak zrobi to nie zatrzyma wątku z mainem, co wymusi na nim
> pokazanie głównego okna z poziomu okna wyboru pliku. Trzeba jeszcze jakoś
> zsynchronizować maina z tym okienkiem wyboru.
Nie po co? modal zatrzyma watek main'a. Jak uruchamiasz modal z watku
dispatcher'a to blokowanie uzyskiwane jest przez uruchomienie w show
petli (!) komunikatow ktora dispatchuje eventy do dialoga, jak
uruchamiasz w innym watku masz normalnego waita, wiec watek maina bedzie
zatrzymany.
--
a1
a1
> A nie wystarczy sprawdzać okresowo w mainie czy okno wyboru pliku jest
> isShowing() ?
Ogolnie wszelkie okresowe sprawdzania sa zue i ewil, po to jest wait i
notify zeby z niego kozystac, ale tak jak napsialem nie jest to
potrzebne o ile okienko jest modalne.
--
a1
Człowiek z uchwytem od wiadra
> Nie po co? modal zatrzyma watek main'a. Jak uruchamiasz modal z watku
> dispatcher'a to blokowanie uzyskiwane jest przez uruchomienie w show
> petli (!) komunikatow ktora dispatchuje eventy do dialoga, jak
> uruchamiasz w innym watku masz normalnego waita, wiec watek maina bedzie
> zatrzymany.
Ok, to ja mam pytanie. Czy wątek ramki startowany jest w momencie odpalenia
metody setVisible/show czy w momencie utworzenia obiektu ramki? Bo to chyba
jest tu kluczowe.
a1
Hmm... znaczy nie bardzo wiem o co ci chodzi, ramka jako tak nie ma
swojego watku jest dispatcher eventow AWT (tworzony bodajrze po
pokazaniu pierwszego okna [ale pewny nie jestem]), ale za bardzo nie
wiem co to ma wspolnego tym modalem.
--
a1
Człowiek z uchwytem od wiadra
> Hmm... znaczy nie bardzo wiem o co ci chodzi, ramka jako tak nie ma
> swojego watku jest dispatcher eventow AWT (tworzony bodajrze po
> pokazaniu pierwszego okna [ale pewny nie jestem]), ale za bardzo nie
> wiem co to ma wspolnego tym modalem.
Widać pokręciłem coś z inną biblioteką GUI. Odpaliłem dwie ramki, jednego
dialoga i zablokował obie :> Widać się zgadza.
Lilith
> A w ogóle to zainteresu się Swingiem, bo AWT ma raczej skromne możliwości i
> nie jest właściwie rozwijane.
A jak juz sie zainteresujesz Swingiem, to zainteresuj sie tez SWT, chocby
dla porownania - mnie sie w tym ( + JFace) jakos wygodniej niz w Swingu
pisze. Mily tutorial (z uzywaniem Eclipse'a przy okazji) :
http://www.cs.umanitoba.ca/~eclipse/
--
Nieustannie demonicznie ;] pozdrawiam
Lilith
Piotr Kobzda
> Chodzi o to ze tak dlugo jak masz aktywne watki, aplikacja sie nie
Drobne uzupełnienie, przy wątki zabrakło _niedemoniczne_, sama aktywność
wątków w zakończeniu aplikacji nie zawsze przeszkadza.
pzdr.
piotr
Bogdan (bogdro)
> On Sat, 27 Aug 2005 13:17:39 +0200, Człowiek z uchwytem od wiadra wrote:
>
>
>>A w ogóle to zainteresu się Swingiem, bo AWT ma raczej skromne możliwości i
>>nie jest właściwie rozwijane.
>
>
> A jak juz sie zainteresujesz Swingiem, to zainteresuj sie tez SWT, chocby
> dla porownania - mnie sie w tym ( + JFace) jakos wygodniej niz w Swingu
> pisze. Mily tutorial (z uzywaniem Eclipse'a przy okazji) :
> http://www.cs.umanitoba.ca/~eclipse/
>
Na razie dodane do zakładek. Spojrzę jak znajdę czas. Dzięki.