Utvikling av et grafisk grensesnitt

Nøkkelmiddelet for brukerinteraksjon med programmet er det grafiske brukergrensesnittet (GUI). GUI-en til ethvert programvareprodukt er en av nøkkelfaktorene for populariteten.

Å lage et kompetent brukergrensesnitt er en møysommelig prosess som krever maksimal oppmerksomhet på detaljer. Det opprettede grensesnittet skal maksimere funksjonene til programmet, men samtidig ikke overbelaste brukeren med en overflod av menyer, knapper, bilder og tekst.

I praksis innebærer programmering av Windows-applikasjoner utstrakt bruk av ulike verktøy og veivisere. Derfor, gitt standardene til det valgte operativsystemet, vil verktøyet ha et grensesnitt med vindu. Dette skyldes først og fremst det faktum at vinduer er hovedelementene i det grafiske grensesnittet i operativsystemer (OS) i Windows-familien. De er rektangulære områder som har sine egne innstillinger, egenskaper og typer.

Den grafiske delen av opplæringsblokken inkluderer fire typer vinduer:

Hovedvindu - inneholder alle elementene i programnavigasjonen, samt tilleggsinformasjon som er nødvendig for å gjøre det enklere å jobbe med PS;

Inform- inkluderer alle kontroller for informasjonskomponenten til programvareverktøyet. De gir tillegg av tester, informasjon, nye brukere og administratorer, tillater manipulering av nyopprettede eller eksisterende data;

Windows for å jobbe med programvarefunksjoner - gi arbeid med de grunnleggende funksjonene til treningsblokken, for eksempel å bestå tester og studere forelesninger;

Visningsvinduer for informasjon og statistikk - tjener til å vise ulike typer informasjon, samt statistikk og grafer.

Hovedprogramvinduet vil inneholde følgende kontroller og informasjonsutdata:

Vindutittel, som inneholder navnet på programmet og formålet med vinduet;

Systemmenyknapper, som er ansvarlige for å endre størrelse, minimere og lukke programmet;

Området til vinduets tittel, som kun er en dekorasjonsfunksjon og er nødvendig for å matche den generelle designbeslutningen;

Velkomstområde;

Område for visning av ukedag, gjeldende dato og klokkeslett;

Brukerverktøylinje som inneholder knapper for tilgang til hovedfunksjonene til programmet;

Administrativt panel, inkluderer en knapp for å få tilgang til de administrative kontrollene til PS;

En statuslinje som viser informasjon om alle moduser i programmet.

Diagrammet over hovedvinduet til det grafiske grensesnittet (vindusvisning for en administrativ konto) er vist i figur 3.2

Figur 3.2 - Skjema for hovedvinduet til det grafiske grensesnittet: 1 - vindustittel; 2 - systemmenyknapper; 3 - vinduets tittelområde; 4 - statuslinje; 5 - velkomstområde; 6 - område for visning av ukedag, dato og klokkeslett; 7 - administrativt panel; 8 - brukerpanel; 9 - knapp for tilgang til treningsstadiet; 10 - knapp for tilgang til teststadiet; 11 - knapp for å vise statistikk og grafer; 12 - utgang; 13 - knapp for tilgang til den administrative delen av applikasjonen

Tatt i betraktning retningen til det utviklede programvareverktøyet, ble flere ikke-standard grafiske løsninger utviklet for å tiltrekke oppmerksomhet og mer interesse for applikasjonen. I tillegg lar det deg få en slags individualitet blant resten av utvalget av programmer med lignende emner og fokus.

En av slike løsninger kan kalles fargerik og skaper en unik design, grensesnittelementer som ikke har noen analoger i dette området. Vi snakker om animerte innlegg basert på flash-animasjon. Ved hjelp av dem realiseres utformingen av navnene på alle de viktigste funksjonelle vinduene, navigasjonselementene, grensesnittet til registrerings- og autorisasjonsskjemaet. De viktigste fordelene med denne utviklingen er: implementering av et hyggelig og vennlig grensesnitt; betydelig forenkling av bruken av programmet, både på bruker- og administrativt nivå.

En annen av hovedfordelene blant analoge programmer, både i programvare og i grafisk implementering, er organiseringen av å bestå tester på forespørsel. For å bestå denne typen tester, må brukeren samle SQL-spørringer fra separate, uavhengige elementer. Avhengig av typen forespørsel, som må utarbeides basert på betingelsene for den foreslåtte oppgaven, dannes en viss polygon for montering. Polygonet inneholder felt for erstatning av operatorer, som trekkes inn i dem med musen fra en egen blokk, og felt for å legge inn navn på tabeller, felt og betingelser.

Brukerstatistikk implementeres i form av grafer, som bygges avhengig av resultatene oppnådd av ham. For hver test bygges dets egen dynamikk. Diagrammer inneholder alle nødvendige etiketter, er implementert ved hjelp av TChart-komponenten, og har derfor mange kontroller som er innebygd i komponenten som standard og som et resultat implementeres i applikasjonen.

For en mer brukervennlig visualisering ble stilene til tabelloverskrifter erstattet, i stedet for de som er implementert i utviklingsmiljøet som standard.

Dermed gjorde de implementerte grafiske løsningene det mulig å oppnå resultatet som er forutsatt av selve ideen om GUI-design. Det opprettede grensesnittet maksimerer mulighetene til programmet, men overbelaster samtidig ikke brukeren med en overflod av menyer, knapper, bilder og tekst.

DOKUMENTETS STRUKTUR

4.1. Visuell programmeringsteknologi

4.1.2. Visual Studio hovedvindu

4.1.3. VS hovedmeny og verktøylinje

4.1.4. Visual Studio Panel Windows

4.1.5... Konfigurere VS-utviklingsmiljøinnstillinger

4.1.6. Testoppgaver

4.1.7. VS .NET Development Environment Lab

4.1. Visuell programmeringsteknologi
og grunnleggende konsepter

Sammenlignet med tidligere generasjoner av programmeringsspråk, språket programmering på høyt nivå– Visual Basic .Net (VB) har en rekke grunnleggende forskjeller. Det er et kraftig, profesjonelt programmeringssystem som lar deg raskt og effektivt lage applikasjoner for MS Windows . Siden systemet er « visuell», programmereren kan lage den synlige delen av MS Windows-applikasjonen , uten å skrive nesten en eneste kodelinje. Denne synlige delen er grunnlaget for brukergrensesnittet « programvareprosjekt - bruker », ved hjelp av hvilken brukeren samhandler med programvareprosjektet. Utviklingen av både programkoden til klasser og metoder for å løse oppgaven, og programgrensesnittet til applikasjonen utføres på prinsippene objektorientert tilnærming , implementert i Visual Studio .Net (VS) . Applikasjoner (prosjekter) kjøres under MS Windows ved hjelp av Integrert utviklingsmiljø (IDE).

For applikasjoner som er opprettet med IDE, er en karakteristisk egenskap at det til enhver tid finnes mange objekter på skjermen: skjemaer, vinduer, knapper, menyer, tekst og dialogbokser, rullefelt, etc. Brukeren har en viss (avhengig av algoritmen til problemet som skal løses) valgfrihet når det gjelder bruken av disse objektene. Han kan klikk ved å bruke museknappen, dra objektet, skriv inn data i vinduet osv. I de fleste tilfeller antas det ikke en forhåndsdefinert sekvens av handlinger. Typisk utvikleren programvare(Programvare), som oppretter et programvareprosjekt, bør ikke begrense handlingene til applikasjonsbrukeren. Han må utvikle programvare som reagerer adekvat på enhver brukerhandling, selv den gale (i et godt program skal det ikke være utilsiktede handlinger). Derfor, for hvert objekt på skjermen, er det en rekke mulige hendelser. Noen av dem er laget av brukeren: klikke eller dobbeltklikke på en museknapp, dra et objekt, trykke på en tastaturtast, skrive inn tekst i et vindu, etc. andre hendelser oppstår som et resultat av andre hendelser: for eksempel et vindu åpnes eller lukkes, en kontroll blir aktiv (tilgjengelig) eller mister aktivitet. Dessuten manifesterer hver hendelse seg i visse handlinger (svar, reaksjoner, oppførsel) i programvareprosjektet. Disse handlingene kan deles inn i to grupper.

Den første er en konsekvens av egenskapene til objektet. Disse egenskapene er satt av programvareutvikleren fra en viss standard liste over egenskaper satt av programmeringssystemet og/eller MS Windows selv. . Et eksempel på slike handlinger er å minimere vinduet etter å ha klikket på knappen Minimer. I slike tilfeller kan ikke programmereren endre oppførselen til et objekt. Imidlertid er det i mange tilfeller en viss mulighet for å variere responsen til et objekt på en hendelse (tekst, font, farge, størrelse, skjermplass osv.) ved å angi visse egenskaper.

Den andre gruppen av handlinger (respons) på hendelser bestemmes fullstendig av programvareutvikleren. Dette er gitt av muligheten til å spesifisere en VB-prosedyre for hver mulig hendelse. Til å begynne med er hver slik prosedyre tom, uten prosedyretekst, og derfor, når en hendelse inntreffer, skjer det ingenting. I teorien er det mulig å lage en prosedyre for enhver hendelse, men i praksis fyller programmereren ut prosedyrekoden med programkoden kun for de hendelsene som er av interesse.

Dermed gir VB brukeren et hendelsesbasert objektorientert programmeringsmiljø. For å si det enkelt, prosessen med å utvikle et programvareprosjekt i dette miljøet koker ned til å velge et sett med objekter og deres egenskaper, sette hendelser og prosedyrer for deres behandling, og lage programvare for å løse problemet, som sammen sikrer funksjonen til opprettet applikasjon.

Hovedvilkårene for visuell programmering, som nevnt ovenfor, er en gjenstand, formen, eiendom, klasse, hendelse, prosedyre, metode dr., som i alle visuelle applikasjonsutviklingsmiljøer har samme betydning.

Gjenstand Er en slags separat enhet som skiller seg fra andre enheter i spesielle egenskaper, oppførsel, interaksjon med andre objekter i applikasjonen. I den objektorienterte tilnærmingen er enhver applikasjon et sett med sammenkoblede objekter som implementerer de nødvendige funksjonelle kravene til applikasjonen. Et objekt er alltid konkret og eksisterer faktisk på skjemaet (som kontroller) eller i applikasjonen (som klasseforekomster).

Grunnenheten i objektorientert programmering er et programobjekt som kombinerer både dataene (egenskapene) som beskriver det og virkemidlene for å behandle disse dataene (metodene). Det vil si at programvareobjekter har egenskaper, kan bruke metoder og reagere på hendelser.

Hovedobjektene for visuell programmering er formen og dens kontroller.

Skjema (skjema ) Er et objekt som representerer et vindu der kontroller er plassert, for eksempel en knapp (Knapp); Merkelapp (Merkelapp); Tekstfelt (Tekstboks); Avmerkingsboks (Avmerkingsboks); Liste (ListBox); Nedtrekksliste (ComboBox); Bytte om (Radioknapp)og så videre .

Det visuelle programmeringsmiljøet lar deg se objekter på skjermen på designstadiet av applikasjonen, gjør det mulig å tilpasse objekter ved å endre deres plassering, størrelse og andre egenskaper. Skjemaet er containerobjekter, og samtidig er seg selv også et objekt. Når du plasserer et objekt på skjemaet, lagres hovedparametrene til objektet i den kjørbare programkoden. I dette tilfellet er objekter også programblokker eller fragmenter av programkode (klasser, prosedyrer, metoder, moduler), som det utformede prosjektet (applikasjonen) er "samlet fra".

Objektegenskap Er en verdi eller karakteristikk lagret av et objekt. Samtidig bestemmer settet med egenskaper til et objekt dets tilstand. For eksempel, Tekst ( Tekst ) eller Farge ( Baksidefarge ) form, måte Tekstjustering ( Justering ) eller Karakterfarge ( Forfarge ) tekstboks er egenskaper. I programmet åpnes objektet etter objektnavn ... Objektegenskaper kan settes i vinduet Egenskaper og endre egenskapene til objekter i programkoden.

I programkoden er det visse regler (spesifikt format) for å sette en egenskap - objektnavn og eiendomsnavn i henhold til reglene for punktnotasjon er atskilt med en prikk .

Klasse Er en samling gjenstander med felles egenskaper og oppførsel. For eksempel, Knapp 1( Knapp 1 ) på Skjema 1(Skjema1 ) med alle dens spesifikke egenskaper og handling er et objekt av klassen Knapp . Klassen er preget av slike grunnleggende konsepter for objektorientert programmering som:

· arv - klasseobjektet har alle egenskapene, metodene og hendelsene til klassen;

· innkapsling - skjule den komplekse virkningsmekanismen til objektet;

· polymorfisme - objekter av forskjellige klasser kan bruke metoder med samme navn, som fungerer forskjellig for forskjellige objekter.

Samling av gjenstander Er et sett med objekter forent med et felles navn, og ikke nødvendigvis objekter av samme klasse. Et eksempel på en samling er samlingene innebygd i VB, inkludert:

· Skjemaer(Skjemaer) - mange innlastede søknadsskjemaer;

· Kontroller(Kontroller) - Sett med alle kontroller på et skjema.

