previous next Title Contents

8. Mitä muita kehitysvälineitä

Monisteessa käsiteltiin Windows-ohjelmointia. Windows ei suinkaan ole ainut graafinen käyttöliittymä, eikä C-kieli ainut työkalu. Toisaalta aihetta Windows-C on raapaistu vain pinnalta. Lukija on kuitenkin toivottavasti saanut kuvan Windows-ohjelmoinnin pääperiaatteista ja käytetyistä termeistä.

Seuraavassa luomme pikaisen katsauksen muihin mahdollisin sovelluskehitysvälineisiin.

8.1 Koodigeneraattorit

Alunperin esimerkiksi .RC-tiedostotkin kirjoitettiin käsin. Nyt tuskin kukaan haluaa suunnitella dialogiaan mittailemalla yksiköitä näytöltä. Dialogi- ja menu -editorit auttavat näiden rutiiniluonteisten tehtävien hoitamista ja generoivat sitten tarvittavan koodin.

Aivan vastaavasti voidaan menetellä myös itse ohjelmakoodin kanssa. Koska jokaisessa Windows-ohjelmassa on pääohjelma ja ikkunafunktio, voidaan nämä generoida automaattisesti. Ohjelmoija suunnittelee dialogieditorin kaltaisella työkalulla pääikkunan ja sen menut sekä mahdollisesti dialogit. Sitten generaattori tekee koodin, jossa aina vakiona pysyvät osat on paikallaan ja merkitsee ohjelmoijalle ne kohdat, joihin ohjelmoijan on itse kirjoitettava koodia.

Tehtävän vaikein asia on ylläpito jatkossa. Jos ohjelmoija tekee muutoksia generaattorin tekemään koodiin, niin generaattorin voi olla vaikea saada visuaalista kuvaa enää takaisin.

Osittain generaattorin tehtävä voidaan korvata vakioisilla ohjelmapohjilla (kehitetään TABHAND.C -ajatusta eteenpäin), joihin seuraava työ aloitetaan. Koodigeneraattorit ovatkin ehkä aloittelijan tapa saada nopeasti toimiva graafinen C-ohjelma.

Koodigeneraattoreita: * Visual C++, Microsoft; C++

* Borland C++ 4.0 -

* ProtoGen, ProtoView Development Co.; C ja C++ (Borland), tuli esim Borland C++ 3.1-tuotevalikoiman mukana

* AppWizard Visual C++, Microsoft, C++ (Microsoft)

* UIM/X, Visual Edge Software Ltd, C ja C++, X-Window

8.2 Application FrameWorks

Toinen nykyisin varsin suosittu ja hyvältä näyttävä tapa on TABHAND.C:n ideaa noudattaen pistää kaikki vakiotavara pääohjelmaa myöten aliohjelmiksi. Usein tämä tehdään vielä C++ kielellä tekemällä kustakin erityyppisesti ikkunasta luokka. Samoin koko sovellus muodostaa yhden luokan, johon ikkunat liitetään. Kun luokkakirjastot kirjoitetaan riittävän kattaviksi, saadaan suurin osa ohjelmoinnin ikävistä asioista haudattua luokkien alle. Samoin päästään eroon nimikirjavuudesta ja siitä, että saman asian suorittamiseen on esimerkiksi Windowsissa eri nimisiä kutsuja riippuen siitä mitä tehdään.

AFW muuttaa jossain määrin ohjelmointiajattelun päälaelleen
Eli tavoitteena on se, että ohjelmoija kirjoittaa tasan ne funktiot, jotka käsittelevät hänen ohjelmalleen tyypillisiä erikoistapauksia (lähinnä viestejä).

Application FrameWork-luokkakirjastoja: Object Windows Library 1.0, OWL 1.0, Borland (vain BC++ 3.0 ja 3.1 versiot)

Object Windows Library 2.5, OWL 2.5 Borland (BC++ 4.5 -)

Microsoft Foundation Class Library, MFC, Microsoft

wxWindows, Julian Smart, PD, Windows, OpenLook (XView), Motif , Mac tulossa (ANSI C++)

XVT, XVT Software Inc, Windows, Mac, OS/2, OSF/Motif, OPEN LOOK

CommonView, Glockenspiel, Windows, OS/2, OSF/Motif (ANSI C++)

Kirjastojen huonona puolena on yhden ylimääräisen kerroksen tuleminen ohjelman ja laitetason välille. Näin ohjelmista tulee hitaita, usein nimenomaan näytönkäsittelyssä. Esimerkkinä Quattro Pro for Windows, joka todennäköisesti on tehty OWL:n päälle ja Excel 4.0, joka ehkä on ohjelmoitu suoraan API-käskyjä käyttäen. Quattro on iso ja kömpelö Exceliin verrattuna vaikka onkin loistava ohjelma riittävän nopeassa koneessa (486/50MHz, 16 MB muistia, grafiikkakiihdytin).

