2007.03_Edytor GUI - nowe spojrzenie_[CSharp].pdf - C# - Kapy97

Programowanie

Zbigniew Fryźlewicz

Rafał Gierusz

Radosław Iwaszyn

Edytor GUI – nowe spojrzenie

cy oprogramowania przykładają dużą wagę

do stworzenia przyjaznego i użyteczne-

go interfejsu użytkownika dla swoich aplikacji. Szeroka

konkurencja na rynku sprawiła, że klienci mogą wybie-

rać spośród wielu produktów posiadających podobną

funkcjonalność. Jeśli aplikacja, którą planują kupić bę-

dzie przez nich często wykorzystywana, to z całą pew-

nością zwrócą uwagę na sposób komunikacji użytkow-

nika z programem. A ten aspekt realizowany jest wła-

śnie przez graﬁ czny interfejs użytkownika. Nie sposób

więc pominąć tego bardzo istotnego fragmentu procesu

wytwarzania aplikacji jakim jest przygotowanie GUI. Ja-

sne jest także, że w dobie wysokiej specjalizacji trudno

oczekiwać od programisty, który zajmuje się przygoto-

waniem często bardzo złożonej logiki biznesowej, aby

był także doskonałym graﬁ kiem, czy też artystą plasty-

kiem. Rodzi to konieczność współpracy pomiędzy oso-

bami, które posiadają „duszę artysty” a programistami

i architektami oprogramowania. Z całą pewnością ideal-

na sytuacja ma miejsce wtedy, gdy graﬁ k tworzy inter-

fejs użytkownika a następnie dostarcza go – w jedno-

litej formie – programiście. Dla obu stron korzystne jest

również to, by praca graﬁ ka przebiegała w jednym, nie-

zmiennym środowisku. Z jednej strony programista mo-

że być pewien, że zawsze otrzyma interfejs w jednoli-

tej formie, z drugiej strony graﬁ k może pracować z do-

brze mu znanym uniwersalnym narzędziem i to bez ko-

nieczności ciągłego szkolenia się i poznawania nowych

środowisk i narzędzi. Takie właśnie narzędzie zbudo-

wali autorzy niniejszego artykułu. Aplikacja została na-

pisana w języku C# i w tymże języku są prezentowa-

ne wszystkie fragmenty kodu źródłowego. Celem arty-

kułu jest nie tyle prezentacja narzędzia, ile pokazanie

idei jaka przyświecała jego twórcom. Przedstawiony tu-

taj opis jest jedynie wprowadzeniem do dalszych badań

nad narzędziem oraz zastosowanych w nim rozwią-

zaniach. Pewne pomysły są jedynie zaprezentowane

Rysunek 1. Proste GUI

i mogą być w przyszłości rozwijane. Zanim jednak na-

piszemy więcej o zbudowanym narzędziu, przyjrzyjmy

się w telegraﬁ cznym skrócie kilku aplikacjom tego typu,

które istnieją na rynku oprogramowania.

Istniejące narzędzia

Na rynku istnieje kilka podobnych narzędzi. Wszyst-

kie jednak są dedykowane do konkretnych środowisk

deweloperskich. Przyjrzyjmy się krótko trzem najpo-

pularniejszym edytorom interfejsów graﬁ cznych. Są to

edytory dołączone standardowo do środowisk Visual

Studio [1], Borland C++ Builder [2] oraz NetBeans [3]

Wszystkie trzy umożliwiają swobodne tworzenie wła-

ściwie dowolnych interfejsów. Zasada tworzenie GUI

jest w każdym z nich taka sama. Aby dodać jakiś kom-

ponent należy go po prostu „przeciągnąć i upuścić” na

formę, ustawić jego właściwości a potem już przystą-

pić do programowania obsługi nowo dodanej kontrol-

ki. W tym celu należy wybrać obsługiwane zdarzenie,

dwukrotnie kliknąć jego nazwę, co spowoduje wygene-

rowanie nagłówka odpowiedniej metody etc. Wszyst-

kie wymienione edytory działają właśnie w taki sposób.

Wydawać by się mogło, że takie możliwości są wręcz

wymarzone podczas tworzenia aplikacji. Jednak nie