Navneområde Er et hierarkisk klassebibliotek organisert under unike navn som f.eks System.Windows eller System.Math . For å få tilgang til klasser og objekter basert på dem som er inkludert i navneområdet, kan operatøren plasseres i begynnelsen av programkoden Importer . Hvert prosjekt i VS inneholder også et rotnavnområde. Navnerommet i VS-dokumentasjonen kalles også klassebiblioteker .

Begivenhet Er et middel for interaksjon av objekter med hverandre. Hendelsen kan opprettes av brukeren eller oppstå som et resultat av påvirkning fra andre programvareobjekter. Objekter kan generere hendelser og utføre handlinger som svar på spesifiserte hendelser. Eksempler på hendelser - form , Klikk ( Klikk ) musen over objektet, DblClick ( Dobbeltklikk ) mus og andre . Som en reaksjon på hendelser kalles en hendelsesprosedyre, som kan endre egenskapene til objektet, kall det

På VB-språk , som i mange andre programmeringsspråk designet for å skrive applikasjoner for MS Windows , brukt av
hendelsesdrevet programmeringsmodell. Dette betyr i praksis at ingen applikasjoner kan fungere alene uten å samhandle med andre applikasjoner og med operativsystemet. La oss for eksempel ta det enkleste tilfellet når en kommando spesifiseres ved å trykke på en tast på tastaturet. Det kan ikke påvirke noen av applikasjonene direkte, og MS Windows fungerer i dette tilfellet som en mellommann. Ved å registrere hendelsen knyttet til tastetrykket, bestemmer operativsystemet hvor hendelseshåndteringen skal passere. Tastetrykkmeldingen sendes deretter til applikasjonen. Applikasjonen behandler den ved å analysere tastaturinndata og viser en melding, for eksempel i et aktivt tekstfelt.

Apper laget av med bruker VB , arbeid på grunn av samme prinsipp. Samtidig utfører VB et slags internt arbeid. For eksempel, når en knapp klikkes i applikasjonen, oppstår en hendelse - VB fanger opp den tilsvarende MS Windows-meldingen og øker hendelsen Klikk gjenstand Knapp .

Merk at i hendelsesdrevne programmer, det er ingen kontinuerlig programkode som kjører fra start til slutt. Dette betyr at etter å ha startet programmet, har brukeren ikke en klar ide om den spesifikke banen til algoritmekjøringen. Det vil si at du når som helst kan klikke på en hvilken som helst knapp i applikasjonen eller utføre for eksempel å skrive inn tekst i et felt, eller du kan om ønskelig stoppe behandlingen. Derfor må applikasjonen vente til en av disse hendelsene inntreffer, og først da kjører den spesifiserte programkoden. Og dermed, en hendelse er alltid nødvendig for å begynne å kjøre programkoden - dette er en av de viktigste reglene for å lage applikasjoner i MS Windows-miljøet .

Svaret på hendelser er å ringe hendelsesprosedyre , som tidligere ble laget av en programvareutvikler. Betydningen av en slik prosedyre er utførelse av programmerte handlinger: endre egenskapene til et objekt, kalle metoder, utføre beregninger i henhold til en gitt algoritme med utdata av resultatet til bestemte steder i applikasjonen, etc., for eksempel hvis brukeren trykker på en knapp, deretter utføres en sekvens av handlinger som en respons. er definert i hendelsesprosedyren i henhold til den spesifiserte algoritmen.

I tillegg til hendelsesprosedyrer kan brukeren lage generelle prosedyrer (brukerprosedyrer).

Brukerprosedyre Er en komplett programkode som implementerer en egen algoritme for problemet som skal løses. En slik prosedyre kalles imidlertid ved navnet på denne prosedyren, og ikke som et resultat av noen hendelse.

Metode Er en prosedyre som implementerer handlingene som er mulig med et objekt. Som et resultat av disse handlingene endres noe i objektet. VB gir brukeren et stort antall innebygde biblioteksrutiner som er klare til bruk. Disse rutinene er en integrert del av klassebiblioteket, det vil si at de er klassemetoder i .NET Framework.

Prosedyreprogrammeringsverktøy (prosedyrer) er en integrert del av ethvert programmeringsspråk på høyt nivå, som er en av hoveddelene i det moderne programmeringsparadigmet. Men det var først med fremveksten av språk som støtter objektorientert programmering at spesielle typer innebygde prosedyrer ble introdusert, kalt metoder . Metoder "Fungerer" som prosedyrer, men de tilhører spesifikke objekter, akkurat som egenskaper. I programkoden kan du referere til metoden på samme måte som til eiendommen – ved hjelp av punktnotasjon.

I VB-miljø kan du lage egen prosedyrer, laget av programvareutvikleren .

Vær oppmerksom på at enhver programkode for et prosjekt skrevet ved hjelp av VB består av et sett med prosedyrer, det vil si at all programkode er så å si inne i et sett med subrutineprosedyrer og funksjonsprosedyrer, og selve prosedyrene er inne i en klasse (modul).

Subrutinerutiner begynner med et nøkkelord Under End Sub, og funksjonsprosedyrer begynner med nøkkelordet Funksjon og avslutte med nøkkelord Avslutt funksjon , mellom hvilke programkoden for denne prosedyren er plassert. Programkoden for hver prosedyre består av en eller flere operatører av programmeringsspråket VB.

Metode for hendelseshåndtering Er en komplett programkode som implementerer en egen algoritme. For hver hendelse kan du programmere en respons, det vil si objektets reaksjon på en hendelse som har skjedd, som et resultat vil en viss sekvens av handlinger utføres - en metode for å håndtere hendelsen.

Navnet på en hendelsesprosedyre har tre deler (inkludert en understreking): Objektnavn_Hendelsesnavn.

På denne måten, hver gang du skriver kode som må utføres som svar på en hendelse, oppretter du en hendelsesprosedyre som kalles automatisk når den tilsvarende hendelsen inntreffer (for eksempel klikkes en knapp).

Operatør Er en programmeringsspråkkonstruksjon som spesifiserer en eller flere operasjoner , produsert over operander . Operandene kan være konstanter, variabler, uttrykk, funksjoner osv. Enhver operatør er skrevet i samsvar med de syntaktiske reglene for programmeringsspråket. For eksempel, i oppdragsoperatøren tegnet " = "Leser" for å tilordne "og betyr at en verdi lik verdien av uttrykket til høyre for" = ". For eksempel linjen

Form4.1.Text = "Skjema med bilde" betyr at i minnet navngitt Skjema4.1.Tekst verdi er skrevet - tekst "Skjema med bilde" og linjen P = A + B + C brukes i et program for å beregne verdien av et uttrykk og tilordne det til en variabel R .

Prosjekt Er en utviklet applikasjon (applikasjonsprogramkode) - et sett med filer som lagrer informasjon om alle programvarekomponenter som brukes i denne applikasjonen. Siden VB , på den ene siden er det objektorientert visuelt programmeringssystem, siden det tillater programmeringsalgoritmer på dette språket, og på den annen side er dette systemet programvaredesign miljø, Resultatet av programmerings- og designprosessene er et prosjekt som kombinerer programmeringskode og et grafisk grensesnitt. Derfor, for å brenne til disk eller laste et programvareprosjekt fra disk, er det nødvendig å brenne eller laste prosjektet, som inneholder alle komponentene (filene). Vanligvis består en VB-applikasjon av mange filer, inkludert en prosjektfil med utvidelsen .vbproj . En prosjektfil inneholder informasjon knyttet til én programvareoppgave – én applikasjon.

Prosjektet er også en sammenstillingsenhet. Sammenstillingen av prosjektet resulterer i en samling. Hvert prosjekt inneholder ett eller flere navneområder. På den innledende fasen av å lage et prosjekt for en gitt prosjekttype automatisk bygget prosjektramme bestående av klasser som er arvinger etter klassene som inngår i biblioteket FCL(Framework Class Library) - .NET Framework-klassebiblioteker. Så hvis utvikleren indikerer at han vil lage et prosjekt av typen " Windows Forms-applikasjon", Da vil objektet bli inkludert i prosjektrammeverket som standard Skjema 1- arvingen til bibliotekklassen Skjema... Utvikleren av programvareprosjektet vil supplere det opprettede skjemaet med kontroller - objekter i de tilsvarende klassene, og dermed utvide funksjonene til standardskjemaet.

Hvert prosjekt inneholder all informasjonen som trengs for å bygge en sammenstilling. Prosjektet inkluderer alle filer med klasser, bygget automatisk på tidspunktet for prosjektoppretting, og filer med klasser, laget av prosjektutvikler. Prosjektet inkluderer også installasjoner og ressurser nødvendig for arbeid. Filen som inneholder monteringsbeskrivelsen (manifest) er også en del av prosjektet.

Avhengig av valgt type, kan prosjektet være kjørbar eller upraktisk... Prosjekter som pågår inkluderer for eksempel prosjekter av typen Konsollapplikasjon eller Windows Forms-applikasjon... Når du bygger skjelettet til et løpende prosjekt, inkluderer det en klasse som inneholder en statisk prosedyre kalt Hoved ()... Som et resultat av å kompilere et slikt prosjekt, PE-fil - kjørbar bærbar fil med filtypen .exe... Slik PE-filen kan bare kjøres på datamaskiner der den er installert Framework .Net siden det er en administrert kodefil.

Ikke-gjennomførbare prosjekter inkluderer for eksempel prosjekter som
Klassebibliotek (DLL) som har utvidelsen. dll, og er dynamisk koblet bibliotek, de. disse prosjektene er ment å inkluderes (knyttes) til andre prosjekter. Som et resultat av å kompilere et prosjekt som
Klassebibliotek sammenstillingen vil inkludere en fil med utvidelsen .dll... Slike prosjekter (montasjer) kan ikke utføres direkte på en datamaskin. De er knyttet til de kjørbare sammenstillingene, hvorfra metodene til klassene som ligger i det ikke-kjørbare prosjektet kalles ( DLL).

Stadier av gjennomføring av de enkleste prosjektene- kan deles inn i flere trinn:

· Oppretting av et grafisk grensesnitt for prosjektet (brukergrensesnitt), som skal sikre interaksjonen mellom prosjektet og brukeren under arbeidet med prosjektet;

· Innstilling av verdier for egenskapene til objekter i det grafiske grensesnittet;

· Oppretting, redigering og feilsøking av programkoden til prosjektet;

· Lagre prosjektet for fremtidig bruk;

· Prosjektimplementering.

Løsning Er en applikasjon under utvikling, hvis filer inneholder informasjon om ett eller flere prosjekter, vanligvis knyttet til et felles tema. Løsningsfilen brukes til å administrere flere sammenkoblede prosjekter og har utvidelsen .sln. Dessuten er hvert prosjekt opprettet i VS plassert i ett skall kalt Beslutning.

Når et nytt prosjekt er opprettet, kan det plasseres i et eksisterende. Løsning eller en ny kan opprettes Løsning som inneholder prosjektet.

Så legg merke til følgende igjen:

Klasse Er det sentrale konseptet med objektorientert programmering. VB prosjektutvikler bruker standard klasser fra biblioteket FCL og lager sine egne klasser. Dessuten utfører klassen to forskjellige roller:

· Klasse - for det første er det en modul - en arkitektonisk enhet for å bygge et prosjekt på modulbasis. Å takle kompleksiteten til et stort prosjekt er bare mulig ved å dele det inn i moduler - relativt små enheter som tillater uavhengig utvikling og påfølgende integrasjon i et stort system.

· Klasse - for det andre er det en datatype, det vil si en semantisk enhet som beskriver egenskapene og oppførselen til et sett med objekter kalt klasseforekomster. Syntaktisk representerer en klasse en beskrivelse av data kalt klassefelt, beskrivelse klassemetoder og beskrivelse klassebegivenheter ... For en klasse som anses som en datatype, definerer felt tilstanden til objekter, metoder - oppførselen til objekter. Hendelser er noen spesielle tilstander som et objekt kan være i og som kan håndteres av hendelsesbehandlere utenfor klassen. Så for eksempel et objekt i klassen MENNESKELIG kan ha et arrangement" Fødselsdag"Og hver av behandlerne av denne hendelsen kan bringe sine gratulasjoner til objektet ved denne anledningen.

Klasser spiller vanligvis begge rollene. Men i VB kan du definere klasser som bare spiller rollen som en modul. den moduler som det er umulig å lage objekter for.

God programmeringsstil krever at hver klasse lagres i en egen fil oppkalt etter klassenavnet. Dette er et stilkrav som kanskje ikke oppfylles i praksis. I våre eksempler vil vi prøve å opprettholde denne stilen.

Ved å definere en klasse er prosjektutvikleren i stand til å dynamisk lage klasseobjekter. Det er en vanlig feil for programmerere som er nye i objektstil å forveksle begrepene objekt og klasse. Du må forstå forskjellen helt fra begynnelsen. En utviklergenerert objektklasse representerer en statisk beskrivelse av et sett med objekter. Et objekt er et dynamisk konsept, det skapes under utførelsen av et programvaresystem, det eksisterer faktisk i datamaskinens minne og forsvinner vanligvis ved slutten av prosjektgjennomføringen. En prosjektutvikler kan lage et programvaresystem som inkluderer to eller tre klasser, men i løpet av driften av et slikt system kan hundrevis av objekter dynamisk dukke opp, som samhandler med hverandre på en kompleks måte.

VS hovedvindu

Merk at prosessen med å lage en enkel applikasjon i VS-miljøet vil bli beskrevet i detalj i det neste Tema 4.2, samt i laboratoriearbeid vedr Tema 4.1."Visual Studio .NET integrert utviklingsmiljø". Gjør deg nå kjent med grensesnittet til VS-miljøet.