8.3 VisualBasic

VisualBasic on tavallaan koodigeneraattori, mutta se ansaitsee aivan oman lukunsa. Ohjelmoija suunnittelee käyttöliittymän dialogieditorien tapaan ja vaikkapa suunnittelun aikana napauttaa dialogissa olevaa nappulaa ja lisää sen koodin, joka suoritetaan nappulaa painettaessa.

Koska VisualBasic osaa käyttää DLL-kirjastoja, voidaan siinä hyödyntää kaikki API-kutsut sekä muilla kielillä tehdyt DLL-toiminnot. Lisäksi kielen oma kokoelma funktiota on varsin mahtava. Olihan Basic nimenomaan Bill Gates ensimmäinen tuote. Enää ei siis voida sanoa, että tämä Basic olisi jollakin tavoin rajoittunut. Toivottavasti tämä on se suunta mihin ohjelmointi on menossa. Kaiken muun hyvän lisäksi koodi voidaan tallettaa ASCII-muodossa, jolloin fakkiutunut koodinvääntäjä pääsee käyttämään mieleistään ohjelmaa.

Esimerkkinä todettakoon, että autolaskurin versio, jossa on liikkuvat autojen kuvat, tiedoston luku ja kirjoitus, DDE-linkki, leikekirjan käyttö ja vieläpä OLE-linkki syntyi 6 tunnissa ilman manuaalin (tietysti Help-tiedostoa tutkailtiin) apua. Tosin osa C-ohjelman koodista voitiin kirjoittaa lähes suorana 1:1 käännöksenä VisualBasicin kielelle. Ongelma tuli kun piti tehdä GetPrivateProfileString, jota ei VisualBasicistä kirveelläkään löytynyt. Tällöin manuaalia tarvittiin Kernelin DLL-kutsujen tekemiseen.

Tällaisten kehittimien ehkä vakavin ongelma tulee olemaan globaali dokumentointi; kuhunkin nappulaan ja List-boxiin kirjoitetaan koodia sinne tänne, eli kukaan ei ehkä lopulta tiedä mikä mihinkäkin kuuluu.

Mutta pienissä sovelluksissa tällaiset kehittimet tulevat olemaan lyömättömiä. Linkkien ansiostahan graafisessakin ohjelmoinnissa ollaan menossa Unixin tyyliseen suuntaan. Joukko (ja iso) pieniä ohjelmia hoitelee kukin oman hommansa. Näitä pieniä ohjelmia sitten kutsutaan muista ohjelmista tarpeen mukaan.

Microsoft on luvannut laittaa VisualBasic-kielensä kaikkiin tuotteisiinsa (=VBA, Visual Basic for Application), joten ehkä vihdoinkin tulisi kaikki ohjelmat kattavat makrokieli. Tämä ei tietenkään ilahduta muita ohjelmataloja. Nyt VisualBasic on jo mukana Excel 5.0:ssa sekä Access-kortisto-ohjelmassa ja osittainen kieli on MS-Wordissä.

Koska VisualBasic ohjelma voidaan kääntää valmiiksi EXE-koodiksi, ei sitä voida enää edes syyttää hitaudesta. Lisäksi uusissa versioissa on mukana tietokannanhallinta kutsuja, jotka osaavat lukea useimpia tunnetuista tietokantatyypeistä ja ilman muuta osaavat SQL:ää.

8.4 Borland Delphi

Borlandin Delphi on Visual Basicia vastaava kehitin. Suurimpana erona on se, että ohjelmointikielenä on Pascal. Jostakin syystä tätä ei haluta julkisesti sanoa, eli tuotteen nimi olisi aivan hyvin voinut olla Visual Turbo Pascal. Tuote haluttiin kuitenkin lanseerata nimenomaan uutena kehittimenä. Vahvuutena on oikea oliopohjainen Pascal-laajennus ja erittäin hyvät tietokantayhteydet. Jopa niin hyvät, että perinteisten tietokantaohjelmien asema tulee kyseenalaiseksi. Tuotteen menestymisen ainoana esteenä saattaa olla Borlandin koko yrityksenä, eli sillä ei ole Microsoftin painoarvoa. Lisäksi Visul Basic ehti saada muutaman vuoden etumatkan, joka olisi pystyttävä kuromaan kiinni käyttäjämäärissä. Tuote kyllä pärjää Visual Basicille.

8.5 Taulukkolaskenta

Monisteen kirjoittajan mielestä taulukkolaskenta on tekstinkäsittelyn jälkeen tärkein tavallisen ihmisen tarvitsemista ohjelmista. Miksikö? Siksi että useat arkipäivän asiat on totuttu laittamaan taulukkomuotoon. Koska taulukkolaskimissa on yleensä mukana enempi tai vähempi hyvä makrokieli, voidaan tavallisimmat toiminnot automatisoida pikanappuloihin tai menuihin. Parhaimmillaan voidaan taulukkolaskenta hävittää näkyvistä kokonaan ja käyttäjä luulee käyttävänsä valmista sovellusta (tosin monesti hitaanlaista).

