Autor Wątek: Pisanie własnego silnika (biblioteki) GUI  (Przeczytany 6001 razy)

Offline Xion

  • Redaktor
    • xion.log

# Styczeń 02, 2008, 12:14:25
Cytuj
Nie przesyła. Wywołuje operator () dla odpowiedniego delegata, a więc wywołuje po prostu jakąś funkcję. Jaką? To ustala się przez wywołanie
Kod:

control->connect( /*...*/ );
które ma za zadanie połączyć numer zdarzenia z delegatem na funkcję.
To trochę OT, ale w tej sytuacji przyjęło się podobną metodę nazywać 'bind', a nie 'connect' :)

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Esidar

  • Użytkownik

# Styczeń 02, 2008, 15:43:00
Nic. Mapa stworzy sobie pusty delegat. Potem zostanie wywołany operator (), ale skoro delegat jest pusty to zupełnie nic się nie stanie.

A jak definiujesz wartości ID komunikatów ? Jak zapewniasz, że jedne kontrolki mają swój zestaw ID komunikatów a inne kontrolki mają inny zestaw ID ?

Nie przesyła. Wywołuje operator () dla odpowiedniego delegata, a więc wywołuje po prostu jakąś funkcję.

A masz możliwość "nadpisania" funkcji ? Tzn. jeśli przedefiniowujesz jakiś event (np. OnMouseClick) to czy masz możliwość zablokowania wywoływania funkcji z klasy bazowej ?

I jeszcze jedno pytanie pomocnicze ;) Jak przekazujesz parametry do tych funkcji ?

Offline Złośliwiec

  • Użytkownik
    • Dark Cult

# Styczeń 02, 2008, 15:52:06
To trochę OT, ale w tej sytuacji przyjęło się podobną metodę nazywać 'bind', a nie 'connect' :)

W wxWidgets przyjęło się nazywać 'connect'. Ale przyznaję, że ta nazwa nie pasuje :).

Offline Shelim

  • Użytkownik
    • Homepage

# Styczeń 06, 2008, 14:28:41
Dziękuję za komentarze! Mam jeszcze jednen problem, tym razem natury algorytmicznej (tzn. implementacją się zajmę, ale nie mam pomysłu na algorytm ;) ):

Do tej pory miałem okno, które mogło zawierać nieograniczoną ilość okien potomnych. Okno można skalować "łapiąc" za którąś z krawędzi, lub róg. Skalowanie celem powiększenia można robić tylko tak długo, aż nie dotrzemy do krawędzi okna nadrzędnego (ekran liczy się jako okno Root :) ). Skalowanie celem pomniejszenia można robić tylko tak długo, aż trafimy na któreś z okien potomnych. Oczywiście wysyła to do odpowiedniej funkcji informację o tym, że okno zostało przeskalowane, dzięki temu użytkownik biblioteki może odpowiednio poprzesuwać i przeskalować okna potomne.

Widzicie błąd?

Ja też nie widziałem.

Do momentu jak wprowadziłem drugą kontrolkę - linię. Jeżeli linia przebiega od np. lewej krawędzi do prawej w ogóle nie będzie można pomniejszać wszerz okna nadrzędnego! - od razu natrafia ono na okno potomne - linię.

Myślałem żeby zastąpić mój algorytm automatycznym skalowaniem okien potomnych w przypadku skalowania okna nadrzędnego, ale to też nie jest dobry pomysł. Wszak użytkownik może nie życzyć sobie pomniejszania buttonów i kontrolek do rozmiaru 1 x 1, zwłaszcza że jest to proces destrukcyjny - powiększenie z powrotem nie przywróci wyjściowego położenia.

trzecim wyjściem jest możliwość ustalenia dla każdego okna flagi, z której wynika, czy user pozwala na skalowanie tego okna wraz ze skalowaniem okna nadrzędnego, czy też nie. Jeżeli tak, to okno będzie pomniejszane wtedy, kiedy okno nadrzędne "wjedzie" na jego teren. Oczywiście okno nadrzędne będzie posyłać informację do zdefiniowanej przez użytkownika funkcji o tym, że zostało przeskalowane, a użytkownik może już swobodnie połatać to, co się ma na nim wyświetlać.

Jakie są wasze opinie na ten temat? :)

Offline Kos

  • Użytkownik
    • kos.gd

# Styczeń 06, 2008, 15:33:50
Hm, nie wiem, może dać obiektom 'anchory', czyli 4 boole określające do których krawędzi okna są "podpięte"? W sensie, podczas rozciągania, każdy anchor (lewy, prawy, górny, dolny) mówi, czy musi być utrzymana stała odległość od danej krawędzi okna.

Jeśli np przy rozciąganiu okna za prawą krawędź dana kontrolka ma tylko lewy anchor, to stoi w miejscu i okno przestaje się zmniejszać, gdy dojdzie do jej prawej krawędzi (tak jak teraz).
Jeśli kontrolka ma tylko prawy anchor, to podczas rozciągania okna za prawą krawędź obiekt przesuwa się tak, że jest zachowana stała odległość od prawej krawędzi okna. Okno przestaje się zmniejszać gdy lewa krawędź obiektu dojedzie do lewej krawędzi okna.
Jeśli kontrolka ma obydwa anchory, to po prostu rozciąga się razem z oknem - pod to podchodziłaby ta wspomniana przez Ciebie linia :) Okno przestaje się rozciągać wtedy, gdy kontrolka osiąga minimalny rozmiar.

Analogicznie dla anchorów pionowych. Podpatrzyłem z Delphi, sprawdza się naprawdę wygodnie. :)

Offline vashpan

  • Użytkownik
    • Strona

# Styczeń 06, 2008, 19:43:43
A w moim GUI nie ma mozliwosci rozciagania okien i tyle :D Wielkosc jest ustawiona raz na zawsze i tyle. Wiedzialem ze z rozciaganiem beda problemy i sobie odpuscilem - ale to nie tylko z powodu lenistwa, uznalem raczej, ze rozciaganie okna w GUI przeznaczonym do gier nie ma zbyt wielkiego sensu...

Wyobrazmy sobie jakas strategie: jak czesto zdaza sie wam rozciagac tam okna ? Po co ?

Dlatego uznalem ze wymaga to zbyt wiele wysilku a efekt moze byc calkowicie nieprzydatny.

Co o tym sadzicie ?

Offline Kos

  • Użytkownik
    • kos.gd

# Styczeń 06, 2008, 19:49:59
Imo też raczej niepotrzebne, ale widzę że kolega chce zrobić taki dość konkretny engine i udodstępnić go dla potomnych pod opensource (jeśli dobrze doczytałem), więc rozciąganie się tu zdecydowanie przyda.

.

  • Gość
# Styczeń 07, 2008, 14:03:29
Wyobrazmy sobie jakas strategie: jak czesto zdaza sie wam rozciagac tam okna ? Po co ?
Dlatego uznalem ze wymaga to zbyt wiele wysilku a efekt moze byc calkowicie nieprzydatny.
Bardzo często. Jeśli chcę zobaczyć szczegóły, co widzi n-ta kamera w engine (rozciągam okienko), albo chcę zobaczyć co się dzieje ze sceną podczas zmiany parametrów w n-tym oknie.
Warunkiem przyjemnego korzystania ze skalowania okien jest warunek, że wszystko się w danym oknie skaluje wraz z nim (podokna, fonty itp.)

Myślałem żeby zastąpić mój algorytm automatycznym skalowaniem okien potomnych w przypadku skalowania okna nadrzędnego, ale to też nie jest dobry pomysł.
To jest dobry algorytm. Ja z takiego korzystam od potopu i wszystko się idealnie spisuje.
Ale będziesz musiał rozwiązać wiele trywialnych niuansów jak wtedy gdy korzystasz z jednego Fonta w 3 oknach i ten Font jest zależny od wielkości któregoś okna. Wtedy będziesz musiał dostosować kolejność skalowania.

Cytuj
Wszak użytkownik może nie życzyć sobie pomniejszania buttonów i kontrolek do rozmiaru 1 x 1, zwłaszcza że jest to proces destrukcyjny - powiększenie z powrotem nie przywróci wyjściowego położenia.
Ustalasz albo w pikselach albo w procentach względem ekranu, do jakich rozmiarów można zmniejszyć okno. I już.

Cytuj
trzecim wyjściem jest możliwość ustalenia dla każdego okna flagi, z której wynika, czy user pozwala na skalowanie tego okna wraz ze skalowaniem okna nadrzędnego, czy też nie.
To jest właściwość okna. Można zastosować.

Cytuj
Jeżeli tak, to okno będzie pomniejszane wtedy, kiedy okno nadrzędne "wjedzie" na jego teren.
Głupie.