zawsze tak jest. Ten sposób pracy jest dobry tylko wte-

dy, gdy programista buduje zarówno interfejs jak i logi-

kę aplikacji. Trudno wyobrazić sobie sytuację, że oso-

ba, która zupełnie nie zna się na programowaniu ale za

to jest doskonałym graﬁ kiem będzie dla każdej aplika-

cji tworzyć jej interfejs w innym narzędziu i to w zależ-

ności od wybranego przez programistę środowiska im-

plementacji. Wiadomo też, że duża ilość opcji – niepo-

trzebnych z punktu widzenia graﬁ ka – jedynie zaciem-

nia i utrudniała jego pracę z programem. Niemniej istot-

na jest kolejna kwestia. Często zdarza się, że jesteśmy

w stanie opisać wygląd interfejsu graﬁ cznego zanim

jeszcze wybierzemy środowisko implementacji projek-

towanej aplikacji. A jeśli założyć, że GUI ma być budo-

wane w tym samym narzędziu w jakim powstaje logika

aplikacji, a z taką sytuacją mamy do czynienia w przy-

padku powyższych trzech środowisk, to do momen-

tu wyboru języka programowania nie mogą być roz-

Zbigniew Fryźlewicz jest adiunktem w Instytucie Infor-

matyki Stosowanej Politechniki Wrocławskiej. Zajmuje

się architekturą i technologiami serwisów webowych.

Kontakt z autorem: Zbigniew.Fryzlewicz@pwr.wroc.pl

Rafał Gierusz jest absolwentem Inżynierii Opro-

gramowania Politechniki Wrocławskiej. Specjalizuje się

w rozpoznawaniu i zastosowaniach nowych technologii

IT. Aktualnie współpracuje z ﬁ rmą Akond Lab.

Kontakt z autorem: Rafal.Gierusz@akond.com

Radosław Iwaszyn jest atudentem IV roku Inżynierii

Oprogramowania na Politechnice Wrocławskiej. Zajmu-

je się technologiami webowymi.

Kontakt z autorem: Radoslaw.Iwaszyn@gmail.com

www.sdjournal.org

Software Developer’s Journal 03/2007

W obecnych czasach nie dziwi nikogo, że twór-

Edytor GUI – nowe spojrzenie

Listing 1. Plik XML reprezentujący GUI z Rysunku 1

będzie budowana docelowa aplikacja. Jest to niewątpliwy atut

zaprojektowanego przez autorów edytora GUI.

< ?xml version= "1.0" encoding= "UTF-8" ? >

< gui >

< window >

< property name= "layout" > xy < /property >

< property name= "title" > Formularz < /property >

< property name= "size" > 792,716 < /property >

< textﬁeld >

< property name= "name" > tfNazwisko < /property >

< property name= "text" / >

< property name= "layoutProperty" > 331,156 < /property >

< property name= "size" > 101,27 < /property >

< property name= "font" > Verdana-12-Regular < /property >

< /textﬁeld >

< label >

< property name= "text" > Nazwisko: < /property >

< property name= "layoutProperty" > 199,156 < /property >

< property name= "size" > 112,26 < /property >

< property name= "font" > Verdana-14,25-Regular < /property >

< /label >

< textﬁeld >

......

< /textﬁeld >

< button >

< property name= "name" > btZapisz < /property >

< property name= "text" > Zapisz < /property >

< property name= "layoutProperty" > 263,209 < /property >

< property name= "size" > 90,28 < /property >

< property name= "font" > Verdana-14,25-Regular < /property >

< /button >

< label >

......

< /label >

< label >

......

< /label >

< /window >

< /gui >

Pliki XML przechowujące interfejsy

Rozpatrzmy jak wyglądają pliki XML, który przechowują infor-

macje o projektowanym interfejsie. Proste GUI (Rysunek 1)

jest opisane w pliku XML przedstawionym na Listingu 1.

Elementem-korzeniem każdego dokumentu XML jest

gui . Element gui może mieć dowolną liczbę elementów pod-

rzędnych window , z których każdy reprezentuje jedno z wielu

okien aplikacji. W środowiskach deweloperskich okno przekła-

da się na formę, czyli miejsce w którym są umieszczane kolej-