Toistaiseksi sekä Excel 4.0 (5.0:ssa on jo VBA) että Quattro Pro for Windows 6.0 käyttävät toisistaan poikkeavia DOS-ohjelmista periytyviä makrokieliä. Niissä on kuitenkin kummassakin lisänä varsin vaikuttavia ominaisuuksia joihin kannattaa tutustua ennen kuukausia kestävän C-koodauksen aloittamista. Ja ainahan on käytössä DDE-linkit (ja myös DLL).

8.6 Tietokannat

Paljon tietoa sisältävät sovellukset kannattaa ilman muuta tehdä jollakin tietokantaohjelmalla. Pienemmät Accessin, Fox Pron, DBasen tai Paradox for Windowsin kaltaisilla tietokanta/kortisto-ohjelmilla ja suuremmat Ingressin tai Oraclen kaltaisilla kehittimillä. Tosin Delphin kaltaiset tuotteet vaikeuttavat tätäkin päätöstä.

Esimerkiksi Paradox for Windowsissa on C:tä muistuttava olio-ohjelmointikieli, jolla ohjelma suunnitellaan kuten VisualBasicillä ikään. Huonona puolena on kääntäjän puuttuminen ja se ettei kieli ole täsmälleen mikään tunnetuista kielistä.

8.7 Hypertekstit

Vähänkin opetusohjelmiin tai käyttöoppaisiin viittaavat sovellukset kannattaa ehkä tehdä hypertekstiohjelmilla. Eräs alunperin tunnetuimpia oli Macin HyperCard. Nyt markkinoilla on useita. "Alkeellinen" hypersovellus voidaan tehdä suoraan Windowsin Helpiä käyttäen.

Myös tavallisen tekstinkäsittelyohjelman ohjelmoitavuus on nykyisin sitä luokkaa, että sen ympärille voidaan tehdä näyttäviä sovelluksia ja automatisoida rutiineja.

8.8 Visuaalinen ohjelmointi

Perinteiselle koodinvääntämisellä vastakkainen tapa tehdä ohjelmia on visuaalinen vuokuvauksiin perustuva ohjelmointi. Esimerkkinä Macin ProGraph. Jälleen ongelmaksi saattaa muodostua dokumentointi, sillä sata sivua ohjelman kuvia ei ole hyvä dokumentti, eikä siihen erityisesti voida kohdistaa mitään hakuja.

8.9 Lopuksi

On olemassa myös tulkkeja, jotka osaavat ajaa Windows ohjelmia X-Windows työasemissa. Joskus näytön käsittely saattaa jopa olla nopeampaa kuin aidossa DOS-koneessa.

Ohjelmoijan työkalun valinta tulee siis olemaan vaikeaa. C-kieli tulee kuitenkin todennäköisesti siirtymään assemblerin osaan: harvojen ja valittujen tehokas työkalu, joka auttaa ymmärtämään taustalla olevia toimintoja. Arkikoodaaja käyttänee AFW-kirjastoja ja C++:aa tai VisualBasicin tai Delphin tapaisia kieliä. Erikoistuneemmat ohjelmoijat käyttänevät jotakin tiettyä sovellusohjelmaa (tai kehitintä) ja sen makrokieltä.

Lisäksi ei ole sanottua, etteikö joku toinen kieli tule ja lyö itseään läpi graafisten liittymien ohjelmoinnissa. On olemassa lupaavia kieliä, joissa yhdistetään olio-kielten (esim. SmallTalk), listakielten (esim. Lisp) ja Prolog-tyylisten kielen ominaisuudet. Koska kuitenkin standardien muodostuminen kestää kauan, on ADA ehkä lähin mahdollinen taustalla odottavista "oikeista" kielistä. Tällä hetkellä löisin kuitenkin rahani C++:n puolesta yleisesti ja VisualBasicin tai Delphin puolesta Windows-ohjelmoinnissa. C++:an puolesta puhuu se, että siihen on "suhteellisen helppo" siirtyä C-kielen jäljiltä (eikä Pascal tai Fortran -pohjakaan ole haitaksi) ja lisäksi tämän hetken koodista valtaosa on C-kielelle. Markkinoilla ratkaisee monesti tarjonta eikä se mikä on parasta. VisualBasin puolesta puhuu sen monikäyttöisyys ja oppimisen helppous. Nykyisistä versioista (3.0) kuitenkin puuttuu itse tehtävät oliot (onko tämä sitten + vai -?) jotka taas on Delphissä.

previous next Title Contents