| Autor |
Wiadomość |
wojac
~user
Dołączył: 19 Gru 2007
Posty: 1
|
|
Witam,
na początek chciałbym autora pochwalić za bardzo ciekawy i rzeczowy wątek.
Ale mam jedno pytanie, otóż piszesz, że "niestety standardowa kontrolka Table w SWT dziala koszmarnie wolno". Jak się objawia to jej wolne działanie i przy jakich danych i w jakich okolicznościach zaczyna ona wolno działać?
A przy okazji chciałem zapytać o jeszcze jedną rzecz, gdyż widzę, że bardzo dobrze się w SWT orientujesz. Mam kontrolkę Table i na niej zdarzenie widgetSelected. I w tym zdarzeniu przepisuje wartości z zaznaczonego rekordu do kontrolki Text. I wszystko fajnie działa, ale jak zaznaczę jakiś rekord programowo (poprzez setSelection()), to niestety to zdarzenie się już nie wywołuje. Czy można je jakoś wywołać? Jeśli tak to jak?
Z góry dziękuję za odpowiedź.
Pozdrawiam.
|
|
| Powrót do góry |
|
|
progs
#Moderator
Dołączył: 16 Cze 2005
Posty: 6000
Skąd: 3m
Pomógł: 358
|
|
---------- 11:47 19.12.2007 ----------
Co do pierwszego pytania, Table koszmarnie dziala z duza iloscia danych pobieranych w locie z bazy danych (szczegolnie jak jest bardzo duzo kolumn gdyz Table czyta zawsze wszystkie kolumny), dlatego uzywam KTable oraz wlasnego rozwiazania:)
Generalnie w SWT brakuje w standardzie tabel i list opartych na modelach o wysokiej wydajnosci bez keszowania wyswietlanych danych.
Problem czesciowo rozwiazuje flaga SWT.VIRTUAL ale i tak dane sa dalej keszowane.
Na szczescie sa alternatywne rozwiazania jak KTable 
Co do drugiego pytania to w SWT zadne programowe zaznaczania nie wywoluja zdarzen, taka jest zasada.
Mozna to ominac samemu wywolujac odpowiednie zdarzenia zamiast metody zaznaczajacej, elekt ten sam ale przetwarzany przez obsluge zdarzen.
Aby wywolac zadarzanie tworzysz nowy obiekt Event ustalasz musowo pole type, pole widget ,oraz inne parametry ktore sa zwiazane z tym zdarzeniem, nastepnie wysylasz zdarzenie przez Display.post(Event), zdarzenie zostanie obsluzone tak jakby przyszlo od systemu:)
pozdro.
---------- 06:59 09.01.2008 ----------
troche artow na temat SWT/JFace:
http://www.squidoo.com/swt
http://www.cs.umanitoba.ca/~eclipse/
http://www.apl.jhu.edu/~kalman/swt/SWT_TUTORIAL.ppt
http://www.zikal.com/
Co do bardziej przyjaznych dla czlowieka materialow ksiazkowych to w polsce jest straszna lipa, ostatnie ksiazki na ten temat (JFace,Eclipse, pluginy itd.) byly w 2004 r dlatego jedyne co pozostaje to nabyc orginalne nowe ksiazki lub w postaci ebooka;), po angielsku jest pare ksiazek wydanych w 2006 r. opisujacych Eclipse 3.x/JFace/SWT wiec w miare aktualne informacje.
Dla osbob nie znajacego dosc jezyka aby je czytac pozostaje czekac ale nie wiadomo jak dlugo na cos nowego, puki co w przygotowaniu w Helion'ie nie ma nic w tej kwestii. Moze inne wydawnictwa sie postraja?
---------- 07:23 21.01.2008 ----------
Ostatnia aktualizacja CAIRO lub/i GTK pokazala ze rysowanie w SWT pod linuxem wydajnoscia zbliza sie do windowsowego GDI+, wydajnosc wzrosla bardzo mocno, o ile przedtem predkosc rysowania byla tragiczna o tyle teraz przy prostych animajach wyciaga duzo FPS nawet kilkaset
Jednak nie jest to ostatnie slowo w tej kwestii, wypisywanie tekstu wciaz jest dosc powolne i wypisywanie duzej ilosci tekstow np. komponentach tabelarycznych wciaz sie przydusza ale mysle poprawa wydajnosci i w tej kwestii nastapi.
Nie testowalem doglebnie wydajnosci, odkrylem to przez przypadek wlaczajac stara testowa animacje i wyrzucajac z niej rysowanie mnustwa napisow pozostawaiajac same linie i tlo, moim oczom zamiast spodziewanej wartosci kilkudziesieciu FPS pokazalo sie niemal 500 .
Poprawa wydajnosci CAIRO i operacji na GC jest od dawna oczekiwana gdyz do tej pory porownaine wersji windowsowej i linuxowej nie dawalo optymistycznych rokowan:)
Jednak gdy rysujemy znacze ilosci tekstu implementacja windowsowa dziala duzo sprawniej niestety, jak sprawdze bardzije konkretnie rozne operacje wtedy bedzie mozna przedstawic wydajnosc liczbowo.
Puki co mozna powiedziec ze rysowanie duzej ilosci linii i tekstu w windows dziala kilkakrotnie szybciej niz pod linuxem.
Tylko czekac na dalsza porawe wydajnosci operacji graficznych:)
---------- 07:37 ----------
Wnoski sa puki co takie, tworzenie komponentow o dynamicznej zawartosci (animacji, komponentow tebelarycznych i innych) za pomoca buforowanej grafiki w SWT pod windows nie wymaga super sprzetu, doskonale rezultaty osiaga juz na starych kompach z prockami ok 1Gz, pod linuxem ponad dwukrotnie szybsza maszyna nie daje porownywalnych rezultatow, sprawdze jeszcze zachowanie na wersji WPF na XP i Vista.
Tworzac skomplikowane i wykozystujace duza ilosc operacji graficznych aplikacje desktop w SWT pod windows otrzymuje sie znakomite rezultaty, Swing aby dorownac musi dzialac na strategi buforow lub prz przekierowaniu renderowanie na OpenGL/DirectX aby zblizyc sie do takich osiagow i to nalepiej za pomoca kompontow ciezkich jak Canvas czyli defakto AWT.
Pod linuxem natomiast taka sztuczka bila na glowe SWT, na szczescie sie to zmienia i wykozystywanie komponentow AWT za pomoca EMBEDDED przestaje juz miec wymierne kozysci ale chyba jeszcze bedzie to dzialac szybciej (wersja z przekierowaniem OpenGL).
cdn...
---------- 09:33 30.01.2008 ----------
Dzis zajmiemy sie dziedziczeniem klas ktorych dziedziczenie jest zabronione standardowo:D
Brzmi dziwnie?, jak wiemy nie mozna np. dziedziczyc klasy Shell co moze niektorych wkurzac jak dotad pisali w Swing, jednak nie ma rzeczy niemozliwych;), proba dziedziczenia Shell konczy sie wyjatkiem ktory wali SWT o bledzie podklasy.
Jednak jak sie dobrze przyjrzymy to za taki stan rezczy odpowiada metoda checkSubclass odziedziczona z klasy Decorations a wiec aby umozliwic dziedzizenie po Shell wystarczy nadpisac ta metode w naszej klasie pozostawiajac pusta implementacje:), proste i skuteczne:)
Jedna uwaga, dziedziczac jakiekolwiek klasy w SWT i nadpisujac wazne metody nadklas trzeba pamietac zawsze o wywolaniu tej metody z nadklasy na samym poczatku aby miec pewnosc ze w dzialaniu komponentu nic sie nie zepsuje:)
Kozystajac z tej wiedzy mozemy odziedziczyc Shell dodajac:
- wlasne konstruktory przyjujace tutul okna podobbie jak jest w Swing
- dodamy sobie metode loop() ktora w elegencki sposob pozwoli nam na uruchamianie petli zdarzen wraz z pokazywanim okienka i jego pakowaniem jak ma ustawiony Layout:)
a oto nasza klasa:
| Java: | import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Shell;
public class Form extends Shell {
public Form () {
}
public Form (String title ) {
setText (title );
}
public Form (int style ) {
super (style );
}
public Form (int style, String title ) {
super (style );
setText (title );
}
public Form (Shell parent ) {
super (parent );
}
public Form (Shell parent, String title ) {
super (parent );
setText (title );
}
public Form (Shell parent, int style ) {
super (parent, style );
}
// tu nasza sztuczka z pusta metoda
@Override
protected void checkSubclass () {
}
public void loop (){
if(getLayout ()!= null) pack ();
open ();
final Display display = getDisplay ();
while (!isDisposed ()) {
if (!display. readAndDispatch()) {
display. sleep();
}
}
}
// test
public static void main (String[] args ){
Form f = new Form ("Testowe okno");
f. loop();
}
} |
To tyle, po klasie Form mozmy spokojnie dziedziczyc jak wskazane jest uzycie dziedziczenia zamiast kompozytu, jednak w wielu przypadkach kompozyt jest duzo lepszym rozwiazaniem, szczegolnie w SWT gdzie aby malowac po obiekcie nie trzeba go dziedziczyc gdyz zdarzenie "paint" jak kazde inne jest delegacyjne:)
Trzeba jednak uwazac dodajac wlasne metody i konstruktory do dziedziczonych klas, jezeli sa udokumentowane jako nie do dziedziczenia moze sie okazac ze dojda jakies metody lub konstruktory w przyszlosci a my je nieswiadomie nadpiszemy i program bedzie sie sypac.
Problem tem jednak dotyczy dziedziczenia jako takiego i nie ogranicza sie tylko do SWT, kazda klasa po ktorej dziedziczmy moze nam sprawic taki problem, dlatego tez osobiscie wole wzorzec kompozyt uzywac.
O ile w klasach zaprojektowanych do dziedziczenia aspekty bezpiecznego i poprawnego tworzenie podklas sa dobrze udokumentowane o tyle w SWT nie jako robimy to w "ciemno" lamiac "oficjalne" zalecenia, ale jak zrobimy to z glowa nie powinno byc z tym zadnych problemow:)
Mozna podobnie kombinowac z kazda klasa ktora nie jest przeznaczona do dziedzicznia ale generalnie nie polecam, bezpiecznej uzywac kompozytu a dziedziczyc klasy do tego przeznaczone a wiec Canvas i Composite, w przypadku okien jest to uzsadnione wygoda i prostota tworzenia i urychamiania aplikacji, nie tzreba sie martwic o petle zdarzen gdyz mamy ja jako eleghancka metode w klasie.
Jak widac w main uzycie klasy jest banalne i calkowicie zgodne z dzialniem klasy bazowej Shell.
pozdro.
---------- 07:48 13.02.2008 ----------
Witam:)
Pojawilo sie Eclipse 3.4M5 oraz SWT z takim samym numerem, nowosci w SWT:
http://www.eclipse.org/swt/R3_4/new_and_noteworthy.html#m5
pozdro.
---------- 08:32 18.03.2008 ----------
Eclipse 3.4M5 na Mandriva 2007 lubi wypadac bez zadnego komunikatu w roznych sytuacjach, w domu mam FC8 i ta wersja dziala bez tych problemow, przypuszczam ze wypada CAIRO, Azaureus jak sobie zaktualizowal SWT do najnowszej wersji tez wypada wiec z musu uzywam wersji "stable" 3.3.1.1
We wlasnych programach jeszcze nie stwierdzilem wypadania a uzywam SWT 3.4M5.
W domu mam aktualizowany system na bierzaca YUM'em, tu jest jakis glupi aktualizator i malo updat'ow sie pojawia na liscie, no nic zobaczymy jak to bedzie sie sprawowac w przyszlosci.
pozdro.
_________________
Programowac kazdy moze, tylko nie kazdy ma tyle cierpliwosci i zapalu zeby zajac sie tym na poważnie:) |
|
| Powrót do góry |
|
|
|
|
Nie możesz pisać nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz głosować w ankietach
|
MapaPowered by phpBB © 2001, 2005 phpBB Group
|
|