ne elementy interfejsu. Okno jest opisane przez kilka atrybu-

tów. Każdy z nich jest zapisany jako element podrzędny ele-

mentu window i ma format <property name=”właściwość”>wa

rtość</property>. Dokładniej, jest to jeden z dwóch możliwych

sposobów przechowywania takiej informacji. Sposób drugi, to

po prostu atrybuty elementu, czyli zapis w postaci: <element

właściwość=”wartość”>. Plik z opisem interfejsu może zawie-

rać dowolne kombinacje obu sposobów zapisu.

Powróćmy jednak do atrybutów, które opisują okno aplikacji.

Taki sam zestaw atrybutów będą posiadały wszystkie kontenery,

czyli elementy na których będzie można ułożyć inne elementy in-

terfejsu. Pierwszym z atrybutów jest layout , który określa sposób

ułożenia kontrolek w oknie. Dostępne wartości tego atrybutu to:

• xy – kontrolki mogą być układane w dowolny sposób na

formie,

• y – kontrolki układane są automatycznie obok siebie w ukła-

dzie wertykalnym; w przypadku, gdy kontrolka nie mieści się

w linii jest automatycznie przenoszona do kolejnej linii,

• x – kontrolki układane są automatycznie obok siebie w ukła-

dzie horyzontalnym; w przypadku, gdy kontrolka nie mieści

się w kolumnie jest automatycznie przenoszona do kolejnej

kolumny.

W interfejsie z Rysunku 1 skorzystano z pierwszej możliwości

układania kontrolek. Kolejnym atrybutem, który posiada okno apli-

kacji jest tytuł, opisany atrybutem o nazwie title. Jego wartość, to

dowolny ciąg znaków; w przykładzie Formularz. Bardzo ważnym

atrybutem jest rozmiar okna (size). Jego wartością jest para liczb

całkowitych, które określają odpowiednio długość oraz szerokość

kontrolki. Dla wszystkich kontenerów, za wyjątkiem okna aplika-

cji, atrybut może być pominięty co oznacza, że kontrolka zajmu-

je całą powierzchnię kontenera, w którym się znajduje. Przyjrzyj-

my się teraz atrybutom jakie posiadają kolejne elementy hierar-

chicznej struktury dokumenty XML, czyli w przypadku dokumen-

tu GUI Designera kontrolki. Łatwo zauważyć, że każda z nich po-

poczęte żadne prace. Sytuacja może się jeszcze pogorszyć jeśli

na jednym z początkowych etapów implementacji okaże się, że

trzeba jednak zmienić środowisko. O ile kod programu da się sto-

sunkowo łatwo przenieść do nowego środowiska, to przeniesie-

nie interfejsu graﬁ cznego jest już znacznie trudniejsze. Z tych też

powodów wymienione środowiska, przygotowane bardzo staran-

nie i z dbałością o wszelkie szczegóły, nie mogą być uważane

za w pełni uniwersalne. Są zasadniczo przeznaczone do jedne-

go rodzaju zadań, takich w których programista buduje zarówno

interfejs jak i logikę aplikacji. Inaczej jest ze zbudowanym przez

autorów edytorem GUI. Jest to narzędzie zapewniające nieza-

leżność i przenośność zbudowanego interfejsu. Obie cechy uzy-

skano zapisując tworzony interfejs w postaci pliku XML, którego

strukturę określa specjalnie zdeﬁ niowany plik schematu (w języ-

ku XML Schema [4]). W efekcie, posiadając te dwa pliki, można

odtworzyć wygląd zaprojektowanego GUI w dowolnym środowi-

sku i platformie programistycznej.

Co więcej, projektant interfejsu zawsze pracuje z tym sa-

mym narzędziem, i to niezależnie od środowiska, w którym

Listing 2. Właściwość Checked

