wtorek, 9 czerwca 2009

RadControls do dzieła! (czyli: opis zmian aplikacji i dalsze wrażenia z wykorzystania RadControls for WinForms)

Promuj

W poprzednich częściach opisana została aplikacja, która zostanie poddana przemianie i pierwsze wrażenia z pakietu RadControls for WinForms, ta część artykułu przedstawia konkretne elementy, jakie zostały wykonane, aby interfejsu użytkownika, aplikacji CAS OPC UA Address Space Model Designer, został "odmłodzony".

Układ głównego okna

W ramach zmian postanowiłem do interfejsu aplikacji dodać na górze wstążkę (Ribbon), jest to ostatnio coraz bardzie popularny element. W środku menedżer dokowania (DockManager), dzięki czemu interfejs użytkownika będzie można oprzeć o pływająco-dokowalne panele. A na dole pasek statusu. Elementy te tworzą następujący schemat okna:

W tym miejscu chciałbym dodać jeszcze pewną uwagę, mianowicie elementy muszą występować w powyższej kolejności, gdyż w innym przypadku elementy zaczynają na siebie zachodzić (nie wiem na ile to możliwe, ale przydatne byłoby przynajmniej ostrzeżenie użytkownika o tym, że stworzony układ jest niewłaściwy).

Początek przygód ze wstążką

Na samym początku dodana została wstążka, co w efekcie dało widok zaprezentowany na rysunku poniżej.

Przyznam, że mnie trochę ten widok zaskoczył. Jaki jest cel posiadania wstążki z przyciskami typu: minimalizuj, maksymalizuj, zamknij, skoro nad nią znajduje się klasyczna etykieta okna?

Rozwiązania dla tego problemu próbowałem znaleźć klasycznymi metodami: wyłączenie ramki okna (FormBorderStyle na None), czy wyłączenie paska górnego (ControlBox na false i pusta etykieta), jednak każde z rozwiązań okazywało się ułomne, jak choćby widoczna ramka dookoła okna na rysunku poniżej.

Ostatecznie wsparłem się jednym z przykładów (czytnika RSS) i użyłem kontrolki ShapedForm z zestawu dostarczanego przez firmę Telerik. Dodatkowo musiałem jeszcze skonfigurować odpowiednio okno, na szczęście odpowiednie wskazówki znalazłem w jednym z przykładów dołączonych do pakietu. Czynności te ostatecznie rozwiązały mój problem, jednocześnie uzasadniając sens wprowadzenia kolejnej kontrolki typu Form. Pojawia się tutaj jednak taka moja refleksja, czy nie lepiej byłoby, gdyby umieszczenie na Form’ie kontrolki Ribbon automatycznie wykonywało wszelkie niezbędne ustawienia?

Teraz na warsztat Dock Manager

W kolejnym kroku zająłem się projektowaniem układu okien z wykorzystaniem możliwości jakie dostarcza mechanizm dokowania, przesuwania, czy ukrywania okien. W przypadku narzędzi wchodzących do zestawu Telerik RadControls for WinForms funkcjonalność taką oferuje DockManager. Korzystanie z DockManager’a wydaje się dość proste sprowadza się do dodania menedżera do okna aplikacji, a następnie umieszczenie w nim paneli.

Tutaj muszę wspomnieć, że paneli (czy dokowanych okien) próżno szukać wśród zestawu kontrolek w przyborniku Toobox. Odpowiednie panele znajdują się tylko w menu kontekstowym menedżera dokowania. Dodawanie paneli przypomina więc pracę trochę pracę z ToolStrip’ami występującymi w klasycznych WinForms’ach, niemniej jednak nie uważam tego za zbyt intuicyjne rozwiązanie i przyznam że pierwotnie szukałem paneli w przyborniku.

Panele można dokować w zasadzie w dowolny sposób, chociaż przyznam, że odbywa się to trochę inaczej niż znany nam sposób z Visual Studio. Poza tym słabo podobają mi się zaproponowane przyciski do zamykania paneli, przypinania, czy wywoływania menu, osobiście wolę te, które widzę codziennie w Visual Studio.

Pewną trudność sprawia jeszcze edycja paneli, które zostały skonfigurowane jako ukryte. Ja za każdym razem ustawiałem panel jako widoczny, edytowałem go, a następnie musiałem pamiętać, by go znów ukryć. W tym przypadku cieszyłby chyba jakiś automat usprawniający edycję.

Wypełnianie wstążki

Praca z przygotowaniem interfejsu opartego o wstążkę (Ribbon) przebiega dość sprawnie. Podobnie jak w przypadku klasycznego TollStrip’a i Dock Manager’a (wchodzącego w skład pakietu), elementy do wstążki dodaje się przy użyciu menu kontekstowego. Mamy do dyspozycji przyciski, przyciski graficzne, przełączniki, przyciski Repeat, pola zaznaczania (checkbox), przyciski typu radio, przełączniki, listy rozwijane, galerie itp… Czyli jest w czym wybierać, aczkolwiek czasami najwygodniej byłoby mieć możliwość dodawania w prostu własnych elementów i np. na jednej z zakładek wchodzących w skład wstążki umieścić zwykły panel z własnymi zaprojektowanymi wcześniej elementami. Poza tym zauważyłem również brak elementu RadDropDownButtonElement (który widziałem wcześniej w przykładach)?

Umieszczane na wstążce elementy automatycznie ustalają swoją pozycję, a osoba przygotowująca interfejs musi wybrać tylko tryb umieszczania: pionowy lub poziomy. Kiedy potrzeba wykorzystać układ, w którym np. dwa elementy leżące jeden pod drugim, trzeba umieścić obok jednego większego elementu należy wykorzystać wiele grup i w każdej ustawić odpowiednie pionowe lub poziome rozmieszczanie. Przykładem takiej sytuacji może być duży przycisk wklej (paste) i obok niego dwa leżące pod sobą przyciski wytnij (cut) i skopiuj (copy).

Chciałbym jeszcze wrócić do przycisku rozwijanego (RadDropDownButtonElement). Trochę zdziwił mnie jego brak na liście elementów, które można dodać (ja znalazłem go w jednym z przykładów, gdzie służył do zmiany wyglądu aplikacji). Przecież jest on bardzo użyteczny. Można przy pomocy niego zgrupować przyciski o podobnej funkcjonalności (np. różne typy filtrów, jak na rysunku) lub przygotować coś podobnego do klasycznego menu. Właśnie to drugie (może nie do końca "estetyczne" rozwiązanie) pozwoliło mi na szybkie przeniesienie skomplikowanego menu aplikacji na wstążkę. Musiałem, co prawda, napisać kilka linijek kodu kreującego odpowiednie elementy na podstawie klasycznego MenuStrip, ale i tak jest to szybsze niż kreowanie wszystkiego od początku. Trochę szkoda, że sam pakiet nie oferuje jakiegoś automatycznego rozwiązania wspomagającego przenoszenie klasycznego menu lub choćby możliwości umieszczenia klasycznego menu na jednej z kart wstążki, według mnie wspomogłoby to bardzo pierwsze kroki przy przenoszeniu interfejsu.

Istotnym elementem wstążki jest jeszcze jej przycisk "Start". Edycja zawartości menu, które pojawia się po jego naciśnięciu nie stanowi żadnego problemu i odbywa się dość intuicyjnie, aczkolwiek według mnie przydałaby się tutaj możliwość automatycznego stworzenia menu, na zasadzie dodania standardowych elementów typu: nowy, otwórz, zapisz itp… Dodatkowo przydałby się też jakiś zestaw standardowych ikon, które można wykorzystać. Pewne ikony są dostępne razem z przykładami, ale wydaje mi się, że cały pakiet mógłby zyskać, gdyby oferował gotową bibliotekę ikon, które można wykorzystać w przygotowywanych aplikacjach.

Wygląd aplikacji oparty o tematy

Ciekawą możliwością, jaką oferuje pakiet jest możliwość wykorzystania tzw. "tematów (themes)" do automatycznej zmiany wyglądu aplikacji, a dokładniej wykorzystywanej kolorystyki. Dzięki temu można w bardzo prosty sposób umożliwić użytkownikowi wybór najwygodniejszego dla niego wyglądu aplikacji, efekty widać na poniższym rysunku.

Jeżeli chodzi o obsługę tematów w aplikacji, dzieje się to dość prosto i sprowadza się (prawie) do wybrania nazwy interesującego nas tematu w obsłudze odpowiedniego zdarzenia (np. po naciśnięciu przycisku). Należy jednak pamiętać, aby do głównego okna aplikacji dodać odpowiedni temat z kontrolek udostępnianych przez pakiet. Brak wykonania tej prostej czynności skutkuje naprawdę dziwnym efektem wizualnym, o możliwości zaistnienia którego nie jesteśmy informowani (np. podczas kompilacji przygotowywanej przez nas aplikacji).

Deployment, czyli publikacja przygotowywanej aplikacji

Oczywiście istotnym krokiem jaki należy powziąć przy tworzeniu aplikacji, jest przygotowanie sposobu, w jaki aplikacja będzie udostępniona użytkownikowi końcowego. W moim przypadku "deployment" jest oparty o technologię click-once. Muszę przyznać, że w tym przypadku bez trudu znalazłem w dokumentacji artykuł, który opisał jakie biblioteki należy dodać, aby moja aplikacja działała, na komputerze innym niż developerskim. Rozwiązanie, przyznam że jest proste i skuteczne, aczkolwiek wydaje mi się że przydałaby się też możliwość instalacji jakiegoś pakietu typu "redistributables", który zainstalowałby wszystkie potrzebne komponenty.


Czytaj dalej...


Promuj

3 komentarze:

  1. Marek Kalinowski14 czerwca 2009 16:06

    Moje doświadczenia z RadControls są takie, że po pierwszych pozytywnych wrażeniach przychodzi rozczarowanie ich niedopracowaniem (wymienię choćby "wysypywanie się" designera VS2008 podczas pracy z kontrolkami, znikanie kontrolek z toolbara). Narzuc na wydajność aplikacji (zwłaszcza jej startu) jest również widoczny.
    Pozdrawiam.

    OdpowiedzUsuń
  2. A dlaczego ShapedForm a nie zamiana RadForm na RadRibbonForm? Wtedy ControlBox znika i pozostaje wyłącznie ten przypisany do wstążki.
    Pozdrawiam
    Tomasz

    OdpowiedzUsuń
  3. Moje doświadczenia z pakietem nie są na razie duże (o czym piszę w tym artykule) dlatego może na razie widzę dużo pozytywów. Być może przyjdzie później faza rozczarowania (jak u Marka Kalinowskiego), ale też nie zrzucałbym wszystkich problemów na niedopracowanie pakietu.

    Jeżeli chodzi o wysypywanie się designer’a, to przyznam, że podczas pracy z pakietem w zasadzie mi się nie zdarzyło. Poza jednym zdarzeniem, gdy Visual Studio napisał, że skończyła mu się dostępna pamięć i designer się nie uruchomił. Tutaj muszę przyznać, że ilość zajmowanej przez Visual Studio pamięci jest większa w przypadku pracy z kontrolkami z pakietu RadControls i wydaje mi się, że podczas dłuższej pracy przyrasta (chociaż przyznam, że jakichś dokładniejszych pomiarów nie robiłem i nie wiem czy tu gdzieś jest jakiś problem). Czy ktoś też zauważył rosnącą ilość pamięci zajmowaną przez VS? Wracając do wysypywania się "designer’a", to mi wielokrotnie zdarzyło się "wysypanie" podczas pracy ze standardowymi kontrolkami, a problem ten występuje częściej, gdy kontrolki w skomplikowany sposób zagnieżdżane są w sobie i jest dużo kontrolek zdefiniowanych przez użytkownika. Wydaje mi się więc, że designer "sam z siebie" się często wysypuje, więc czy pakiet RadControls powoduje częstsze wysypywanie? Nie wiem.. ale na pewno nie obarczał bym go całą winą.

    Jeżeli chodzi o znikanie kontrolek z ToolBox’a, to przyznam, że coś takiego zdarzyło mi się kilka razy ( ale chyba zawsze miałem uruchomione dwie instancje VS, być może więc jakiś problem z miejscem w którym są przechowywane ustawienia i źle działa, to gdy próbuje do tego miejsca zapisać więcej niż jedna aplikacja. (ktoś ma podobne wrażenia?)

    Przechodząc do wydajności aplikacji (a zwłaszcza jej startu)... przyznam, że podczas działania nie zauważyłem jakichś problemów z wydajnością, ale muszę przyznać, że uruchomienie aplikacji wykorzystującej te dodatkowe kontrolki jest znacząco dłuższe. Pytanie czy należy się temu dziwić? Według mnie nie bardzo. Po pierwsze dodajemy dodatkową funkcjonalność, którą należy dodatkowo zainicjować, a to trwa. Po drugie podczas startu muszą być wczytane dodatkowe biblioteki (assembly) w moim przypadku jest to 5 dodatkowych plików, a to musi trwać.

    W przypadku Ribbon i ShapedForm, przyznam że Tomasz zadał bardzo dobre pytanie, które mnie trochę zaskoczyło. Odpowiedź moja jest prosta, zrobiłem to tak jak znalazłem to w przykładach (przykład czytnika RSS i "Ribbon/resize”). Chyba powinienem był zajrzeć do dokumentacji, ale pokierowałem się przykładem, pytanie więc czemu autorzy przykładu użyli ShapedForm? Powtórzę trochę to co pisałem może w artykule, przykłady są mocną stroną pakietu, prezentują się naprawdę dobrze i ładnie, ale ich autorzy powinni położyć większy nacisk na ich aktualizację do najnowszych wersji kontrolek (by nie wykorzystywały klas "obsolete" jak RSS reader’rre) oraz by zawsze pokazywały optymalne rozwiązanie.

    Dziękuję za komentarze i zapraszam do dalszej dyskusji.

    Pozdrawiam!

    OdpowiedzUsuń

Posty powiązane / Related posts