Løpe MS Visual Studio.

Skjermen vises startside- MS VS ( ris. 4.1.2-1).

Det er flere hovedpaneler i dette vinduet: Standard meny, vindu Standard verktøylinje, vindu Startside anitz en, vindu Solution Explorer, vindu Verktøykasse.

Ris. 4.1.2-1. Startside -Microsoft Visual Studio

Det skal bemerkes at når du arbeider med VB i VS IDE, kan du bruke både knappene på standardverktøylinjen og hovedmenyelementene øverst på skjermen.

VS gir brukeren en rekke verktøylinjer. Disse verktøylinjene inneholder knapper hvis funksjon avhenger av funksjonaliteten til den aktuelle verktøylinjen.

Vindu startside lar deg åpne nylig brukte prosjekter, søker etter eksempler, inneholder ulike lenker til nettsteder som kan hjelpe når du jobber med VS . I tillegg til prosessen med å jobbe med et prosjekt, vil forskjellige vinduer vises i stedet for startsiden, for eksempel et vindu Skjemakonstruktør, vindu Kode editor og så videre.

I vinduet Solution Explorer filene til gjeldende løsning (prosjekter) vises. Dette vinduet brukes til å få detaljert informasjon om objekter. . Den lar deg søke og utforske elementer, deres egenskaper, metoder, hendelser i prosjekter og referanser til dem.

Verktøy utviklet for å lette applikasjonsutvikling inkluderer også et vindu. Verktøykasse, viser kontroller som brukes i VB-prosjekter .

For å opprette et nytt prosjekt, bruk dialogboksen
Lag et prosjekt(fig. 4.1.2-2). For å åpne den må du gjøre ett av følgende:

Utfør kommando Lag et prosjekt fra hovedmenyen - Fil;

trykk på knappen Lag et prosjekt, plassert på standardverktøylinjen.

Ris. 4.1.2-2. Dialogvindu Lag et prosjekt

I VB kan du lage applikasjoner etter ulike maler. I denne opplæringen vil vi kun bruke malen Windows Forms-applikasjon.

Denne applikasjonen er designet for å lage tradisjonelle Windows-applikasjoner, brukergrensesnittet for dette er designet ved hjelp av MS Windows Forms. Dessuten, for formen til denne malen, kan du angi visse egenskaper og plassere forskjellige kontroller på den.

La oss se på et eksempel på de grunnleggende trinnene som kreves for å lage et prosjekt. Windows Forms-applikasjon.

Eksempel 4.1.2-1. Lag et prosjekt kalt Eksempel 4.1.2-1 og et grafisk grensesnitt som består av et skjema med én knapp og ett tekstfelt. Når du trykker på knappen, skal "Hei, MTUSI!" vises.

Prosjektskjema Eksempel-4.1.2-1 kan se ut som på fig. 4.1.2-3.

Ris. 4.1.2-3. Prosjekt GUI (skjema)Eksempel 4.1.2-1

For å gjennomføre prosjektet Eksempel 4.1.2-1 følgende trinn kreves:

1) Start VS.

2) Opprett et nytt prosjekt:

Fil og utfør deretter kommandoen Lag et prosjekt;

Velg en prosjektmal Windows Forms-applikasjon .

Som et resultat vil et vindu åpnes Form1.vb [Konstruktør] – Skjemakonstruktør(som angitt av den tilsvarende fanen) som lar deg implementere det grafiske grensesnittet til applikasjonen.

Velg et element i hovedmenyen Fil og utfør deretter kommandoen Lagre alt ;

dette vil åpne en dialogboks Lagre prosjektet;

Skriv inn i feltet Navn navnet på prosjektet Eksempel-4.1.2-1(som standard gir VB navnet WindowsApplication1) og skriv deretter inn Stedskatalognavn hvor prosjektet skal ligge, eller bruk knappen Oversikt for å søke etter ønsket katalog (fig. 4.1.2-4);

Klikk på knappen Lagre ;

som et resultat vil utviklingsmiljøet se ut som i fig. 4.1.2-5.

Ris. 4.1.2-5. Utviklingsmiljø

Visual Studio Panel Windows

Panelvindu startside(Fig. 4.1.1-1) lar deg se de sist brukte prosjektene, søke etter for eksempel programmer, både fra Hjelp og Internett, og også se lenker til nettsteder som inneholder nyheter om VS-produktet , dokumentasjon, opplæringsprogrammer.

Ris. 4.1.4-1. PanelvinduSkjemakonstruktør og kontekstmenyen

Startsiden åpnes automatisk når VS starter . Hvis vinduet startside ikke dukket opp, kan den kalles ved hjelp av kommandoen startside hovedmenyelement Utsikt

Panelvindu Form1.vb[Konstruktør] (skjemakonstruktør)
Hovedvindu er en Hovedarbeidsvinduet , der den visuelle utformingen av applikasjonen utføres (fig. 4.1.4-1). Dette vinduet kan vises på skjermen ved å klikke på fanen Form1.vb[konstruktør] eller ved å dobbeltklikke på navnet på skjemaet i vinduet Solution Explorer.

I vinduet Skjemakonstruktør alle former for applikasjonen lages visuelt ved hjelp av verktøysettet til utviklingsmiljøet. Du kan bruke et rutenett til å plassere objekter nøyaktig på et skjema i et vindu.

Størrelsen på skjemaet i vinduet kan endres ved hjelp av skjemavalghåndtakene og musen. For å endre størrelsen på skjemaet, plasser musepekeren over markøren og flytt den til ønsket størrelse når den blir en tohodet pil.

Å jobbe i et vindu Form1.vb[konstruktør] du kan bruke kontekstmenyen (fig. 4.1.4-1).

Ris. 4,1-2. PanelvinduKode editorog hennes og kontekstmenyen

Panelvindu Form1.vb (Koderedigerer) Er en kraftig tekstredigerer med mange muligheter, som er hovedprogrammererens verktøy for å lage og feilsøke programkode. Den kan også plasseres i Hoved arbeidsvindu(fig. 4.1-2) .

Panelvindu Solution Explorer og kontekstmenyen er vist i fig. 4.1.4-3.

Ris. 4.1.4-3. PanelvinduSolution Explorer og kontekstmenyen

Panel Kontrollelementer gruppert etter seksjoner
(Fig. 4.1.4-4). For å lage fordelsskjemaer trenger du hoveddelen Standard kontroller ( ris. 4.1.4-5).

Panelvindu Egenskaper er beregnet for å vise og angi egenskapene til prosjektobjekter, inkludert skjemaet og objektene plassert i det. Dette vinduet inneholder for eksempel slike egenskaper for det valgte objektet som posisjon i form, høyde, bredde, farge og andre (fig. 4.1.4-6).

For å åpne en dialogboks Egenskaper gjør ett av følgende:

I hovedmenyen Utsikt velge lag Egenskapsvindu;

Klikk på knappen Egenskaper-vinduet på standarden
verktøylinjer;

Velg et lag Egenskaper kontekstmeny for det valgte objektet;

Trykk på en tastaturtast .

Ris. 4.1.4-4. Verktøykasse-vindu 4.1.4-5. Panel

kontroller gruppert etter seksjon (Standardelementer)

Ris. 4.1.4-6. PanelvinduEgenskaper

Siden skjemaet og kontrollene hver for seg er objekter, endres egenskapssettet i dette vinduet avhengig av det valgte objektet. Ved hjelp av knappene I alfabetisk rekkefølge og
Etter kategori objektegenskaper kan sees alfabetisk eller etter gruppe (kategori), henholdsvis.

Et verktøytips vises nederst i vinduet som forklarer formålet med den valgte objektegenskapen. En mer detaljert forklaring finner du i hjelpesystemet. Du kan også bruke dynamisk hjelp ved å velge ønsket seksjon i vinduet Dynamisk hjelp.

Bruke en dialogboks Egenskaper, du kan endre standardegenskapene til objekter. Noen av egenskapene til et objekt, for eksempel størrelse og posisjon, kan angis ved å flytte objektet og endre størrelsen på det med musen i skjemadesigneren. Egenskapene som er angitt i vinduet Egenskaper kan endres under kjøring ved å skrive de riktige kodene i prosedyrer som du oppretter med koderedigeringsprogrammet.

Vanligvis inneholder et skjema mange objekter. Hvis du velger flere objekter samtidig, kan du i egenskapsvinduet se egenskapene som er felles for disse objektene.

4.1.5. Innstilling av parametrene til den integrerte
utviklingsmiljøer

Verktøyvinduene, hjelpesystemet, kompilatoralternativene til VS-utviklingsmiljøet er enkle og svært fleksibelt konfigurerbare.

Følgende trinn viser deg hvordan du endrer innstillingene for VB-utviklingsmiljøet i henhold til retningslinjene for beste praksis:

1) I hovedmenyen Service utføre kommando Import og eksport av parametere... Du kan bruke veiviseren som vises til å lagre miljøinnstillingene for bruk på en annen datamaskin, laste inn innstillinger fra en annen datamaskin eller tilbakestille innstillingene - alternativet du vil velge nå.

2) Plukke ut Tilbakestill alle innstillinger og klikk deretter på knappen Lengre... VS vil spørre om det er nødvendig å lagre gjeldende innstillinger i en fil før konfigurering. Du bør alltid sikkerhetskopiere dine nåværende innstillinger slik at du kan gå tilbake til dem hvis de nye innstillingene viser seg å være "ubeleilige".

3) Sjekk at et alternativ er valgt Ja, og vær oppmerksom på navnet på filen og mappene der VS skal lagre disse innstillingene.

4) Hvis du trenger å gå tilbake til disse innstillingene, samme veiviser og alternativet Import valgte miljøinnstillinger.

5) For å se en liste over standardalternativene som brukes for VS, klikk på knappen Lengre.

6) Klikk på Alternativer for VB utvikling, og klikk deretter på knappen Klar.

7) Veiviseren vil bytte IDE-alternativer, inkludert menykommandoer, verktøylinjer og innstillinger for noen dialogbokser, vinduer Verktøy og Kode editor.

8) Du kan gjenta denne konfigurasjonsprosessen når som helst du trenger å tilbakestille gjeldende innstillinger (for eksempel hvis du har gjort en feil i innstillingene), eller hvis du trenger å konfigurere VS til å bruke et annet programmeringsverktøy.

9) Klikk på knappen for å lukke veiviseren Lukk.

Hvis miljøparametrene for arbeid med VB er konfigurert, kan du utføre oppgaver. Men hvis de har endret seg, må følgende trinn følges for å bekrefte at innstillingene knyttet til prosjektene og VB-kompilatoren samsvarer med de som brukes i praksis. For å sjekke prosjekt- og kompilatorinnstillingene, må du gjøre følgende:

1) Klikk på kommando Alternativer menyelement Service og åpne en dialogboks Alternativer.

2) Dialogvindu Alternativer Er vinduet som inneholder mange av VS Tuning Options. For å se alle parameterne som kan endres, klikk på avkrysningsboksen Vis alle alternativer plassert i nedre venstre hjørne av dialogboksen.

3) I dialogboksen Alternativer klikk på kategorier Prosjekter og løsninger og deretter på seksjonen Generell. Denne gruppen av avmerkingsbokser og alternativer konfigurerer innstillingene for VS-prosjekter og -løsninger. For at programvaren skal samsvare med innstillingene som brukes i denne opplæringen, må du konfigurere og

9. juli 2003

Med bruken av en rekke visuelle applikasjonsutviklingsverktøy, har skriving av grafiske brukergrensesnitt blitt som en barnelek. Han pirket i den med musa - et skjema dukket opp, pirket i det en gang til - knappen ble trukket. Det virker for meg som at mange nå ikke tenker på en annen måte å programmere på i et grafisk miljø. Selvfølgelig kan du ikke argumentere mot fremgang; når du skriver store prosjekter, er alle disse bekvemmelighetene veldig nyttige. Men samtalen handler ikke om det. Noen ganger kommer det til absurditet, en primitiv applikasjon skrives ved hjelp av MFC, VCL etc. Slike programmer bruker minne som termitter og tar opp ekstra diskplass med sin fete kropp. Som regel "veier" MFC / VCL-analoger ti til tjue ganger mer enn programmer skrevet i et rent API. Og Visual Basic (Gud tilgi meg for denne setningen) med sin msvbvmXX.dll? Og systemressursene forbrukes mye mer (flere ganger). Fattige brukere, som nekter seg øl, sparer sedler for å kjøpe ny maskinvare. Er det ikke synd – de fattige? Ikke bare programmerere å drikke øl? Det er et annet positivt poeng i API-koding, programmereren kommer nærmere operativsystemet. Følgelig forstår og kontrollerer han det bedre. Og bare - det er en veldig spennende opplevelse. Igjen, alt det ovennevnte gjelder spesifikt for små, upretensiøse programmer, i store prosjekter er alt helt annerledes.

Forhåpentligvis overbevist. Gå.

Vi vil se på å lage et enkelt vindusgrensesnitt med minimal funksjonalitet. Det blir et enkelt vindu med to inntastingsfelt og to knapper. Når du klikker på "Kopier"-knappen, vil teksten fra det første inntastingsfeltet bli kopiert til det andre. Når du klikker på "Lukk"-knappen, vil programmet avslutte arbeidet. I fremtiden kan den tjene som en mal for å skrive andre, mer komplekse applikasjoner. Vi vil kommunisere i C / C ++, selv om vi ikke vil fornærme Delphi. Det generelle prinsippet er det samme, bare syntaksen er forskjellig. For å jobbe med systemmeldinger og API-funksjoner, må du koble header-filer til prosjektet ditt; i C / C ++ er det windows.h, i Delphi er det vinduene og meldingsmodulene.

Ethvert program i Windows har tre hoveddeler: en hovedfunksjon, en meldingsløkke og en vindusfunksjon som håndterer alle meldinger som sendes til vinduet.

Programmet vårt begynner å kjøre med funksjonen WinMain (). Dette er hovedfunksjonen. WinMain ()-funksjonen utfører vanligvis følgende oppgaver:

• Definerer klassen til vinduet. For ikke å forveksle med OOP-klassen.
• Registrerer gitt klasse i systemet.
• Oppretter hovedprogramvinduet og andre kontroller.
• Viser et vindu på skjermen.
• Starter en meldingssløyfe.
• Det er deklarert som følger: int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) La oss finne ut parameterne:
  • hInstance er et håndtak til gjeldende applikasjonsforekomst.
  • hPrevInstance - En håndtak til forrige forekomst av applikasjonen, hvis den kjører.
  • lpCmdLine er en peker til en streng som inneholder parametere som sendes til programmet ved oppstart.
  • nCmdShow er en konstant som bestemmer hvordan vinduet vises. (Se SW_ konstanter).

I Delphi vil vi ikke se et slikt bilde; i dette utviklingsmiljøet er hovedfunksjonen skjult for programmereren av kompilatoren. Selv om det utvilsomt er til stede i den endelige koden. For å registrere en vindusklasse må du fylle ut feltene til WNDCLASS type struktur (i Delphi TWNDCLASS). For dette har vi deklarert wcl-variabelen. wcl.hInstance = hInstance; En håndtak til gjeldende applikasjonsforekomst, hInstance-variabelen initialiseres av WinMain ()-funksjonen. Delphi er implisitt initialisert. wcl.lpszClassName = szWinName; Navnet på klassen. Vi har opprettet og initialisert strengvariabelen szWinName på forhånd. wcl.lpfnWndProc = WindowFunc; Peker til en vindusfunksjon. wcl.style = 0; En konstant som spesifiserer stilen til vinduet. CS_-flaggene brukes til dette, jeg satte det bare til null. Du kan spesifisere en kombinasjon av flagg ved å bruke den bitvise operasjonen "eller". wcl.hIcon = LoadIcon (NULL, IDI_ASTERISK); Håndtaket til applikasjonsikonet, returnert av LoadIcon ()-funksjonen. Jeg har lastet inn standardikonet. Se IDI_ konstanter. wcl.hCursor = LoadCursor (NULL, IDC_ARROW); Håndtaket til applikasjonsmarkøren, returnert av LoadCursor ()-funksjonen. Jeg lastet ned standardpilen. Se konstanter IDC_. wcl.lpszMenuName = NULL; Peker til en streng som spesifiserer navnet på meny-ressursen for denne vindusklassen. Ingen meny, ingen indeks. wcl.cbClsExtra = 0; Reservert felt. Sett til null. wcl.cbWndExtra = 0; Reservert felt. Sett til null. wcl.hbrBackground = (HBRUSH) COLOR_WINDOW; Vindusfarge. COLOR_WINDOW-konstanten støpes til HBRUSH-typen (ingen grunn til støping i Delphi). Ved å bruke GetStockObject ()-funksjonen kan du også angi fargen på vindusbørsten eller bakgrunnsbildet. Nå kan du gjerne registrere vindusklassen.

RegisterClass (& wcl); En peker til wcl-strukturen sendes som en parameter til RegisterClass-funksjonen.

I neste linje lager vi vinduet vårt.

hMainWnd = CreateWindow (szWinName, "Et enkelt vindu til API.", WS_OVERLAPPEDWINDOW ^ WS_THICKFRAME ^ S_MAXIMIZEBOX, CW_USEDEFAULT, CW_USEDEFAULT, 300, 170, HWND_DESKTOP, NULL, hInstance, NULL);

• Den første parameteren er navnet på vindusklassen.
• Den andre parameteren er tittelen på vinduet.
• Den tredje parameteren er vindusstilen. Fra standard WS_OVERLAPPEDWINDOW, ved å bruke xor-operasjonen, fjernet jeg vindusskaleringsevnen og deaktiverte maksimeringsknappen.
• Den fjerde og femte er plasseringen av vinduet fra øvre venstre hjørne av skjermen. Jeg har CW_USEDEFAULT, med denne verdien velger systemet automatisk vindusposisjonen.
• Den sjette og syvende parameteren er henholdsvis vinduets bredde og høyde.
• Den åttende parameteren er eiervinduet. I hovedvinduet er eieren skrivebordet (0). Kontrollene har et hovedvindu.
• Den niende er en peker til et menyhåndtak. Ingen meny, ingen indeks.
• Den tiende parameteren er et håndtak til gjeldende applikasjonsforekomst.
• Eleventh - Brukes når du lager applikasjoner med et MDI-grensesnitt. Vi trenger ikke.

Funksjonen returnerer et håndtak til det opprettede vinduet, som er lagret i hMainWnd-variabelen.
Vindushåndtak er et unikt nummer i systemet som et vindu eller kontroll identifiseres med.

Deretter vil vi lage de nødvendige kontrollene. Alle kontroller er de samme vinduene, de har bare et annet klassenavn. Det er ikke nødvendig å registrere kontrollklasser, de er allerede forhåndsdefinert i systemet. Knapp - klasseknapp. Inndatafeltet er redigeringsklassen. Innskriften er ststic-klassen. Det er mange klasser som tilsvarer standardkontrollene. Vi lager kontroller ved å bruke den kjente CreateWindow ()-funksjonen og den ukjente CreateWindowEx (). CreateWindowEx () lar deg lage et utvidet stilvindu. Vi bruker den til å lage inndatafelt. I denne funksjonen legges den første parameteren til, som setter denne svært utvidede stilen, resten av parameterne er de samme som i CreateWindow (). Kontroller er underordnede vinduer, eieren deres er hovedvinduet.

Når du oppretter kontroller, i parametrene til funksjonen, må du spesifisere håndtaket til hovedvinduet, samt stilen til WS_CHILD-vinduet. Utseendet og funksjonaliteten til kontrollene kan manipuleres ved å bruke flaggene: WS_, ES_, BS_, SS_, og kombinere dem med bitoperasjonen "eller". Når vi oppretter kontroller, initialiserer vi de tilsvarende variablene med deres beskrivelser, som returneres av funksjonene CreateWindow () og CreateWindowEx (). Vi vil trenge disse beskrivelsene for videre arbeid med kontrollene. Vi viser vinduet vi opprettet på skjermen og tegner det på nytt.

GetMessage-funksjonen henter neste melding fra applikasjonens meldingskø og sender den til vinduet.

• Den første parameteren er en struktur av MSG-typen (i Delphi, TMSG-typen)
• Den andre parameteren er håndtaket til vinduet som meldingen er ment for. Hvis NULL eller 0, så alle programvinduer.
• Den tredje og fjerde - lar deg angi rekkevidden av mottatte meldinger. Hvis 0, er alle meldinger adressert til vinduet.

GetMessage - Returnerer FALSE når WM_QUIT-meldingen vises, i så fall går løkken ut og applikasjonen avsluttes. TranslateMessage - Oversetter virtuelle nøkkelkoder til tastaturmeldinger. DispatchMessage - Sender en melding til vindusfunksjonen for behandling.

Vindufunksjonen gir funksjonaliteten til et program ved å behandle systemmeldinger. Vindusfunksjonen er en CALLBACK-funksjon, dvs. kalt opp av operativsystemet som svar på en innkommende ny melding. Vindusfunksjonen er deklarert slik:

LRESULT CALLBACK WindowFunc (HWND hMainWnd, UINT iMsg, WPARAM wParam, LPARAM lParam)

• HMainWnd er håndtaket til hovedvinduet.
• iMsg - meldingsnummer. Se konstanter WM_.
• lParam og wParam er meldingsparametere.

Når meldingen vises, kan vi sammenligne iMsg-parameteren med en av WM_-konstantene og programmere riktig programrespons.

For eksempel: Når venstre museknapp trykkes mens musen er over klientområdet i vinduet, heves WM_LBUTTONDOWN-hendelsen. Vindufunksjonen kalles, verdien av konstanten WM_LBUTTONDOWN legges inn i iMsg-parameteren, vi kan sjekke tilstanden og programmere programmets respons vi trenger.

Inne i vindusfunksjonen er det en utvalgssetning som utfører oppgaven ovenfor. I select-setningen må en standardbehandler organiseres, som implementeres av DefWindowProc-funksjonen (hMainWnd, iMsg, wParam, lParam);

Hvis dette ikke blir gjort, vil programmet vårt dø og ikke komme til live. Mange meldinger behandles av systemet selv, for eksempel: endre størrelse på vinduet, minimere / maksimere vinduet, kalle opp systemmenyen, etc. Dette er hva DefWindowProc () er for.

Når du arbeider med vinduskontroller, sendes en WM_COMMAND-melding til eiervinduet, med lParam som inneholder kontrollhåndtaket, og den høye byten til wParam-parameteren – identifikatoren for hendelsen som kalles inn i kontrollen. For eksempel: når du trykker på knappen - BN_CLICKED. Se konstantene BN_, WM_. Vi kan lukke programmet ved å bruke funksjonen PostQuitMessage (0). Denne funksjonen sender en WM_QUIT-melding til vinduet.

Noen få ord om hvordan du skriver slike programmer i Delphi. Vi oppretter et nytt prosjekt, starter prosjektlederen, sletter Unit1 sammen med skjemaet. Trykk Ctrl + F12 og åpne prosjektfilen. Vi fjerner skjemaenheten fra bruk, legger til vinduer og meldinger der. Slett alt mellom start og slutt. Arbeidsstykket er klart. Du kan kode. Å skrive programmer i ren API er umulig uten hjelp, som alltid bør være tilgjengelig. Hvis du var Gates selv, vil du ikke huske alt. Anbefale:

• først av alt - MSDN;
• Delphi hjelpesystem (MSTOOLS.HLP-fil);
• på nettstedet http://www.soobcha.ru/rushelp er det en russisk hjelp på Win32 API.

Det er alt.
Lykke til.

Bobachenko Maxim Nedlasting: CreateWnd.zip(2,6 K)
arkivet inneholder filene windows.cpp og windows.dpr

yadobr 14. januar 2014 kl. 09:10

Utforme et grafisk brukergrensesnitt

• Grensesnitt

Introduksjon

Det er milliarder av dataenheter i verden i dag. Enda flere programmer for dem. Og hver har sitt eget grensesnitt, som er "spakene" for interaksjon mellom brukeren og maskinkoden. Ikke overraskende, jo bedre grensesnitt, desto mer effektiv blir interaksjonen.

Imidlertid tenker ikke alle utviklere og til og med designere på å lage et praktisk og intuitivt grafisk brukergrensesnitt.

For meg selv begynte jeg med å stille spørsmål: generelle prinsipper, hva grensesnittelementer (EI) lage hvordan de skal utformes, hvor de skal plasseres riktig og hvordan de skal oppføre seg.
Nedenfor skal jeg prøve å svare på disse spørsmålene.

Generelle prinsipper

Hva slags EI å lage?

Hva skal utformingen av EI være?

Faktisk er EI-design et tema for en egen artikkel. Her må du ta hensyn til alt: fra farge, form, proporsjoner, til kognitiv psykologi. Noen få prinsipper er imidlertid verdt å merke seg:

Hvordan plasserer jeg EI på skjermen riktig?

Hvordan bør EI-er oppføre seg?

I varetekt

Denne artikkelen er ikke ment å være den mest omfattende veiledningen til prinsipper for grensesnittdesign. Det grafiske brukergrensesnittet er et stort emne som er nært sammenvevd med psykologi, og opptar hodet til forskere og hundrevis av sider med bøker og forskning. I et så lite format er det ingen måte å uttrykke fylden i emnet som diskuteres. Imidlertid vil overholdelse av de grunnleggende prinsippene tillate deg å bygge mer brukervennlige grensesnitt, samt forenkle selve designprosessen.
Takk for oppmerksomheten.

Litteratur

Jeff Raskin, "Grensesnitt: nye retninger i design av datasystemer"
Alan Cooper, "Om grensesnittet. Grunnleggende om interaksjonsdesign "
Alan Cooper, "Psykisk sykehus i hendene på pasienter"

Send det gode arbeidet ditt i kunnskapsbasen er enkelt. Bruk skjemaet nedenfor

Studenter, hovedfagsstudenter, unge forskere som bruker kunnskapsbasen i studiene og arbeidet vil være veldig takknemlige for deg.

postet på http://www.allbest.ru/

postet på http://www.allbest.ru/

DEN RUSSISKE FØDERASJONS FØDERALE UTDANNINGSBYRÅ

Statens utdanningsinstitusjon

høyere profesjonsutdanning

Russisk statshumanitær Universitetet

Institutt for informasjonsvitenskap og sikkerhetsteknologi

Institutt for generell informatikk

TEST

OM INFORMASJONSTEKNOLOGI

GRAFISKE GRENSESNITT OG DERES UTVIKLINGSVERKTØY

Lisichenok Konstantin Viktorovich

Eksternship 3 års studier

(4 års studier)

Gruppe b (informasjonssfære)

veileder,

Ph.D., lærer: Mashintsov E.A.

Moskva 2005

Plan

Introduksjon

X Window System

Generell struktur av systemet X-vinduet

Programmering med X Toolkit Intrinsic (Xt) bibliotek

Xt objekter, deres klassifisering

Informasjonskilder

Introduksjon

Da byen Strechy for første gang i 1959, på UNESCOs konferanse om informasjonsbehandling, foreslo en tidsdelingsmodus for å løse problemer på datamaskiner, er det vanlig å starte fra det øyeblikket med begynnelsen av interaktive beregninger og følgelig, studiet av menneske-maskin-grensesnittet. Etter hvert som datamaskiner vokste i kraft, økte også kostnadene for en interaktiv programvarekomponent. Spørsmålet om maskineffektivitet har eskalert med den eksplosive markedsinngangen for arbeidsstasjoner som kombinerte interaktivitet med grafikk. Begrepet effektivitet har siden endret sin betydning - hvis det tidligere reflekterte egenskaper som prosessortid og mengden minne som er okkupert, forstås det nå som enkel utvikling, enkel vedlikehold og enkel arbeid med programmet. Derfor er kostnadene for forskning og utvikling av brukergrensesnittet berettiget.

Utviklingen av enhver applikasjonsprogramvare innebærer som regel opprettelsen av et brukergrensesnitt. Siden de fleste moderne brukergrensesnitt er basert på lignende ideer (aktiv bruk av "musen", fokus på objekter, grafikk, etc. - imitasjon av prosesser og fenomener, muligheten for å bruke algoritmer som er kjent for hver person fra hans hverdag), er det er en mulighet og behov for utvikling av tilleggsprogramvare designet for å lage denne typen "standard" grensesnitt, eller snarere deres baser.

På den annen side krever de mange og varierte maskinvare- og systemplattformene som denne programvaren må kjøre på, kildeportabilitet. Kravene ovenfor fører logisk til ideen om et bærbart enhetlig programvareverktøysett for å lage brukergrensesnitt eller, hvis vi vurderer det endelige, et system (modul, blokk) som administrerer (administrerer, driver, vedlikeholder, administrerer) grensesnitt med brukeren.

Du kan klassifisere slike brukergrensesnittverktøy i henhold til skjemaet:

* Tekstskjermsystemer (curse, ncurse, etc).

* Grafiske skjermsystemer.

* Multi-vindussystemer (WMS):

* tegnorientert (tekst);

* grafikk;

* UI-verktøysett

* tradisjonelle;

* objekt orientert;

* UIDS - Utviklingssystem for brukergrensesnitt - utviklingssystem for brukergrensesnitt (verktøysett);

* UIMS - User Interface Management System - et system (administrasjon) av brukergrensesnittet (programvaremodul - en integrert del av sluttproduktet i forbindelse med den tilsvarende UIDS);

* UIDE - Utviklingsmiljø for brukergrensesnitt - utviklingsmiljø for brukergrensesnitt.

Denne ordningen later ikke til å være en systematisk klassifisering, snarere er den bare en oppregning.

For tiden jobbes det stort med å utvikle metoder og lage verktøy innenfor rammen av systemer kalt UIMS – User Interface Management System.

SystemX-vinduet

X-vinduet eller rett og slett X er et system for å lage et grafisk brukergrensesnitt, opprinnelig - på datamaskiner som kjører UNIX. X ble opprettet ved MIT (Massachusetts Institute of Technology). Foreløpig er versjon 11.6 (X11R6) allerede utgitt og forberedelsene er aktivt i gang for utgivelsen av versjon 7.

En funksjon ved X Window er arkitekturen - den er bygget i henhold til klient-server-skjemaet. Samspillet mellom X-klienten og X-serveren skjer innenfor rammen av den tilsvarende applikasjonsnivåprotokollen - X-protokollen. X-vinduet bryr seg ikke om transporten som brukes, som enten kan være en lokal UNIX-socket eller hvilken som helst nettverkstransport, for eksempel TCP. Dette betyr at X-klienten og X-serveren kan "live" på forskjellige datamaskiner, dvs. programmet kan utføre input-output av grafisk informasjon på skjermen til en annen datamaskin, dessuten spiller ikke forskjellene i arkitekturen til X-klienten og X-serveren noen rolle - dette leveres av X-protokollstandarden. Systemet gir grafisk utdata til maskinens skjerm, fanger opp signaler fra inngangsenheter som tastatur og mus, og sender dem videre til programmer. Det skal bemerkes at en utdataenhet kan ha mer enn én skjerm. X gir utdata til noen av dem. Alt dette: skjermen (skjermene), inndataenheter (tastatur, mus) kalles i X Window-termer - display.

På grunn av sin arkitektur brukes X Window fritt i distribuerte datasystemer, for eksempel i TCP / IP (internett) nettverk.

X lar brukeren (bak skjermen) kommunisere med mange programmer samtidig. Slik at utdataene fra dem ikke blandes, oppretter systemet på skjermen "virtuelle underskjermer" - vinduer. Hver applikasjon (som regel) tegner bare i sitt eget vindu (eller sine vinduer). X gir et sett med verktøy for å lage vinduer, flytte dem rundt på skjermen, endre størrelse på dem, vise dem og mer.

Som regel har programmer et sett med konfigurasjonsparametere - ressurser. Dette kan være fargen på vinduet, ulike parametere for tekstfonten (ligatur, størrelse osv.) og mye mer. Systemet standardiserer måten applikasjonsressurser er definert, administrert på og inneholder en rekke prosedyrer for å jobbe med dem. Denne samlingen av funksjoner kalles "ressursbehandleren" (Xrm - X ressursbehandler). "Lagringen" av programparametere kalles ressursdatabasen.

X opererer i henhold til den hendelsesdrevne arkitekturen - den organiserer kommunikasjon mellom programmene i seg selv og mellom programmene og det ytre miljøet gjennom arrangementer. En hendelse er en informasjonsenhet som identifiserer endringer eller handlinger som finner sted i systemet. Ved hjelp av hendelsesidentifikatoren kan du få informasjon om den - typen hendelse, dens egenskaper, hvor den skjedde osv.

Generell X Window-enhet

System X-vinduet er en samling av programmer og biblioteker. Dens "hjerte" er et spesielt program - X-serveren. Det er en egen UNIX-prosess som foregår på datamaskinen som skjermen er festet til. Det er serveren som kjenner funksjonene til en bestemt maskinvare, vet hva de skal gjøre for å vise et hvilket som helst grafisk objekt, for eksempel en primitiv, på skjermen. Han vet også hvordan han oppfatter og behandler signaler som kommer fra tastatur og mus.

Serveren kommuniserer med klientprogrammer ved å sende eller motta datapakker fra dem. Hvis serveren og klienten er på forskjellige maskiner, sendes dataene over nettverket, og hvis på en, brukes den interne kanalen. For eksempel, hvis serveren oppdager at brukeren har trykket på museknappen, forbereder den den tilsvarende pakken (hendelsen) og sender den til klienten hvis vindu musepekeren var i det øyeblikket knappen ble trykket. Omvendt, hvis programmet trenger å vise noe på skjermen, oppretter det den nødvendige datapakken og sender den til serveren. Åpenbart en beskrivelse av denne interaksjonen, pakkeformater osv. og utarbeider spesifikasjonen til den nevnte X-protokollen.

Du trenger imidlertid ikke å kjenne implementeringsdetaljene til serveren og X-protokollen for å programmere for X. Systemet gir et standardbibliotek med prosedyrer som programmer får tilgang til "høynivå"-tjenester X. Så, for å vise et punkt, er det nok å ringe den tilsvarende standardprosedyren og gi den de nødvendige parametrene. Denne prosedyren vil gjøre alt arbeidet med å generere datapakker og overføre dem til serveren.

X-vindu

Som nevnt tidligere er et vindu et grunnleggende konsept i X. Det representerer vanligvis et rektangulært område på skjermen som systemet gir til klientprogrammet. Sistnevnte bruker et vindu for å vise grafisk informasjon.

Vinduet har innside og kant. Hovedvindusattributtene er bredden og høyden på interiøret, og bredden (tykkelsen) på kanten. Disse parameterne kalles vindusgeometri.

Et koordinatsystem er knyttet til hvert vindu, hvis opprinnelse er i øvre venstre hjørne av vinduet (mer presist, dets indre). X-aksen er til høyre og y-aksen er nede. Måleenheten for begge aksene er piksler.

X Window lar et program lage flere vinduer samtidig. De er knyttet sammen i et hierarki der noen er «foreldre» og andre er «barn». Serveren selv lager ett hovedvindu på hver skjerm, som er den øverste "forelderen" av alle andre vinduer. Dette vinduet kalles "root"-vinduet.

Vindushåndtering

Vinduer kan plasseres på skjermen på alle måter, og overlapper hverandre. X-vinduet har et sett med verktøy som klientprogrammet kan bruke til å endre størrelsen på vinduene og deres plassering på skjermen. En funksjon ved systemet er at det ikke har en innebygd mulighet til å kontrollere vinduer ved hjelp av mus eller tastatur. For å gjøre dette trenger du en spesiell klient - vindusbehandleren.

Lederen kan imidlertid ikke administrere vinduene riktig uten å vite noe om dem. Windows kan ha ulike egenskaper som vindusbehandleren bør gi: for eksempel er det i mange tilfeller praktisk å ha vindustitler, i andre er det ønskelig at vinduet ikke kan gjøres mindre, eller omvendt - større enn en viss størrelse. Vinduet kan "skjules" til et piktogram ("ikon") - i dette tilfellet må lederen vite hvilket ikon som skal brukes og hvordan det skal navngis. Kunder kan kommunisere sine ønsker angående vinduer til lederen på to måter:

* når du oppretter et X-vindu, kan "anbefalinger" (hint) om den opprinnelige plasseringen av vinduet, dets geometri, minimums- og maksimumsstørrelser osv. overføres;

* du kan bruke Xs innebygde måte å kommunisere mellom programmer på - "egenskaper"-mekanismen.

X Window Graphics Capabilities

X Window System er designet for å kjøre på punktgrafikkskjermer. Antall bits per piksel kalles dybden eller tykkelsen på skjermen. Bits med samme tall (identiske binære sifre) i alle piksler danner så å si et plan parallelt med skjermen. Dette kalles fargeplanet. X lar deg male i alle fargeplan(er) uten å påvirke de andre.

Pikselverdien setter ikke direkte fargen på punktet på skjermen, men setter cellenummeret i en spesiell matrise, som lagrer fargeverdien, dvs. pikselverdien spesifiserer fargenummeret i den gjeldende paletten.

X har et stort sett med prosedyrer som lar deg tegne grafiske primitiver: punkter, linjer, buer, tekst; arbeide med friformsregioner.

"Egenskaper" og atomer

X Window System har innebygde fasiliteter for å gi informasjon mellom klientprogrammer. Mekanismen til "egenskaper" brukes til dette. En "egenskap" er en informasjonsstruktur knyttet til et objekt, for eksempel et vindu, tilgjengelig for alle X-klienter. Hver egenskap har et navn og en unik identifikator - et atom. Vanligvis skrives eiendomsnavn med store bokstaver. Atomer brukes for å få tilgang til innholdet i egenskaper for å redusere mengden informasjon som sendes mellom klienter og X-serveren.

X gir en rekke prosedyrer som lar deg oversette navnet på en egenskap til et unikt atom, og omvendt få de nødvendige dataene fra atomet.

Noen egenskaper og deres tilsvarende atomer er forhåndsdefinert og opprettes på tidspunktet for serverinitialisering.

Bibliotek programmeringX Toolkit Intrinsic (Xt)

Det er laget flere pakker for å lette programmering i X window-systemet. De facto-standarden er for tiden X Toolkit Intrinsics (Xt)-biblioteket, som er inkludert i standardleveransen av systemet. Xt gjør det enkelt å initialisere programmer og lage vinduer. I tillegg inneholder biblioteket verktøy for å lage objekter (kontroller) som brukes av programmer ved kommunikasjon med brukere. I Xt-termer kalles kontrollen widget.

For øyeblikket, på grunnlag av pakken, implementeres ulike sett (sett) med kontrollelementer (objekter), for eksempel Athena, OSF / Motif, Open Look. Disse settene, i forbindelse med selve Xt, brukes som et hendig verktøy for å lage grensesnitt. De tar på seg slitet som en programmerer må gjøre manuelt når de skriver en tilpasset applikasjon som kun bruker X Windows kjernebiblioteksrutiner.

Xt grunnleggende

programmering av brukergrensesnitt

Xt objekter

Xt-pakken er en base for å lage kontroller - widgets (maler). I Xt-forstand er en widget ganske enkelt en datastruktur hvis felt inkluderer ID-en til selve elementet, ID-en til vinduet, hvis noen, og mye mer. Attributtene til et slikt objekt kalles ressurser. Ressursene til en widget kan for eksempel være fargen på vinduet, fargen på vinduskanten, fonten til den viste teksten, etc.

Hvert objekt tilhører en av de forhåndsdefinerte widgetklassene. En klasse forstås i vanlig forstand for objektorientert programmering, dvs.: en klasse kan betraktes som et sett av forekomster (objekter) med de samme egenskapene. Xt-klassene danner et hierarki.

Under drift oppretter programmet selve objektene (klasseforekomster - widget). De danner aggregater, som hver også representerer et visst hierarki. Hvert slikt hierarki kalles et widget-tre. Roten til treet er nødvendigvis en widget som tilhører en av underklassene til en spesialklasse - Shell. Hvis blant de to widgetene A og B i objekttreet, er den første nærmere roten enn den andre, så er A det overordnede objektet ("overordnet") for B, og B er underobjektet (eller "underordnet" objekt ( barn)) for A. Dermed er skallobjektet den overordnede widgeten for alle andre widgets i dette objekttreet. Det er han som utfører interaksjonen mellom programmet og vindusbehandleren.

Det beskrevne widgethierarkiet tilsvarer forholdet til vinduene deres, som er en egenskap til X-vinduet. I tillegg er et annet hierarki pålagt objekter. Faktum er at under drift kan noen gjenstander kontrollere andre. For eksempel, hvis et objekt har underobjekter, så når geometrien endres, kan det automatisk gjenoppbygge geometriene til dets etterkommere. For å gjøre dette mulig etableres en kobling mellom widgeten - en "kontroll"-lenke. Hvert objekt kan ha ett eller flere underobjekter "administrert" av seg.

Det er tre mekanismer for et Xt-basert program for å samhandle med en widget og et X-vindu.

* Ring tilbake

Prosedyrer ("callback-prosedyrer"). For enhver klasse er et sett med handlinger definert som objekter som tilhører den må reagere på. For eksempel, for enhver klasse, er det et svar på ødeleggelsen av en widget. Når en handling utføres, kalles enten Xt-standardfunksjonen eller én eller flere prosedyrer levert av programmet. Slike funksjoner kalles tilbakeringingsprosedyrer eller ganske enkelt tilbakeringing.

* Handling

-prosedyrer. Programmet kan bestille en reaksjon på en bestemt kompleks hendelse (gruppe av hendelser) som kommer fra Xt. Hvis en hendelse inntreffer, søker Xt etter og kaller opp den aktuelle funksjonen.

* Hendelsesbehandlere

- hendelsesbehandlere. Denne metoden ligner den forrige, men raskere og mindre fleksibel. Den lar deg svare bare på enkle (enkelt) hendelser, men ikke på sekvensen deres.

Generell programmering

X-programmer må gjøre en rekke standard ting, som å etablere en tilkobling til serveren, sette de nødvendige egenskapene for vindusbehandlingen og mange andre trinn. Hvis Xt brukes, gjøres alt dette i én prosedyre - XtInitialize (). Den initialiserer selve pakken, X Window-ressursbehandleren ((\ term ressursbehandling), og utfører alle andre nødvendige operasjoner. Anrop til XtInitialize () (eller XtAppInitialize ()) må gå foran alle andre Xt-prosedyrekall. XtInitialize () returnerer shell-widget identifier som kan brukes som roten til programmets objekttre. Vanligvis er navnet på programklassen det samme som navnet på selve programmet, starter kun med stor bokstav Ressursadministratoren bruker navnet og klasse av programmet for å slå opp parameterne i ressursdatabasen.

Hvert program kan angi noen parametere på kommandolinjen. Xt definerer "standard" parametere som kan sendes ved programoppstart. I tillegg kan kommandolinjen inneholde ikke-standardparametere som kun er spesifikke for denne applikasjonen. XtInitialize () skanner kommandolinjen og plasserer de riktige dataverdiene i databasen.

Under initialiseringen opprettes også en programkontekst – en struktur som lagrer all informasjon om applikasjonen. Konteksten er ment å beskytte programmet mot påvirkning av ulike modifikasjoner i operativsystemet. XtInitialize () oppretter en standardkontekst (standardkontekst), men likevel, fra og med den fjerde versjonen av X, anbefales det å lage en egen "personlig" kontekst for hver enkelt forekomst av programmet, som når det gjelder Xt-bruk XtAppInitialize () prosedyrekallet ( i stedet for XtInitialize ()). Merk her at en applikasjon i Xt kanskje ikke har ett, som vanlig, men flere "toppnivå"-objekter.

Det neste trinnet etter initialisering er stadiet med å lage kontrollelementer i programmet, beskrive forholdet mellom dem, angi reaksjoner på ulike hendelser (registrering av hendelsesbehandlere og andre lignende objekter). Dette kan gjøres på forskjellige måter, den tradisjonelle bruken er for eksempel å lage et objekt av XtCreateWidget () prosedyren, å overføre kontroll over objektet til dets overordnede - XtManageChild () prosedyren, for å registrere hendelsesbehandlere for widgeten - XtAddEventHandler ()-prosedyren osv. etc.

Etter at alle programobjekter er klare for arbeid, vises deres grafiske representasjoner (for eksempel tilsvarende disse widgetvinduene) på skjermen ved hjelp av XtRealizeWidget ()-prosedyren.

Det neste trinnet er hovedsyklusen - syklusen for å motta og sende hendelser. Den implementeres ved å kalle XtMainLoop () (XtAppMainLoop ()) prosedyren.

Et program som kun bruker Xlib-rutiner må vurdere hver innkommende hendelse (ved å eksplisitt kalle den fra hendelseskøen, for eksempel XNextEvent () eller XPeekEvent ()) og reagere deretter. Hvis oppgaven har flere vinduer, før du utfører noen handlinger, er det nødvendig å bestemme i hvilke av vinduene hendelsen skjedde, og på hvilket nivå i hierarkiet denne hendelsen vil bli behandlet (vil dette objektet eller dets overordnede håndtere denne hendelsen? ). Alt dette er ganske slitsomt.

Xt tar seg av alt det daglige arbeidet. XtMainLoop () mottar neste hendelse og bestemmer vinduet den er ment for. Den tilsvarende widgeten er plassert langs vinduet. For sistnevnte er det definert en hendelsesbehandler, handlingsprosedyre eller tilbakeringing, registrert for å reagere på en hendelse som har skjedd. Hvis det er noen nettverk, blir de oppringt. Mekanismen beskrevet ovenfor kalles hendelsesforsendelse.

XtMainLoop () (XtAppMainLoop ()) avslutter automatisk programmet på forespørsel fra vindusbehandleren.

Xt objekter, deres klassifisering

Xt gir et sett med verktøy for å lage objekter som brukes av programmer for å kommunisere med brukeren, og generelt med resten av omverdenen.

Hver widget opprettet av programmet er en representant for en eller annen klasse. Xt og pakker basert på den, som OSF / Motif, Athena, Tk / tcl, Open Look, etc., har et stort antall slike klasser. Å lage nye widgets som ikke finnes i standardbibliotekene krever også å opprette (definere) den tilsvarende klassen, som vanligvis er en tidkrevende oppgave.

Hver klasse har et antall faste egenskaper som er felles for alle forekomstene (for eksempel en liste over tilbakeringingsprosedyrer). Verdiene av disse egenskapene for selve gjenstandene kan variere.

Alle Xt-klasser danner et hierarki. Hvis klasse B er nærmere toppen av hierarkiet enn klasse D, kalles B base for D, og ​​D kalles en avledet klasse (eller underklasse) for B.

Underklasser arver egenskapene til alle sine basisklasser. Dette betyr at en forekomst av en klasse har egenskaper ikke bare av klassen, men også av attributtene til alle basisklassene.

I programmer identifiseres hver klasse av en variabel som peker til den tilsvarende datastrukturen. Denne variabelen kalles en klassepeker. Dataene for denne strukturen fylles ut når Xt initialiseres.

De viktigste widgetklassene er:

Gjenstand. En abstrakt klasse (en klasse som ikke genererer sitt eget objekt) som brukes som roten til treet til alle objekter. Den inneholder en enkelt underklasse:

RectObj. En abstrakt klasse som brukes til å definere noen vanlige egenskaper som kreves for funksjonen til ulike typer objekter (for eksempel for objekter som ikke har et vindu). Den inneholder en underklasse:

Kjerne. Roten til treet til widgetklasser som har vinduer. Denne klassen definerer egenskaper som er felles for alle objekter, for eksempel størrelsen på widgetvinduet og dets plassering på skjermen. Inneholder en underklasse:

Sammensatte. Widgeter som tilhører denne klassen kan være overordnede til andre objekter. Forekomster av Composite-klassen definerer følgende atferd for underobjektene sine:

* setter plasseringen av "barne"-widgetene i henhold til visse begrensninger;

* ved ødeleggelse, frigjør minnet som brukes av underobjekter (ved ødeleggelse av widgeten til Composite-klassen, vil alle dens "etterkommere" bli ødelagt først);

* kontrollerer utseendet på skjermen til vinduene til sine underordnede widgets;

* kontrollerer overføringen av inputfokus mellom objekter.

Composite-klassen inneholder underklasser:

Begrensning. Denne klassen er en ytterligere utvidelse av basisklassen. Dens forekomster har ekstra kontroll over størrelsen og plasseringen til deres etterkommere. For eksempel kan underobjekter plasseres i en spesiell rekkefølge: i en rad, i en kolonne osv.

Shell. Dette er en spesiell klasse for samhandling med vindusbehandleren. widget fra denne klassen kan bare ha ett barn. Shell-klassen inneholder underklasser:

OverstyrShell. Det er en viktig underklasse av Shell-klassen. For en vinduswidget av denne klassen er override_redirect-attributtet satt til True, dvs. vindusbehandleren har ingen kontroll over det. Vinduer av objekter i denne klassen har som regel ikke tilbehør lagt til av vindusbehandleren (tittel, ramme, standardknapper), og brukes hovedsakelig til å lage menyer av forskjellige typer.

WMShell. Det er en spesiell underklasse av Shell-klassen som inneholder flere felt som kreves for å samhandle med vindusbehandlingen. Inneholder:

VendorShell. Denne klassen er ment å tillate interaksjon med tilpassede vindusbehandlere. Denne klassen inneholder underklasser:

TopLevelShell. Widgets av denne klassen brukes vanligvis som skallobjekter i programobjekttreet. Han inneholder:

ApplicationShell. Et program kan vanligvis bare ha én forekomst, som tilhører ApplicationShell-klassen.

TransientShell. Denne klassen skiller seg fra den forrige bare i særegenhetene ved interaksjon med vindusbehandleren. Windows-widgets av denne klassen kan ikke minimeres (gjøres om til et ikon). Men hvis forelderen til et objekt i TransientShell-klassen blir til et ikon, fjernes widgetvinduet fra skjermen. TransientShell-klassen brukes til å lage dialoger.

Hver av widgetklassene, og derfor objektene som er opprettet på grunnlag av den, har et ganske stort antall parametere. De kalles "ressurser" i Xt-termer. Xt tilbyr et bredt utvalg av verktøy for å jobbe med dem.

Ytterligere Xt-funksjoner

Xt gir en mekanisme for å arbeide med filer (og generelt med eksterne enheter) asynkront. En applikasjon kan registrere en prosedyre som vil bli kalt når data er klare eller når lese-/skrivefeil oppstår.

Xt gir en applikasjon med muligheten til å utføre visse handlinger med spesifiserte intervaller. Vis for eksempel med jevne mellomrom gjeldende tid på skjermen i et spesifisert vindu, etc. For slike formål brukes en spesiell Xt-mekanisme - en timer. Den gir et anrop med et spesifisert tidsintervall til en spesiell funksjon spesifisert av programmet.

Xt gir muligheten til å utføre en handling når hendelseskøen er tom. Dette oppnås ved å registrere en spesiell "arbeids"-prosedyre som Xt vil ringe hvis hendelseskøen er tom. Slike funksjoner brukes vanligvis til å utføre ulike handlinger og beregninger på svært kort tid.

Hver applikasjon kan om nødvendig endre den vanlige syklusen for å motta og sende (behandle) hendelser - Xt gir et helt sett med prosedyrer for å jobbe med hendelseskøen.

Xt har en mekanisme kalt akseleratorer som lar deg injisere hendelses- og handlingsavhengigheter. Akseleratorer ligner på handlingsprosedyrer med den forskjellen at en hendelse (eller gruppe av hendelser) som oppstår i en widget starter et kall til den tilsvarende handlingsprosedyren for et annet objekt.

Xt støtter flere måter å jobbe med widgets på. Så programmet, ved å bruke prosedyrene gitt av Xt, kan vise et vindu, angi en eller annen driftsmodus for det og lukke vinduet når det blir unødvendig. Disse rutinene brukes hovedsakelig til å lage popup-menyer og dialoger. Vanligvis har alle widgetsett (for eksempel OSF / Motiv) sine egne mye mer praktiske prosedyrer for å lage menyer og dialoger.

Xt-tillegg Xt er for tiden strengt standardisert av X-konsortiet, men det er ingen standarder på høyere nivå. Populære er:

* OSF / Motiv Toolkit;

* Athena widgetsett;

* OPEN LOOK Intrinsic Toolkit;

* InterViews;

* Tk / tcl.

Den mest utbredte og nesten de facto standarden er nok OSF / Motif.

Athena

Athena Widget-settet leveres av X-konsortiet i standard X-distribusjon. Athena ble opprettet som en del av de grunnleggende applikasjonene og verktøyene for MITs Athena Project, som er X Window System.

Athena hadde opprinnelig "flat" grafikk - alle knapper, menyer og andre grensesnittelementer hadde ingen skygger, dvs. var flate. For omtrent et år siden ble AW3d utgitt - en variant av Athena Widgets, der denne feilen ble eliminert.

Motiv

Open Software Foundation Motif (OSF / Motif) er en pakke som inkluderer en vindusbehandler, et sett med verktøy for å utføre ulike hjelpeoperasjoner og et bibliotek med objekter bygget på toppen av Toolkit Intrinsics.

Motiv støtter alle Xt-klasser, og derfor ressursene til disse klassene, men konstanter brukes til å skrive navnet og klassen til et objekts ressurs, prefikset med henholdsvis XmN og XmC. For å registrere ressurstypen brukes konstanter med XmR-prefikset (i stedet for XtR, som er akseptert i Xt).

Motiv utvider mange av objektklassene levert av Xt. Spesielt støtter Motif et ganske stort sett med klasser som lar deg lage menyer, rullefelt), klikkbare knapper, redigeringselementer, etc.

I tillegg gir Motif en spesiell klasse med objekter kalt gadgets, som danner en egen XmGadget-klasse i Motif, som er en underklasse av RectObj-klassen. De kan også brukes til å lage grensesnittelementer, men de har den særegenheten at de ikke har egne vinduer. En gadget bruker foreldrenes vindu til å tegne.

Hver widget-klasse har et ganske bredt utvalg av både arvede og ekstra ressurser som er spesifikke for den. De lar deg kontrollere slike viktige egenskaper ved objekter som bakgrunnsfarge, plassering på skjermen, font på vist tekst, etc.

Noen av Motif-klassene brukes ikke til å lage widget-forekomster (slike klasser kalles abstrakt i OOP-terminologi). De inneholder de vanligste attributtene og metodene som kreves for at de ulike widgettypene skal fungere.

Motiv har to hovedunderklasser av objekter: XmPrimitive og XmManager (XmGadget-klassen ble nevnt tidligere). Begge disse klassene er abstrakte. Den første arver fra Core-klassen og brukes som base for objektklasser som ikke eier andre objekter. Eksempler er trykknapper, lister osv. XmManager-klassen arver fra Constraint-klassen og brukes til å lage objekter som kan ha og administrere underordnede objekter.

Objektklassifisering

XmGadget-klassen. Ved instansiering av vanlige Motif-objektklasser (widget), opprettes det tilsvarende vinduet. Hvis programmet bruker mange widgets, fører dette til en betydelig nedgang i applikasjonen. Tid brukes både på å lage vinduer og på videre arbeid med dem. Men det er lett å se at det ikke er nødvendig å ha et eget vindu for hvert objekt. Etiketter, knapper og mange andre widgets kan med hell bruke overordnede objekter til å tegne vinduet. Ingen vindu - du trenger ikke å få tilgang til serveren igjen, ytelsen øker og ekstra minne er ikke bortkastet.

For å implementere nettopp denne ideen har Motif-utviklerne duplisert noen av objektklassene, og laget to versjoner – med et vindu og uten et vindu. Versjoner av objekter som ikke har vinduer henter hierarkiet fra den abstrakte klassen - XmGadget, og deres generelle navn er det samme. Denne spesielle klassen av objekter arver sine egenskaper fra RectObj-klassen, som igjen er en abstrakt klasse som inneholder de grunnleggende mekanismene for å manipulere objekters geometri.

Foruten det faktum at dingser ikke har egne vinduer, er det andre begrensninger pålagt dem. Så for dem er det umulig å definere hendelsesbehandlere, oversettelsestabeller. I tillegg kan gadgeter ikke ha etterkommere objekter. Resten av funksjonaliteten til gadgeten og den tilsvarende widgeten er den samme, så vi vil ikke beskrive dem separat, bare liste dem opp.

XmGadget-klassen inneholder underklasser:

* XmArrowButtonGadget.

* XmLabelGadget. \ Hfil

* XmPushButtonGadget.

* XmToggleButtonGadget.

* XmCascadeButtonGadget.

* XmSeparatorGadget.

XmPrimitive klasse. Denne abstrakte klassen inneholder:

XmArrowButton. En forekomst av klassen er en knapp som har en retningspil. Knappen kan klikkes med mus eller tastatur. Grensen til en kontroll kan ha en skygge, den brukes til å vise forskjellige tilstander der et objekt kan være: fri ("frigitt") og trykket.

XmLabel. Representanter for denne klassen (etiketter) er noen av de enkleste Motivobjektene. Tagger er laget for å vise informasjon: tekst eller bilder (bit (piksel) kart).

XmPushButton. Representanter for denne klassen er rektangulære trykknapper der en tekstlinje kan tegnes.

Hvis et objekt velges, for eksempel ved å trykke venstre museknapp mens markøren er på objektet, endres fargen på widgetkanten, noe som skaper en klikkeffekt. Etter at du slipper knappen, gjenopprettes kantfargen. Du kan også klikke på en slik widget fra tastaturet - for å gjøre dette må du overføre inngangsfokuset til objektet og trykke på "mellomrom"-tasten (vanligvis).

XmDrawnButton. Objekter i denne klassen ligner på trykket knapper med den eneste forskjellen at det ikke er tegnet tekst i dem, men et vilkårlig bilde (pikselkart).

XmToggleButton. Objekter i denne klassen representerer en liten knapp, ved siden av som regel er det en forklarende tekst. Knappen kan være i to tilstander: på og av (det vil si at det er en bryter). De er merket med en endring i kontrollens utseende.

En representant for denne klassen brukes til å lage såkalte "sjekkknapper", som det ville være lurere å kalle "avmerker", og "radioknapper" (radioknapper) - flerposisjonsbrytere. De første brukes til å sette logiske parametere, dvs. har to betydninger. Sistnevnte tjener et lignende formål, men settet med betydninger i dette tilfellet er begrenset og inneholder mer enn to elementer. Formen til den grafiske representasjonen av et objekt av typen XmToggleButton avhenger av om det brukes som en "hake" eller "radio"-knapp.

Vanligvis er widgetene til XmToggleButton-klassen kombinert til konstruksjoner som kalles henholdsvis en avkrysningsboks og en radioboks. Disse blokkene representerer på sin side modifikasjoner av objekter i XmRowColumn-klassen, beskrevet nedenfor.

XmCascadeButton. Objekter i denne klassen representerer trykknapper og brukes når du oppretter en meny. Når du klikker på et objekt, vises en undermeny for neste nivå.

XmList. Medlemmer av denne klassen er noen av de mer interessante objektene i Motif. De er designet for å vise en liste over strenger og tillate brukeren å utføre ulike handlinger med listeelementene. Brukeren kan velge én eller flere linjer presentert i dette objektet, mens de er uthevet. I tillegg, hvis listen har inputfokus, er ett av elementene uthevet med en stiplet kantlinje. Denne boksen kalles listemarkøren.

XmScrollBar. Objekter i denne klassen - rullefelt (rullefelt) brukes som regel sammen med andre objekter, for eksempel en liste (XmList), tekst (XmText) og andre. Rullefeltet er beregnet for å rulle området hvis informasjonen som presenteres i den (liste, tekst, bilde osv.) ikke kan vises i hele vinduet. Objekter i XmScrollBar-klassen representerer en stolpe (horisontal eller vertikal) med pilknapper langs kantene. Hvis du klikker på en av dem, kan du bla i retningen som er angitt av pilen. På stripen av selve rullefeltet er det en glidebryter (glidebryter) - et uthevet rektangel. Hvis du "kroker" den med musen og "drar" den, fører det som regel også til rulling av området.

XmSeparator. Objekter av denne klassen - separatorer - brukes som regel for å forbedre utseendet til programvinduer. En slik widget er en vertikal eller horisontal stripe (linje) som skiller grupper av objekter. For eksempel kan skilletegn brukes i menyer for å skille noen kommandoer fra andre, i dialoger - for å isolere gruppen av trykket knapper fra andre elementer, etc.

XmText. Objekter i denne klassen lar deg vise én eller flere tekstlinjer. Hvis linjene ikke passer inn i vinduet, kan bildet rulles til venstre-høyre og opp-ned. Teksten kan redigeres - redigeringsmodusen kan endres med den tilsvarende innstillingen for objektressursene.

Motif gir en rekke praktiske prosedyrer som lar deg utføre et bredt spekter av operasjoner med widgeten til denne klassen: hente og endre data, kopiere den valgte delen av dataene til systembufferen (utklippstavlen), og så videre.

XmTextField. Objekter i denne klassen lar deg se og redigere en enkelt tekstlinje.

XmManager-klassen. Denne klassen er abstrakt, dvs. ikke brukt til gyteobjekter. Den definerer de grunnleggende parameterne som trengs for å bygge widgetklasser som kan manipulere andre objekter. Disse ressursene er nødvendige for å vise underordnede widgets på riktig måte og kontrollere deres inndatafokus.

XmManager-klassen inneholder:

XmBulletinBoard. Objekter av denne klassen kan ha underobjekter som er plassert i vinduet på en vilkårlig måte. Vinduskoordinatene til underordnede widgets måles i et koordinatsystem som har sin opprinnelse i øvre venstre hjørne av XmBulletinBoard-klasseobjektvinduet.

Når objektet endres størrelse, for eksempel med musen, endres ikke startposisjonen til underobjektene, eller de beveger seg for å unngå kryss. Hvis widgetvinduet blir mindre, kan deler av underobjektene bli usynlige.

XmBulletinBoard-klassen inneholder:

XmForm. Et særtrekk ved objekter i denne klassen (skjemaer) er muligheten til å kontrollere plasseringen av underobjektene deres ved å spesifisere koblinger både mellom selve skjemaet og den underordnede widgeten, og mellom underobjektene i seg selv.

For hver underordnede widget kan du spesifisere hvor dens venstre, høyre, bunn eller øvre kant er forankret. Så hvis du fester venstre og høyre kant av underobjektet til høyre kant av skjemaet, vil avstanden fra dem til denne kanten alltid forbli den samme. Hvis størrelsen på formen reduseres, vil underobjektet flyttes til venstre, og hvis størrelsen økes, flyttes det til høyre. Du kan binde ett underobjekt til et annet. Deretter endrer du posisjonen til underobjektet som widgeten er festet til, vil det forankrede objektet bevege seg slik at avstanden mellom dem bevares.

Når du endrer størrelse på et skjema, bevares alle forbindelser mellom underobjektene.

XmSelectionBox. Objekter av denne klassen ("select boxes") representerer et eksempel på en sammensatt widget og inkluderer en rulleliste der brukeren kan velge elementet han vil ha, samt et tekstfelt (XmTextField-objekt) der det valgte elementet i listen er vises. Brukeren kan redigere valget som er gjort. Listen og tekstboksen kan ha annoteringsetiketter satt ved å bruke den riktige widgeten til XmLabel-klassen. XmSelectionBox inkluderer også tre trykknapper (XmPushButton-objekter). Som standard er de merket "Ok", "Avbryt" og "Hjelp". Og til slutt er det ett element til - en klikkbar knapp, som som standard heter "Bruk". Dette underobjektet er opprinnelig opprettet, men er ikke inkludert i listen over administrerte widgets.

Ved hjelp av valgblokken kan brukeren spesifisere ønsket delstreng i listen eller legge den inn i tekstfeltet. Innstillingene bekreftes ved å trykke på "Ok"-knappen.

XmSelectionBox-klassen inkluderer:

XmCommand. Objekter i denne klassen gir brukeren muligheten til å velge ønsket kommando ved å bruke listen over kommandoer som allerede er lagt inn, eller ved å skrive inn kommandoen i tekstfeltet spesielt for dette i widgeten.

XmFileSelection. Objekter i denne klassen lar deg se gjeldende innhold i forskjellige kataloger og velge en bestemt fil.

Objekter i denne klassen inneholder elementer:

* 2 tekstfelt: "Filter" og "Selection" (objekter i klassen XmNextField);

* 2 lister: "Kataloger" og "Filer" (objekter i XmList-klassen);

* 4 trykknapper: "Ok", "Filter", "Avbryt" og "Hjelp" (objekter i klassen XmPushButton);

Tekstfeltet "Filter" spesifiserer en maske (mal) for å velge et bestemt delsett fra hele settet med filer som tilfredsstiller betingelsen som er spesifisert i dette feltet - som samsvarer med malen - det er denne undergruppen som vises i "Filer"-listen. Kataloglisten viser underkatalogene til gjeldende katalog. Tekstboksen "Utvalg" viser filen (navnet) valgt i "Filer"-listen, og i samme tekstboks kan brukeren skrive inn hele navnet på filen han trenger manuelt. De fire trykknappene brukes til å utføre ulike handlinger:

Ok - velg den angitte filen;

Filter - oppdatering av listen over filer som vises i tekstboksen "Filer" i samsvar med gjeldende maske;

Avbryt - lukker widgetvinduet, filen er ikke valgt;

Hjelp - et rop om hjelp.

XmMessageBox. Objekter i denne klassen er designet for å vise meldinger til brukeren som vises under programmets drift. Denne widgeten er sammensatt. Den har et område der en tekstlinje (melding) vises og et spesielt ikon som karakteriserer meldingstypen. I tillegg har objektet tre klikkbare knapper. Som standard er de merket "Ok", "Avbryt" og "Hjelp".

XmDrawingArea. Objekter i denne klassen gir programmet et vindu for å tegne og vise informasjon. Klassen i seg selv gir ikke parametere som kan brukes direkte på visningsgrafikk. Men listene over tilbakeringingsprosedyrer som er tilgjengelige i denne klassen lar deg motta varsler om behovet for å tegne widgetvinduet på nytt og om mottak av inputfokus.

XmFrame. Objekter i denne klassen brukes til å skille noen objekter fra andre ved å omslutte dem med en ramme. Det særegne med widgeten til denne klassen er at de bare kan ha og administrere ett underobjekt.

XmPanedWindow. Objekter i denne klassen kan kombinere forskjellige widgets. Underobjektene er skilt fra hverandre, og et spesielt element er plassert mellom dem, som kalles ramme. Det ser ut som en liten firkant og brukes til å endre størrelsen på underordnede widgets. Så hvis et objekt i XmPanedWindow-klassen har to underobjekter, kan du gjøre følgende: "kroke" rammen med musen og "dra" den i ønsket retning (ned-opp eller venstre-høyre) - mens langsgående størrelse (størrelsen langs den retningen som "dratt bort" rammen) av det ene barneobjektet vil vokse "på bekostning" av det andre (størrelsen på det andre vil avta), de tverrgående dimensjonene til begge underobjektene vil bli bevart. Den "tverrgående" størrelsen til et objekt i XmPanedWindow-klassen bestemmes av den maksimale tilsvarende størrelsen på dets underobjekter.

XmRowColumn. Objekter i denne klassen kan kombinere forskjellige widgets. Delobjektene er ordnet i en bestemt rekkefølge - i form av en matrise. Widgeten til XmRowColumn-klassen er grunnlaget for å lage følgende objekter:

avkrysningsboks - "boks med kontrollerbare knapper" (dvs. objekter av XmToggleButton-klassen eller XmToggleButtonGadget-klassen); blant knappene tilgjengelig i "blokken" kan flere velges ("på") samtidig;

radioboks - "blokk med radioknapper" (dvs. XmToggleButton- eller XmToggleButtonGadget-objekter); blant knappene som er tilgjengelige i "blokken", kan bare én velges ("på") samtidig;

rullegardinmeny - "rullegardinmeny" - et undermenyvindu som vises etter å ha valgt en knapp i menyen på øverste nivå (menylinjen); menyelementer er arrangert vertikalt;

alternativmeny - en knapp med tilhørende meny; når knappen trykkes, vises et menyvindu, hvor en parameterverdi er valgt; menyelementer er arrangert vertikalt;

popup-meny - "popup-meny", som som regel startes ved å klikke på den tredje museknappen; et menyvindu vises på stedet der markøren er plassert; menyelementer er arrangert vertikalt;

menylinje - en meny på øverste nivå som inneholder en rekke knapper (objekter fra XmCascadeButton- eller XmCascadeButtonGadget-klassen) som brukes til å kalle opp forskjellige undermenyer (rullegardinmeny); menyelementer er ordnet horisontalt.

XmScale. Et objekt i denne klassen er et rektangulært område som inneholder en låseglidebryter, som brukeren kan bruke til å velge verdien til parameteren knyttet til objektet fra det spesifiserte området.

XmScrolledWindow. Objektet for denne klassen gir muligheten til å vise og vise noe informasjon (tekst, bilde, liste). En slik widget inneholder som regel et underobjekt der dataene beregnet for visning er plassert (dette kan være et objekt av XmText-klassen, XmDrawingArea, etc.) For mer praktisk visning av dataene, bla horisontalt og vertikalt stenger kan brukes.

Denne klassen inneholder en underklasse

XmMainWindow. Objekter i denne klassen representerer en separat komponent i grensesnittet, vanligvis bestående av følgende deler:

* meny på øverste nivå,

* kommandovindu,

* "Arbeidsområde,

* meldingsboks,

* og to rullefelt (horisontalt og vertikalt).

Underobjekter kan skilles med skilletegn.

Klassene XmMenuShell og XmDialogShell. Motif gir XmMenuShell-objektklassen for å lage forskjellige menyer. Denne klassen arver fra OverrideShell-klassen (fra Xt).

Som nevnt i beskrivelsen av Xt, brukes TransientShell-klassen til å lage programobjekter som på den ene siden kontakter vindusbehandleren direkte, og på den andre siden har funksjoner som skiller dem fra vanlige toppnivåvinduer. Den viktigste er at widgeten til TransientShell-klassen ikke kan minimeres. Men de fjernes fra skjermen hvis forelderen blir til et ikon. Denne typen widget brukes vanligvis til å lage hjelpevinduer for et program.

Motif tar de spesifiserte egenskapene fra TransientShell-klassen og utvider dem til en XmDialogShell-avledet klasse. Sistnevnte fungerer som et skalldialogobjekt.

Strukturen til en dialogboks i Motif kan representeres som følger:

XmDialogShell klasseobjekt

En objektunderklasse av XmManager, for eksempel XmBulletinBoard eller XmForm

Ulike kontroller: knapper, tekstinntastingsfelt, etc.

Biblioteket har et sett med prosedyrer for å lette opprettelsen av den beskrevne konstruksjonen.

Dialoger

Som nevnt er konstruksjonen av en dialogboks i Motif som følger: først er det et objekt av XmDialogShell-klassen, som deretter inkluderer widgeten til en av underklassene til XmManager-klassen, dette objektet brukes til å plassere forskjellige objekter.

Biblioteket har spesielle prosedyrer for å lage dialoger. De er forskjellige i typen widget, som er et barn av et objekt i XmDialogShell-klassen.

Tekstutgang

Biblioteket har et ganske stort antall widgets som brukes til å vise tekstinformasjon. Dette er XmLabel med underklasser, XmText m.fl. XmNfontlist-ressursen brukes til å spesifisere mulige fonter som kan brukes ved tegning av strenger. Det er av typen XmFontlist. Dens betydning er et sett med "font" / "font tag"-par.

Tagger (tags) er ment å gjøre programmer uavhengige av spesifikke fonter, spesifisert av brukeren. Dette gjøres på følgende måte: applikasjonen er laget på en slik måte at i alle funksjoner som fungerer med tekstlinjer, er ikke selve skriftene til stede, men etikettene deres. Når oppgaven er kompilert og startet, bestemmes samsvaret mellom tagger og spesifikke fonter. Sistnevnte brukes til tegning.

Motif har fasiliteter ikke bare for å jobbe med tekststrenger som vises i en enkelt font, men lar deg også jobbe med objekter som "sammensatte strenger" - dvs. tekstlinjer som bruker mange fonter. Det er et sett med verktøy for å lage slike strenger, jobbe med dem og konvertere dem til vanlige strenger med "enkeltskrift".

Arbeid med bilder

Motif selv jobber med bilder ved å representere dem i et internt format, som er en enkel bitmap, som spesifiseres ved hjelp av XImage-strukturen.

Fokuskontroll

Motiv støtter to modeller for å overføre inputfokus. Den første er implisitt (peker): fokus gis til widgeten som musepekeren flyttes til. Den andre modellen er eksplisitt: for å overføre fokus, plasser musepekeren i widgetvinduet og trykk på venstre museknapp. Når en widget eller gadget mottar input-fokus, er dens kant uthevet.

I tillegg til disse modellene for overføring og mottak av inputfokus, er det også en mekanisme for å overføre inputfokus fra en widget til en annen. Objekter kan kombineres i grupper - dette kan gjøres ved å angi de nødvendige verdiene for de tilsvarende ressursene, eller det kan overlates til systemet. I sistnevnte tilfelle binder Motif automatisk widgeten ved å bruke innebygde regler. For eksempel inneholder et objekt i XmMessageBox-klassen tre grupper: den ene er "hoved"-dialogobjektet (XmForm-klassen), den andre er "etiketten" der meldingen presenteres for brukeren, og den tredje er knappene for å bli presset.

Inndatafokuset overføres både fra ett objekt (i en gruppe) til et annet, og fra en gruppe til en gruppe.

Fokus overføres innenfor en gruppe ved hjelp av piltastene, og fra gruppe til gruppe ved hjelp av tabulatortasten (det er derfor selve gruppene kalles Tab -grupper). Når fokus overføres til en gruppe, overføres inngangsfokuset i den til det første objektet som kan motta fokus (objektet kan forhindres i å motta fokus ved å angi riktig verdi for den tilsvarende ressursen). Rekkefølgen som fokus sendes i i en gruppe er den samme som rekkefølgen dens widgeter opprettes i. Når du gjør det, flytter tastekombinasjonen vanligvis fokus i motsatt retning.

Motiv gir også en rekke prosedyrer som du kan bruke for å kontrollere inputfokus.

Lesstif Ganske nylig har en freeware-analog av Motif blitt utgitt, fullt kompatibel med den. Den heter Lesstif. Den kan fritt skaffes i kildekode og kompileres for ulike plattformer på Internett.

Tk / tcl

Tcl - Les: - står for "verktøykommandospråk". Består av to deler: selve språket og biblioteket.

Tcl-språket har en enkel syntaks og er lett å programmere. I sin opprinnelige form er tcl en tolk. Lar deg lage nye konstruksjoner som funksjoner eller programmer, noe som gir en dyktig programmerer et kraftig verktøy for å utvikle ikke bare endelige applikasjoner, men også sin egen utvidelse av tcl-språket, skape og vedlikeholde sin egen stil.

tcl-biblioteket gir muligheten til å bruke tcl-tolker i applikasjonsprogrammer, og inkluderer derfor skript skrevet på tcl-kommandospråket i programmer. Biblioteket inneholder en leksikalsk analysator av tcl-språket, funksjoner som implementerer innebygde tcl-kommandoer, og lar deg knytte tilpassede subrutiner (funksjonskall) til tcl-kommandoer. Denne ordningen er mulig for både C og C++.

Tk er et Motif-kompatibelt verktøysett for å utvikle grafiske brukergrensesnitt i X Window-miljøet. I tillegg til standard C- og C++-grensesnitt, inkluderer det et tcl-grensesnitt, som gjør det mulig å bruke Tk-fasiliteter fra tcl-skallet. Dette betyr at i tillegg til standard programmering i C og C++, kan grensesnittdelene av applikasjonen implementeres i form av skript i tcl-språket og disse grensesnittdelene (dialoger, skjermoppsett osv.) kan redigeres dynamisk , under driften av det endelige programmet, ved å bruke tcl-kommandoer.

"Ønske"-vindusmiljøet lar deg lage GUI-applikasjoner med kun tcl-språket.

Lignende dokumenter

Programmeringssystemer og deres grafiske muligheter. Utvikling av et multimediekurs, som bidrar til effektiv assimilering av elever på grunnskolen av emnet "Grafiske evner til programmeringsspråket" (på eksemplet med programmeringsspråkene Basic og Pascal).

avhandling, lagt til 29.12.2010


Grafiske visningskomponenter, systemobjekter og funksjoner. Systemet for interaksjonsmidler mellom brukeren og enheten. Historie om grafiske brukergrensesnitt til personlige datamaskiner, deres klassifisering. X Window System.

presentasjon lagt til 22.05.2012


Programmering og grunnleggende grafikkfunksjoner. Grunnleggende strukturer for visningen og to konstruktører med argumenter. Ytterligere koordinater for punktet og initialisering av en ny. Lagre og endre koordinatene til det øvre venstre hjørnet av rektangelet.

laboratoriearbeid, lagt til 12.01.2011


Vektor datagrafikk. Grafiske primitiver. Grafiske evner til programmeringsspråket Pascal. Metodiske anbefalinger for å studere grafikk i programmeringsspråket Pascal. Plotte funksjoner.

semesteroppgave, lagt til 13.06.2007


Utvikling av et program for Windows-operativsystemet ved hjelp av VisualC ++ (6.0, .NET). Betraktning av det grunnleggende om programvaremodellering av driften av enheten (vannkoker). Regler for å lage klasser av enheten og dens grafiske grensesnitt.

semesteroppgave, lagt til 06.03.2014


Data-grafikk. Presentasjon av grafisk informasjon i en datamaskin. Grafiske formater. Grafisk redaktør. Vektorgrafikk. CorelDraw. Kjennetegn ved programmet, grensesnitt. Teknologiske muligheter og bruk av CorelDraw-programmet.

semesteroppgave, lagt til 19.05.2007


Rollen til distribuerte datasystemer i å løse moderne problemer. Instrumentsystem DVM for utvikling av parallelle programmer. Verktøy for å bygge en formell modell av et grafisk grensesnitt. Krav til det grafiske grensesnittet til DVM-systemet.

semesteroppgave, lagt til 15.10.2010


Essensen av programmering ved hjelp av Delphi 7-miljøet og dets grunnleggende grafiske muligheter. Strukturen til en autonomt kompilert programmodul og dens prinsipper. Grunnleggende teknikker for å arbeide med grafiske prosedyrer, bygge en bue, sirkel og ellipse.

semesteroppgave, lagt til 16.12.2011


Bruksområder for datagrafikk. Typer datagrafikk. Fargeoppløsning og fargemodeller. Programvare for å lage, vise og behandle grafisk informasjon. Grafiske evner til tekstbehandlere, grafiske redaktører.

test, lagt til 06.07.2010


Utviklingen av grafiske brukergrensesnitt. X Window System Device and Window Managers. Beskrivelse av KDE- og GNOME-skrivebordet og applikasjonene. En oversikt over de grunnleggende prinsippene for å organisere grensesnittet i Windows-systemet, en beskrivelse av pakken med applikasjonsprogrammene.