public bool Checked {

get {

return (( CheckBox ) controlStored ) . Checked ;

}

set {

(( CheckBox ) controlStored ) . Checked = value ;

}

Software Developer’s Journal 03/2007

www.sdjournal.org

Programowanie

Listing 3. Metoda tworząca kontrolkę NewCheckBox

Listing 5. Funkcja InitializeComponent() po stworzeniu

aplikacji

private static void addNewCheckBox

( EventArgs e , Designer designer ) {

CheckBox cb = new CheckBox ();

designer . adjustLocation ( e , cb );

designer . addControlToShow ( cb );

string name = “ checkBox ” + cbCounter ++;

cb . Name = name ;

NewCheckBox ncb = new NewCheckBox ( cb , designer );

designer . addControlInstance ( name , ncb );

}

private void InitializeComponent () {

this . components = new System . ComponentModel . Container ();

this . AutoScaleMode =

System . Windows . Forms . AutoScaleMode . Font ;

this . Text = “ Form1 ” ;

}

nych potrzeb. Wszystko to odbywa się przy niewielkim wysiłku,

a co najważniejsze bez widocznych zmian aplikacji, czyli bez

zmiany sposobu obsługi aplikacji przez użytkownika. Nowe kon-

trolki to dla użytkownika kolejne pozycje na liście kontrolek do wy-

boru. Zatem z punktu widzenia użytkownika edytora dodany atry-

but jest po prostu jednym z wielu, które są dostępne. Nie jest ko-

nieczna nauka nowego sposobu obsługi czegokolwiek. Podob-

nie jest z nowo dodanymi kontrolkami. Również one nie wymaga-

ją widocznych zmian w aplikacji. Pojawią się na liście dostępnych

kontrolek, a ich dodawanie do GUI oraz korzystanie z ich atrybu-

tów będzie przebiegało dokładnie tak samo jak dla tych kontrolek,

które już są dostępne w aplikacji. W ten sposób zyskujemy olbrzy-

mią elastyczność. Aplikacja – edytor GUI – może być rozszerza-

na właściwie w nieskończoność. Aby to potwierdzić prześledźmy

kroki wymagane w celu dodania nowej kontrolki do edytora. Wy-

magane krok są opisane poniżej.

siada wcześniej opisany atrybut size. Dodatkowo każda z nich

posiada atrybut layoutProperty, który określa lokalizację kontrolki

względem kontenera nadrzędnego. W rozważanym przykładzie

pierwsza z etykiet (label) posiada atrybut layoutProperty o warto-

ści „199, 156”, co oznacza, że znajduje się ona w punkcie x=199,

y=156 względem lewego górnego rogu kontenera nadrzędne-

go (w tym przypadku jest to okno aplikacji). Dodatkowo, niektó-

re z kontrolek posiadają atrybut name, który przechowuje jej na-

zwę. Dzięki temu jest możliwy dostęp do kontrolek z poziomu pro-

gramu, w którym tworzone GUI ma zostać użyte. Jeśli nie chce-

my, aby właściwości kontrolki były modyﬁ kowane podczas pracy

programu po prostu nie nadajemy jej nazwy. W efekcie programi-

sta nie ma dostępu do jej atrybutów. Pozostałe atrybuty, które po-

siadają kontrolki zależą już od ich specyﬁ ki. W rozważanym przy-

kładzie powtarza się zestaw text, font, które opisują tekst wyświe-

tlany na kontrolce. Nie musi tak jednak być. Możliwa jest tu pełna

dowolność i każda kontrolka może mieć dowolny, własny zestaw

atrybutów. Edytor GUI nie wprowadza tutaj żadnych ograniczeń

i jest w stanie – bez żadnej ingerencji w kod – prawidłowo obsłu-

giwać dowolnie wybrane atrybuty. Jedyna konieczność, to do-

danie odpowiednich fragmentów kodu do klas odpowiedzialnych

za zapis i odczyt wybranych atrybutów. Pamiętać także należy o

tym, że reprezentowane atrybuty nie zawsze przekładają się bez-

pośrednio na atrybuty kontrolek w konkretnym języku programo-

wania. W używanym do implementacji edytora GUI języku C#

mamy do dyspozycji właściwości ( properties ), którym bezpośred-

nio przypisujemy wartości tak, jak do zmiennych. W innych języ-

kach np. w Javie należy skorzystać z metod ustawiających takie

właściwości, np. setFont() . Mogą istnieć języki programowanie,

w których ustawianie powyższych właściwości dla kontrolek od-

bywać się może w całkowicie inny, specyﬁ czny dla konkretne-

go języka, sposób. Przełożenie atrybutów kontrolek z edytora na

konkretny język nie musi więc być bezpośrednie, lecz z racji spo-

sobu przechowywania danych w postaci dokumentu XML jest za-

wsze możliwe. Zastosowanie XML pozwala na łatwe i szybkie

rozszerzanie edytora (czyli dodawanie kolejnych kontrolek, któ-

re będzie on obsługiwał oraz właściwości, które posiadać bę-

dą istniejące już kontrolki) oraz dostosowanie go do indywidual-

Rozszerzanie funkcjonalności

Wybieramy dowolną kontrolkę, którą chcemy dodać do programu

edytora. Dla celów demonstracyjnych wybrano CheckBox czyli

kontrolkę, która nie może zawierać innych (dodawanie np. konte-

nerów jest bardzo zbliżone, lecz nieco bardziej czasochłonne.

Pierwszą czynnością jaką musimy wykonać jest stworze-

nie klasy, która będzie przechowywać kontrolkę i udostępniać

jedynie taką jej funkcjonalność jakiej oczekujemy od kontolki.

Nową klasę nazwijmy NewCheckBox . Dodawana klasa musi

dziedziczyć po klasie bazowej dla wszystkich kontrolek, czy-

li OverlapableBase . Aby możliwy był zapis do plików XML ko-

nieczna jest też implementacja interfejsu IXMLWritable . Inter-

fejs ten zawiera jedynie jedną metodę, która zwraca węzeł

XML reprezentujący kontrolkę. Klasa bazowa natomiast do-

starcza podstawową funkcjonalność, wspólną dla wszystkich

kontrolek. Konstruktor nowej klasy powinien przyjmować dwa

parametry: oryginalną kontrolkę CheckBox oraz referencję do

bazowego okna aplikacji ( Designer ). Obie referencje muszą

być przekazane do konstruktora klasy bazowej, która odpo-

wiedzialna jest za kontrolę wspólnego zachowania kontrolek:

public NewCheckBox(CheckBox cb, Designer d): base(cb,d) { }

Ciało konstruktora jest puste. Jest tak, ponieważ na tym etapie

nie jest konieczna inicjalizacja jakichkolwiek zmiennych. Wszyst-

ko zapewnia konstruktor klasy bazowej. Kolejną czynność, to

zdeﬁ niowanie właściwości, które kontrolka ma udostępniać.

W rozważanym przypadku założymy, że będzie to jedynie usta-

wienie, czy pole ma być zaznaczone czy odznaczone. Oczywi-

Listing 4. Warunek tworzenia nowej kontrolki

switch ( whichControl ) {

case 1 : addNewButton ( e , designer ); break ;

case 10 : addNewCheckBox ( e , designer ); break ;

}

Rysunek 2. Wygląd nowej kontrolki (NewCheckBox) na formie

www.sdjournal.org

Software Developer’s Journal 03/2007

Programowanie

ście liczba właściwości, które można zdeﬁ niować jest dowolna.

Deﬁ nicja właściwości może wyglądać jak na Listingu 2.

Do wykonania pozostało nam jeszcze dodanie tworzenia

naszej klasy w fabryce kontrolek. Fabryka, o której mowa od-

powiedzialna jest za stworzenie kontrolki na podstawie otrzy-

manych danych, czyli rodzaju kontrolki i referencji do konte-

nera, na którym będzie się znajdować. Przygotowujemy więc

funkcję tworzącą kontrolkę – Listing 3.

Dodajemy także odpowiedni warunek wybierający kontro-

lkę do utworzenia (Listing 4). Teraz możemy już uruchomić

aplikację i zobaczyć, że nowo stworzony CheckBox prezentu-

je się tak, jak tego oczekiwaliśmy (Rysunek 2).

Widać więc, że rozszerzanie funkcjonalności aplikacji jest

czynnością bardzo prostą. Jedyną rzeczą, której nie opisa-

no w procesie dodawania CheckBox’a był jego zapis do XML.

Nie jest to jednak nic trudnego. Konieczna jest jedynie wiedza,

w jaki sposób kontrolka ma być reprezentowana. Najprościej

jest przyjąć taki sam sposób przechowywania dla wszystkich

kontrolek. Nie jest to jednak konieczność. W szczególnym

przypadku każda z kontrolek dostępnych w aplikacji może być

opisywana przez zestaw zupełnie różnych atrybutów.

Bibliograﬁ a

• Templeman J., Vitter D. „Visual Studio.NET: .NET Framework.

Czarna księga”, Helion 2003,

• Hollingworth J., Swart B., Cashman M., Gustavson P. „C++

Builder 6.0. Vademecum profesjonalisty”, Helion 2003,

• http://www.netbeans.org ,

• Skonnard A., Gudgin M. „ Essential XML. Quick Reference ”,

Addison-Wesley 2002,

• Gamma, Helm, Johnson, Vlissides. „ Design Patterns. Elements

of reusable object oriented software ”, Addison-Wesley 2003,

• Esposito, Dino. „ Applied XML Programming for Micro-

soft.NET ”, Microsoft Press 2003,

• Waldschmidt, Peter. „ Complete .NET XML ”, Manning Publica-

tions Co., 2002.

zyków. Poniżej przedstawimy zarys takiego rozwiązania. Istot-

ne jest również, że taki sposób przechowywania GUI jest al-

ternatywą dla plików XML, ponieważ umożliwienie zapisu ko-

du języka programowania jest prawie równoznaczne z umoż-

liwienie wczytywania plików napisanych w tymże języku. Nie

można jednak zapominać, że taki sposób zapamiętywania

GUI przeczy podstawowej zasadzie, jaka przyświecała pod-

czas tworzenia edytora w obecnym kształcie, to jest jego uni-

wersalności. Pliki XML mogą być odczytywane na każdej plat-

formie sprzętowej i w każdym języku programowania.

Przyjrzyjmy się teraz wspomnianej wcześniej koncepcji ge-

nerowania kodu języka programowania na podstawie stworzo-

nego w edytorze GUI. Do dalszych rozważań posłużymy się

językiem C# i środowiskiem Microsoft Visual.NET 2005. Gdy

w tymże środowisku tworzymy nową aplikację Windows zauwa-

żyć możemy, że Visual Studio tworzy plik .cs, w którym znajduje

się główna klasa tworzonej aplikacji oraz funkcja InitializeCompo-

nent(), której ciało rozrasta się wraz z dodawaniem kontrolek na

formę oraz zmianami ustawień dla poszczególnych komponen-

tów. To właśnie ta metoda jest kluczem do wygenerowania kodu

z poziomu narzędzia. Zaraz po stworzeniu nowej aplikacji wnę-

trze metody wygląda jak na Listingu 5. Po dodaniu jakiejś kontro-

lki (np. Button ) zmienia się ono tak jak na Listingu 6.

Widzimy więc, że pojawiła się tutaj inicjalizacja nowej kon-

trolki oraz co najważniejsze dodanie tejże kontrolki do główne-

go kontenera okna. Z powyższego kodu wywnioskować można,

że dodawanie kontrolki to nic innego jak jej przygotowanie w me-

todzie InitializeComponent() i dodanie do odpowiedniego konte-

nera. Kontenerem tym nie musi być główne okno aplikacji. Mo-

żemy przecież mieć do czynienia z przypadkiem, gdy w głów-

nym oknie znajduje się np. Panel, na którym umieszczono kolej-

ne kontrolki. Spostrzeżenie powyższe pozwala stwierdzić, że ge-

nerowanie kodu C# będzie bardzo podobne do zapisywania pli-

ków XML. Konieczna będzie również analiza całej hierarchii kon-

trolek, inicjalizacja ich właściwymi wartościami oraz dodanie do

odpowiednich kontenerów. Zatem idea zapisu tego typu plików

pozostaje bardzo bliska zapisowi ich do plików XML. Możliwe jest

również stworzenie kolejnego narzędzia, które przetwarzać bę-

dzie podane pliki XML generując na ich podstawie kod źródło-

wy programu. Taka aplikacja z pewnością ułatwi pracę programi-

stom, którzy otrzymawszy plik z interfejsem od graﬁ ka będą mo-

gli od razu przystąpić do tworzenia logiki aplikacji nie przejmując

się zupełnie koniecznością jakiegokolwiek przetwarzania otrzy-

Generowanie kodu

Ciekawym pomysłem na rozszerzenie funkcjonalności tego ty-

pu aplikacji jest stworzenie generatora kodu, który będąc czę-

ścią narzędzia (lub zewnętrzną aplikacją) będzie pozwalał na

szybkie i niezawodne tworzenie logiki aplikacji, które oparte

będą na przygotowanym wcześniej GUI. Zwolni to programi-

stów od konieczności pisania narzędzi niezbędnych do prze-

twarzania plików XML, które generowane są obecnie przez

aplikację. Należy jednak podkreślić, że nie jest możliwe stwo-

rzenie generatorów kodu dla wszystkich istniejących obecnie

języków programowania. Można pokusić się jedynie o doda-

nie takiej funkcjonalności dla najpopularniejszych obecnie ję-

Listing 6. Funkcja InitializeComponent() po dodaniu

przycisku na formie

private void InitializeComponent () {

this . button1 = new System . Windows . Forms . Button ();

this . SuspendLayout ();

// button1

this . button1 . Location = new System . Drawing . Point ( 198, 71 );

this . button1 . Name = "button1" ;

this . button1 . Size = new System . Drawing . Size ( 75, 23 );

this . button1 . TabIndex = 0 ;

this . button1 . Text = "button1" ;

this . button1 . UseVisualStyleBackColor = true ;

// Form1

this . AutoScaleDimensions =

new System . Drawing . SizeF ( 6F, 13F );

this . AutoScaleMode =

System . Windows . Forms . AutoScaleMode . Font ;

this . ClientSize = new System . Drawing . Size ( 292, 266 );

this . Controls . Add ( this . button1 );

this . Name = "Form1" ;

this . Text = "Form1" ;

this . ResumeLayout ( false );

}

www.sdjournal.org

Software Developer’s Journal 03/2007

Edytor GUI – nowe spojrzenie

manych plików. Z ich punktu widzenia praca wyglądała będzie

więc tak, jakby interfejs stworzony został w ich środowisku pro-

gramistycznym. Niewątpliwe czyni to pracę bardziej komfortową

oraz wydajniejszą.

cy i co najważniejsze łatwe w rozbudowie. Jak przekonaliśmy się

w artykule dodanie nowej kontrolki, czy nawet generowanie ko-

du konkretnego języka programowania przy użyciu stworzone-

go przez autorów narzędzia nie jest zadaniem skomplikowanym.

Możliwa jest również bardzo prosta rozbudowa aplikacji o kolejne

funkcjonalności.

To, co odróżnia stworzone przez autorów narzędzie od

innych podobnych aplikacji tego typu istniejących na rynku

jest jego pełna uniwersalność. Nie jest ono ukierunkowane

na konkretną platformę i wybrane środowisko implementa-

cyjne. Możliwe jest jego wykorzystywanie w sposób zupeł-

nie niezależny od sposobu implementacji. Dzięki temu na-

rzędzie takie przydatne może być wszystkim twórcom inter-

fejsu graﬁ cznego, którzy nie tworzą logiki programu, a chcą

korzystać z dobrze poznanego narzędzia bez konieczności

zapoznawania się ze szczegółami działania kolejnych śro-

dowisk deweloperskich.

Zakończenie

Główną ideą, która przyświecała autorom było stworzenie uni-

wersalnego narzędzia do tworzenia interfejsów graﬁ cznych.

Chodziło przede wszystkim o to, aby narzędzie które miało po-

wstać mogło być wykorzystane do tworzenia GUI, które nie bę-

dzie w żaden sposób zależne od środowiska implementacji. Jak

się okazało przechowywanie plików programu w formacie XML

daje takie właśnie możliwości. Sposób ten pozwala na wykorzy-

stanie stworzonych interfejsów nie tylko w różnych środowiskach

deweloperskich, ale i w różnych systemach operacyjnych oraz

na różnych platformach sprzętowych. Stworzone narzędzie, któ-

re implementuje tę ideę okazało się być przyjazne podczas pra-

2007.03_Edytor GUI - nowe spojrzenie_[CSharp].pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: