NO332643B1 - Programmeringsgrensesnitt for en datamaskinplattform - Google Patents

Abstract

Et programmeringsgrensesnitt tilveiebringer funksjoner for å frembringe applikasjoner, dokumenter, mediapresentasjoner og annet innhold. Disse funksjonene gjør det mulig for utviklere å oppnå tjenester fra et operativsystem, en objektmodell-tjeneste eller andre systemer eller tjenester.

Description

Foreliggende oppfinnelse vedrører programvare, samt utvikling av denne programvaren. Mer spesifikt vedrører oppfinnelsen et programmeringsgrensesnitt som letter bruk av en programvarebasert plattform for brukerprogramvare og maskinvare i datamaskiner.

Vedlagt denne spesifikasjonen er et sett bestående av tre CD-plater som inneholder et programutviklingssett (SDK - Software Development Kit) for Microsoft<®>Windows<®>sitt operativsystem med kodenavn "Longhorn". Programutviklingssettet inneholder dokumentasjon for nevnte Microsoft<®>Windows<®>operativsystem med kodenavn "Longhorn". En kopi av hver av disse tre CD-platene er også vedlagt denne spesifikasjonen.

Den første CD-platen i settet av tre CD-plater (CD 1 av 3) omfatter en filmappe med navn "Ihsdk" opprettet 22. oktober 2003; den er 586 megabyte stor, inneholder 9692 undermapper og inneholder 44292 filer. Den andre CD-platen i settet av tre CD-plater (CD 2 av 3) omfatter en filmappe med navn "ns" opprettet 22. oktober 2003; den er 605 megabyte stor, inneholder 12628 undermapper og inneholder 44934 filer. Den tredje CD-platen i settet av tre CD-plater (CD 3 av 3) omfatter en filmappe med navn "ns" opprettet 22. oktober 2003; den er 575 megabyte stor, inneholder 9881 undermapper og inneholder 43630 filer. Filene på hver av disse tre CD-platene kan kjøres/åpnes på en Windows<®->basertdatabehandlingsanordning (f.eks. en IBM-PC eller tilsvarende) som kjører et operativsystem fra Windows<®>(f.eks. Windows<®>NT, Windows<®>98, Windows<®>2000, Windows<®>XP, osv.). Filene på hver CD-plate i dette settet av tre CD-plater inntas med dette som referanse her.

Hver CD-plate i settet av tre CD-plater er av typen CD-R, og følger standarden ISO 9660. Innholdet i hver CD-plate i settet av tre CD-plater er i overensstemmelse med ASCII-(American Standard Code for Information lnterchange)-standarden.

Fra tidlig av har programvare for datamaskiner vært kategorisert som enten "operativsystem-programvare" eller "brukerprogramvare'7applikasjons-programmer. Generelt beskrevet er et brukerprogram eller en applikasjon programvare som er ment for å utføre en spesifikk oppgave for brukeren av en datamaskin, for eksempel å løse en matematisk likning eller å lette tekstbehandling. Operativsystemet er programvaren som administrerer og styrer maskinvaren i datamaskinen. Formålet med operativsystemet er å gjøre datamaskinens ressurser tilgjengelige for applikasjonsprogrammerere mens det samtidig skjuler kompleksiteten som er nødvendig for å kunne styre maskinvaren.

Operativsystemet gjør ressursene tilgjengelige gjennom funksjoner som kollektivt betegnes et API (Application Program Interface). Betegnelsen API benyttes også for å referere til én enkelt av disse funksjonene. Funksjonene blir ofte gruppert etter hvilken ressurs eller tjeneste de tilbyr til applikasjonsprogrammereren. Brukerprogramvare ber om ressurser ved å anrope individuelle API-funksjoner. API-funksjoner anvendes også for å formidle meldinger og informasjon frembragt av operativsystemet tilbake til bruker-programmene.

I tillegg til endringer i maskinvaren, er en annen faktor som har drevet utviklingen av operativsystem-programvare ønsket om å gjøre utviklingen av brukerprogramvare enklere og raskere. Utvikling av brukerprogramvare kan være en vanskelig oppgave, og i enkelte tilfeller kreves flere års utviklingstid for å frembringe et avansert program som omfatter millioner av kodelinjer. For et populært operativsystem, så som forskjellige versjoner av operativsystemet Microsoft Windows<®>, skriver utviklere av brukerprogramvare tusenvis av forskjellige applikasjoner hvert år som benytter operativsystemet. En logisk konsekvent og brukervennlig operativsystemplattform er nødvendig for å under-holde så mange ulike applikasjonsutviklere.

Ofte kan utviklingen av brukerprogramvare gjøres enklere ved å gjøre operativsystemet mer komplekst. Nærmere bestemt, dersom en funksjon kan være nyttig for flere forskjellige applikasjonsprogrammer, kan det være bedre å skrive den én gang og innlemme den i operativsystemet enn å kreve at mange programvareutviklere skriver den mange ganger og innlemmer den i forskjellige applikasjoner. På denne måten, dersom operativsystemet tilbyr et stort utvalg av vanlig funksjonalitet som et antall applikasjoner trenger, kan det oppnås betydelige kostnadsmessige og tidsmessige besparelser i forbindelse med utvikling av brukerprogramvare.

Uavhengig av hvor skillet mellom operativsystem-programvare og brukerprogramvare trekkes, er det klart at i et formålstjenlig operativsystem, API-et mellom operativsystemet på den ene siden og maskinvaren i datamaskinen og brukerprogramvaren på den andre siden er like viktig som at den interne operasjonen til operativsystemet selv er effektiv.

Når de utvikler applikasjoner, anvender utviklere en rekke forskjellige verktøy for å generere grafiske elementer og annet innhold. Ytterligere verktøy er tilgjengelige for å anordne grafiske elementer og andre data som skal vises eller rendres. Disse verktøyene er typisk tilveiebragt av forskjellige entiteter eller forskjellige verktøyutviklere. Som følge av dette tilveiebringer ikke verktøyene et ensartet programmeringsmiljø. En utvikler som anvender disse forskjellige verktøyene er således nødt til å lære seg hvordan å anvende hvert av verktøyene og forsøke å få dem til å kommunisere med hverandre. Disse aktivitetene kan være kjedelige og tidkrevende, og stjeler tid fra den utviklingsjobben som skal gjøres.

Gjennom de senere år har den alminnelige utbredelsen av Internett, og nettverks-teknologi generelt, endret rammebetingelsene for utviklere av programvare til datamaskiner. Tradisjonelt fokuserte programvareutviklere på stedsbundne (single-site) programapplikasjoner for alenestående "desktop"-datamaskiner, eller LAN-baserte datamaskiner som sto i forbindelse med et begrenset antall andre datamaskiner via et lokalt nettverk (LAN). Slike programapplikasjoner ble typisk referert til som "krympe-pakkede" produkter fordi programvaren ble markedsført og solgt i krympepakket emballasje. Applikasjonene anvendte veldefinerte API'er for å aksessere datamaskinens underliggende operativsystem.

Etter hvert som Internett vokste frem og ble allment akseptert, begynte industrien å innse styrken i det å ha applikasjoner kjørende på forskjellige nettsteder i verdensveven (World Wide web, eller bare "web'en"). I den nettverkstilknyttede verdenen kunne klienter fra hvor som helst sende inn forespørsler til server- eller tjener-baserte applikasjoner på forskjellige nettsteder og motta svar i løpet av brøkdeler av et sekund. Disse web-applikasjonene var imidlertid typisk utviklet på den samme operativsystem-plattformen som opprinnelig var utviklet for alene-stående databehandlingsmaskiner eller lokalt nettverks-tilsluttede datamaskiner. I enkelte tilfeller fungerer dessverre ikke disse applikasjonene på en tilfredsstillende måte i det distribuerte databehandlingsmiljøet. Den underliggende plattformen var ganske enkelt ikke konstruert med tanke på å støtte et ubegrenset antall sammenkoplede datamaskiner.

For å imøtekomme dreiningen mot det distribuerte databehandlingsmiljøet som fremtvinges av Internett har Microsoft Corporation utviklet en plattform for implementasjon av nettverksprogramvare kjent som ".NET"-rammeverket (leses "Dot Nett"). Microsoft® .NET er programvare for å kople sammen mennesker, informasjon, systemer og anordninger. Plattformen gjør det mulig for utviklere å tilveiebringe web-tjenester som skal kjøre over Internett. Denne dynamiske dreiningen ledsages av et sett av API-funksjoner for Microsoft sitt .NET™-rammeverk.

Etter hvert som bruken av .NET™-rammeverket har blitt mer utbredt, har det blitt identifisert måter å bedre plattformens effektivitet og/eller ytelse. Oppfinnerne har utviklet et unikt sett av API-funksjoner for å realisere denne bedrede effektiviteten og/eller ytelsen.

US 2003/028685 A1 vedrører et programmeringsgrensesnitt for en nettverks-programvareplattform.

Et formål med denne oppfinnelsen er å sørge for et programmeringsgrensesnitt, slik som en API, som muliggjør frembringelse av funksjoner for generering av applikasjoner/programmer, dokumenter, mediapresentasjoner og annet innhold. Dette formålet er løst ved oppfinnelsen ifølge de selvstendige krav. Ytterligere utførelser av oppfinnelsen er angitt i de uselvstendige krav. Disse funksjonene gjør det mulig for utviklere å oppnå tjenester fra et operativsystem, en objektmodell-tjeneste eller andre systemer eller tjenester. I en utførelsesform gjør funksjonene det mulig for en utvikler å generere et grafisk brukergrensesnitt.

Samme referansenummer er brukt i alle figurene til å referere til like trekk.

Figur 1 illustrerer en nettverksarkitektur der klienter aksesserer web-tjenester over Internett ved anvendelse av konvensjonelle protokoller. Figur 2 er et blokkdiagram som illustrerer en programvarearkitektur for en nettverksplattform, som omfatter et applikasjonsprogrammeringsgrensesnitt (API). Figur 3 er et blokkdiagram som illustrerer delsystemet for presentasjon som støttes av nevnte API, så vel som funksjonsklasser i de forskjellige API-funksjonene. Figur 4 er et blokkdiagram som illustrerer et eksempel på datamaskin som kan kjøre hele eller en del av programvarearkitekturen. Figurene 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 og 16 illustrerer forskjellige eksempler på utførelse av et programmeringsgrensesnitt.

Denne redegjørelsen beskriver et API for en nettverksplattform som utviklere kan bygge web-applikasjoner og -tjenester basert på. Mer spesifikt beskrives et eksempel på API for operativsystemer som anvender en nettverksplattform, så som .NET™-rammeverket tilveiebragt av Microsoft Corporation. Rammeverket .NET™ er en programvare-plattform for web-tjenester og web-applikasjoner til bruk i det distribuerte databehandlingsmiljøet. Det representerer neste generasjon Internett-basert databehandling, og anvender åpne kommunikasjonsstandarder for kommunikasjon mellom løst koplede web-tjenester som samarbeider for å utføre en gitt oppgave.

I den beskrevne utførelsen anvender nettverksplattformen XML-(eXtensible Markup Language), en åpen standard for å beskrive data. XML administreres av W3C (World Wide web Consortium). XML anvendes for å definere dataelementer på en nett-side og "business-til-business"-dokumenter. XML har en tilsvarende formatetikett-basert oppbygning som HTML; men mens HTML definerer hvordan elementer vises, definerer XML hva disse elementene inneholder. Videre anvender HTML forhåndsdefinerte formatetiketter, mens XML tillater utvikleren av en side å definere nye formatetiketter. På denne måten kan praktisk talt hvilke som helst dataelementer bli identifisert, slik at nettsider kan fungere som poster i en database. Gjennom anvendelse av XML og andre åpne protokoller, så som SOAP (Simple Object Access Protocol), muliggjør nettverksplattformen integrasjon av et bredt spekter av tjenester som kan være skreddersydd til brukerens behov. Selv om utførelsesformene beskrevet her er beskrevet i forbindelse med XML og andre åpne standarder, er ikke disse nødvendige for praktisering av den krevede oppfinnelsen. Andre like anvendelige teknologier vil kunne brukes til å realisere oppfinnelsene beskrevet her.

Som den anvendes her, omfatter betegnelsen applikasjonsprogrammeringsgrensesnitt eller API tradisjonelle grensesnitt som anvender metode- eller funksjonsanrop, så vel som fjern-anrop (f.eks. en proxy, stubb-relasjon) og SOAP/XML-baserte påkallinger.

Man må forstå at i noen av de nedenfor gitte beskrivelsene av navnerom, beskrivelser av enkelte klasser, grensesnitt (Interfaces), "enum"-lister (enumerations) og delegater er utelatt med hensikt. Mer fullstendige beskrivelser av disse klassene, grensesnittene, listene og delegatene kan finnes i CD-platene som inneholder programutviklingssettet det er henvist til ovenfor.

EKSEMPEL PA NETTVERKSMILJØ

Figur 1 illustrerer et nettverksmiljø 100 der en nettverksplattform, som for eksempel .NET™-rammeverket, kan bli implementert. Nettverksmiljøet 100 omfatter representative web-tjenester 102(1) ..., 102(N) som tilbyr tjenester for aksess over et nettverk 104 (f.eks. Internett). Web-tjenestene, generelt referert til med referansenummer 102, er programmerbare applikasjonskomponenter som er gjenbrukelige og som sam-handler programmatisk over nettverket 104, typisk over standard web-protokoller så som XML, SOAP, WAP (Wireless Application Protocol), HTTP (HyperText Transport Protocol) og SMTP (Simple Mail Transfer Protocol), selv om andre mekanismer for å vekselvirke med web-tjenestene over nettverket også er mulige, så som RPC (Remote Procedure Cali) eller objektoverføring-type teknologi. En web-tjeneste kan være selvbeskrivende og er ofte definert i form av formater for og ordning av meldinger.

Web-tjenestene 102 kan aksesseres direkte av andre tjenester (som angitt av en kommunikasjonsforbindelse 106) eller en programapplikasjon, så som en web- applikasjon 110 (som angitt av kommunikasjonsforbindelsene 112 og 114). Hver web-tjeneste 102 er illustrert som omfattende én eller flere tjenermaskiner som kjører programvare for å behandle forespørseler om spesifiserte tjenester. Slike tjenester opprettholder ofte databaser som lagrer informasjon som for formidling til de som ber om det. Web-tjenestene kan være innrettet for å utføre en hvilken som helst av en rekke forskjellige tjenester. Eksempler på web-tjenester omfatter verifikasjon ved innlogging, varsling, lagring i database, lagerføring, lagringsmapper, avbildning, musikk, elektroniske lommebøker, kalendere/planleggere, telefonlister, nyheter og informasjon, spill, billettjenester og annet. Web-tjenestene kan kombineres med hverandre og med andre applikasjoner for å bygge intelligente, interaktive opplevelser eller hendelser.

Nettverksmiljøet 100 omfatter også representative klientanordninger 120(1), 120(2), 120(3), 120(4) ..., 120(M) som anvender web-tjenestene 102 (som angitt av kommunikasjonsforbindelsen 122) og/eller web-applikasjonen 110 (som angitt av kommunikasjonsforbindelsene 124, 126 og 128). Klientene kan i tillegg kommunisere med hverandre ved anvendelse av standard protokoller, som angitt av en eksempelvis XML-basert forbindelse 130 mellom klientene 120(3) og 120(4).

Klientanordningene, referert til generelt med referansenummer 120, kan være realisert på mange mulige måter. Eksempler på mulige klientmaskiner omfatter, uten begrensning, flyttbare datamaskiner, stasjonære datamaskiner, digitaliseringsbord, fjernsyn/"set-top"-bokser, trådløse kommunikasjonsanordninger, personlige digitale assistenter, spillkonsoller, skrivere, fotokopieringsmaskiner og andre anordninger.

Web-applikasjonen 110 representerer en applikasjon som er innrettet for å kjøre på nettverksplattformen, og kan anvende web-tjenestene 102 når den mottar og betjener forespørseler fra klienter 120. Web-applikasjonen 110 utgjøres av én eller flere programapplikasjoner 130 som kjører oppå et programmeringsrammeverk 132 på én eller flere tjenere 134 eller andre datasystemer. Merk at en del av web-applikasjonen 110 vil kunne befinne seg på én eller flere av klientene 120. Alternativt kan web-applikasjonen 110 samhandle med annen programvare på klientmaskiner 120 for å utføre sine oppgaver.

Programmeringsrammeverket 132 er strukturen som underholder applikasjonene og tjenestene som utvikles av applikasjonsutviklere. Det muliggjør utvikling med bruk av flere programmeringsspråk samt sømløs integrasjon ved å støtte flere programmeringsspråk. Det støtter åpne protokoller så som SOAP, og kapsler inn det underliggende operativsystemet og objektmodell-tjenester. Rammeverket tilveiebringer et robust og sikkert kjøremiljø for de flere programmeringsspråkene, og tilbyr sikre, integrerte klasse-biblioteker.

Rammeverket 132 er en flerlagsarkitektur som omfatter et API-lag 142, et CLR-(Common Language Runtime)-lag 144 og et operativsystem-/tjenestelag 146. Denne lagdelte arkitekturen gjør det mulig å oppdatere og modifisere forskjellige lag uten at andre deler av rammeverket påvirkes. En CLS-(Common Language Specification)-spesifikasjon 140 lar utviklere som anvender forskjellige språk skrive kode som kan aksessere underliggende bibliotekfunksjonalitet. Spesifikasjonen 140 fungerer som en kontrakt mellom programutviklere og bibliotekutviklere som kan anvendes for å øke samspillsevnen mellom programmeringsspråk. Ved at man holder seg til CLS-spesifikasjonen kan biblioteker skrevet i ett språk gjøres direkte tilgjengelige for kodemoduler skrevet i andre språk, slik at det oppnås sømløs integrasjon av kodemoduler skrevet i forskjellige programmeringsspråk. Ett detaljert eksempel på mulig utførelse av en CLS-spesifikasjon er beskrevet i en ECMA-standard utviklet av medlemmer av ECMA TC39/TG3. Leseren henvises til ECMA sitt nettsted www.ecma.ch.

API-laget 142 presenterer grupper av funksjoner som applikasjonene 130 kan anrope for å aksessere ressursene og tjenestene som tilbys av laget 146. Ved at API-funksjonene tilgjengeliggjøres for en nettverksplattform kan applikasjonsutviklere bygge web-applikasjoner for distribuerte databehandlingssystemer som fullt ut utnytter nettverksressursene og andre web-tjenester, uten å måtte forstå de kompliserte detaljene ved hvordan disse nettverksressursene faktisk fungerer eller gjøres tilgjengelige. Dessuten kan web-applikasjonene skrives i et hvilket som helst antall programmeringsspråk og oversettes til et mellomspråk som støttes av CLR-laget 144 og som er innlemmet som del av CLS-spesifikasjonen 140. På denne måten kan API-laget 142 tilgjengeliggjøre metoder for et bredt og mangfoldig utvalg av applikasjoner/anvendelser.

I tillegg kan rammeverket 132 være konstruert for å støtte API-anrop fra fjerne applikasjoner som kjører på andre anordninger enn de tjeneranordningene 134 som er vert for rammeverket. Representative applikasjoner 148(1) og 148(2), som henholdsvis befinner seg i klientanordningene 120(3) og 120(M), kan anvende API-funksjonene ved å gjøre direkte eller indirekte anrop til API-laget 142 over nettverket 104.

Rammeverket kan også være implementert ved klientanordningene. Klient-anordningen 120(3) representerer tilfellet der et rammeverk 150 er implementert hos klienten. Dette rammeverket kan være identisk med det tjener-baserte rammeverket 132 eller være modifisert for klientoppgaver. Alternativt kan det klient-baserte rammeverket gjøres mer kompakt dersom klienten er en anordning med begrenset eller dedisert funksjonalitet, så som en mobiltelefon, en personlig digital assistent, en håndholdt datamaskin eller andre kommunikasjons-/databehandlingsanordninger.

Pro<g>rammerin<g>srammeverk for utviklere

Figur 2 viser programmeringsrammeverket 132 mer i detalj. CLS-spesifikasjons-laget 140 støtter applikasjoner 130(1), 130(2), 130(3), 130(4) ..., 130(K) skrevet i en rekke forskjellige programmeringsspråk. Slike programmeringsspråk omfatter Visual Basic, C++, C#, COBOL, Jscript, Perl, Eiffel, Python og annet. CLS-spesifikasjonen 140 spesifiserer en delmengde av trekk eller regler vedrørende trekk som, dersom de følges, gjør at de forskjellige språkene kan kommunisere. For eksempel støtter enkelte språk ikke en gitt datatype (f.eks. en peker til et heltall ("int<*>")) som ellers ville kunne være støttet av CLR 144.1 dette tilfellet omfatter ikke CLS-spesifikasjonen 140 denne typen. På den annen side er datatyper som støttes av alle eller de fleste programmeringsspråk (f.eks. et array av heltall ("int[]")) innlemmet i CLS-spesifikasjonen 140, slik at bibliotekutviklere fritt kan anvende dem og være sikre på at programmeringsspråkene er i stand til å håndtere dem. Denne muligheten til å kommunisere sikrer sømløs integrasjon av kodemoduler som er skrevet i ett programmeringsspråk med kodemoduler som er skrevet i andre programmeringsspråk. Siden forskjellige programmeringsspråk er best egnet til forskjellige oppgaver, gir den sømløse integrasjonen på tvers av programmeringsspråk en utvikler mulighet til å velge et gitt programmeringsspråk for en gitt kodemodul, og denne kodemodulen kan anvendes sammen med moduler som er skrevet i andre språk. CLR-miljøet 144 muliggjør sømløs utvikling med flere programmeringsspråk, med arv på tvers av språkene, og tilveiebringer et robust og sikkert kjøremiljø for de flere programmeringsspråkene. For mer informasjon om CLS-spesifikasjonen 140 og CLR-miljøet 144 henvises leseren til de samtidig verserende patentsøknadene "Method and System for Compiling Multiple Languages", innlevert 21. juni 2000 (US 09/598,105), og "Unified Data Type System and Method", innlevert 10. juli 2000 (US 09/613,289), som inntas her som referanse.

Rammeverket 132 innkapsler operativsystem 146(1) (f.eks. et operativsystem fra Windows<®>) og objektmodell-tjenester 146(2) (f.eks. COM (Component Object Model) eller DCOM (Distributed COM)). Operativsystemet 146(1) tilveiebringer tradisjonell funksjonalitet, så som håndtering av filer, varsling, hendelsesbehandling, brukergrensesnitt (f.eks. vindusbehandling, menyer, dialoger, osv.), sikkerhet, autentisering, verifikasjon, prosesser og prosesstråder, minneadministrering og annet. Objektmodell-tjenestene 146(2) tilveiebringer grensesnitt mot andre objekter for å utføre forskjellige oppgaver. Anrop til API-laget 142 formidles til CLR-laget 144 for lokal eksekvering av operativsystemet 146(1) og/eller objektmodell-tjenestene 146(2).

API-laget 142 grupperer API-funksjoner i et antall navnerom. Et navnerom definerer hovedsaklig en samling av klasser, grensesnitt, delegater, enum-lister og strukturer, kollektivt betegnet "datatyper", som tilveiebringer et gitt sett av beslektet funksjonalitet. En klasse representerer administrerte, heap-allokerte data med referanse-basert tilordningssemantikk. En delegat er en objekt-orientert funksjonspeker. En enum-liste er en spesialisert verdibasert datatype som representerer navnede konstanter. En struktur (struct) representerer statisk allokerte data med verdibasert tilordningssemantikk. Et grensesnitt (interface) definerer en kontrakt som andre datatyper kan implementere.

Ved å anvende navnerom kan en utvikler organisere et sett av datatyper i en hierarkisk, navnebasert inndeling. Utvikleren kan opprette flere grupper fra settet av datatyper, der hver gruppe inneholder minst én datatype som tilgjengeliggjør logisk beslektet funksjonalitet. I det gitte utførelseseksempelet er API-laget 142 organisert slik at det omfatter tre rot-navnerom. Det skal bemerkes at selv om kun tre rot-navnerom er illustrert i figur 2, ytterligere rot-navnerom også vil kunne innlemmes i API-laget 142. De tre rot-navnerommene illustrert i API 142 er: et første navnerom 200 for et presentasjon-delsystem (som omfatter et navnerom 202 for et brukergrensesnitt-shell), et andre navnerom 204 for web-tjenester og et tredje navnerom 206 for et filsystem. Hver gruppe kan da være gitt et navn. For eksempel kan datatyper i presentasjonsdelsystem-navnerommet 200 kan være gitt navnet "Windows", og datatyper i filsystem-navnerommet 206 kan være gitt navnet "Storage". De navnede gruppene kan være organisert under ett enkelt "globalt" rot-navnerom for system-nivå API-funksjoner, for eksempel et overordnet navnerom "System". Ved å velge og å anvende som prefiks en toppnivå-identifikator, kan datatypene i hver gruppe enkelt bli referert til med et hierarkisk navn som omfatter den valgte toppnivå-identifikatoren prefikset foran navnet på den gruppen som inneholder den aktuelle datatypen. For eksempel kan datatyper i filsystem-navnerommet 206 bli referert til med bruk av det hierarkiske navnet "System.Storage". På denne måten blir de individuelle navnerommene 200, 204 og 206 hovedgrener fra navnerommet "System", og kan ha en betegnelse der det aktuelle navnerommet er gitt et prefiks, for eksempel "System.".

Presentasjonsdelsystem-navnerommet 200 henfører seg til programmering og utvikling av innhold. Det tilveiebringer typer som muliggjør frembringelse av applika sjoner, dokumenter, mediapresentasjoner og annet innhold. Foreksempel tilveiebringer presentasjonsdelsystem-navnerommet 200 en programmeringsmodell som gjør det mulig for utviklere å oppnå tjenester fra operativsystemet 146(1) og/eller objektmodell-tjenestene 146(2).

Navnerommet "Shell" 202 henfører seg til brukergrensesnittsfunksjonalitet. Det tilveiebringer datatyper som gjør det mulig for utviklere å bygge inn brukergrensesnittsfunksjonalitet i sine applikasjoner, og gjør det videre mulig for utviklere å utvide bruker-grensesnittsfunksjonaliteten.

Webtjenester-navnerommet 204 henfører seg til en infrastruktur for å bygge en rekke forskjellige applikasjoner, f.eks. applikasjoner så enkle som en "chatte"-applikasjon som opererer mellom to likeaktige entiteter i et intranett, og/eller så komplekse som en skalerbar web-tjeneste for millioner av brukere. Den beskrevne infrastrukturen er tjenlig meget moduloppbygget i det at man kun trenger å anvende de delene som er hensikts-messige for en gitt løsning. Infrastrukturen tilveiebringer en plattform for å bygge meldingsbaserte applikasjoner i forskjellig skala og med forskjellig kompleksitet. Infrastrukturen eller rammeverket tilveiebringer API'er for grunnleggende meldingsbehandling, sikker meldingsbehandling, pålitelig meldingsbehandling og transaksjons-basert meldingsbehandling. I utførelsesformen beskrevet nedenfor er de tilveiebragte API'en delt inn i et hierarki av navnerom på en måte som er møysommelig komponert for å balansere anvendelighet, brukervennlighet, utvidbarhet og versjonsstyringsmulighet.

Filsystem-navnerommet 206 henfører seg til lagring. Det tilveiebringer datatyper som letter lagring og fremhenting av informasjon.

I tillegg til rammeverket 132 tilveiebringes programmeringsverktøy 210 for å hjelpe brukeren til å bygge web-tjenester og/eller applikasjoner. Ett eksempel på programmeringsverktøy 210 er Visual Studio™, et sett av programmeringsverktøy levert av Microsoft Corporation som støtter flere programmeringsspråk.

Rot-navnerom for API'er

Figur 3 illustrerer en del av presentasjons-delsystemet 200 mer i detalj. I en utførelses-form identifiseres navnerommene i henhold til en hierarkisk navnekonvensjon der navne-strenger sammenkjedes med punktum imellom. For eksempel identifiseres presentasjonsdelsystem-navnerommet 200 av rot-navnet "System.Windows". Under navnerommet "System.Windows" finnes et nytt navnerom for forskjellige kontroller, identifisert som "System.Windows.Controls", som videre inneholder et nytt navnerom for primitiver

(ikke vist) kjent som "System.Windows.Controls.Primitives". Med denne navnekonven-sjonen i tankene tilveiebringer det følgende en generell oversikt over utvalgte navnerom i API-laget 142, selv om andre navnekonvensjoner kunne ha vært anvendt med samme virkning.

Som kan sees i figur 3 omfatter presentasjons-delsystemet 200 flere navnerom. Navnerommene som er vist i figur 3 representerer en konkret utførelsesform av presentasjons-delsystemet 200. Andre utførelsesformer av presentasjons-delsystemet 200 vil kunne omfatte ett eller flere ytterligere navnerom eller vil kunne utelate ett eller flere av navnerommene vist i figur 3.

Presentasjons-delsystemet 200 er rot-navnerommet for mye av presentasjons-funksjonaliteten som tilbys av API-laget 142. Et navnerom "Controls" 310 omfatter kontroller som brukes til å bygge opp en fremvisning av informasjon, så som et brukergrensesnitt, og klasser som lar en bruker samhandle med en applikasjon. Eksempler på kontroller omfatter "Button" som genererer en aktiveringsknapp på fremvisningen, "RadioButton" som genererer en alternativknapp på fremvisningen, "Menu" som genererer en meny på fremvisningen, "ToolBar" som genererer en verktøylinje på fremvisningen, "Image" som legger inn et bilde i fremvisningen og "TreeView" som genererer en hierarkisk fremvisning av informasjon.

Enkelte kontroller frembringes ved å neste og anordne flere elementer. Kontrollene følger en logisk modell som skjuler elementene som anvendes for å generere kontrollene, og med det forenkler programmeringsmodellen. Kontrollene kan innrettes og tilpasses av en utvikler eller en bruker (f.eks. ved å tilpasse utseendet og oppførselen til knapper i et brukergrensesnitt). Enkelte kontroller har adresserbare komponenter som lar en person tilpasse individuelle kontroller. I tillegg kan applikasjonsutviklere og komponentutviklere implementere underklasser av kontroll-klassene og utvide kontrollene. Kontrollene blir rendret med bruk av vektorgrafikk slik at deres størrelse kan endres i tilpasning til et gitt grensesnitt eller en ny fremvisning. Kontrollene kan anvende animasjon, for eksempel for å øke den interaktive følelsen i et brukergrensesnitt og for å vise handlinger og reaksjoner.

Navnerommet Controls 310 omfatter ett eller flere paneler, som er kontroller som avpasser og anordner sine underelementer (f.eks. nestede elementer). For eksempel anordner et panel "DockPanel" underelementer ved å plassere hvert underelement øverst, på venstre side, nederst eller på høyre side av fremvisningen, og fylle opp den gjenværende plassen med andre data. Et gitt panel kan plassere menyer og verktøylinjer øverst i fremvisningen, en statuslinje nederst i fremvisningen, en filmappe-liste på venstre side av fremvisningen og fylle resten av rommet med en liste av meldinger.

Som angitt ovenfor er System.Windows.Controls.Primitives et navnerom som omfatter et antall kontroller, som er komponenter som typisk anvendes av utviklere av kontrollene i navnerommet System.Windows.Controls og av utviklere som implementerer sine egne kontroller. Eksempler på slike komponenter omfatter "Thumb" og "RepeatButton". "ScrollBar", en annen komponent, genereres med bruk av fire "RepeatButton"-komponenter (én for "linje opp", én for "linje ned", én for "side opp" og én for "side ned") og en "Thumb"-komponent for å bringe visningen til et annet sted i dokumentet. Et annet eksempel er "ScrollViewer", en kontroll som frembringes med bruk av to "ScrollBar"-komponenter og én "ScrollArea"-komponent for å tilveiebringe et rullefelt.

Den følgende listen omfatter eksempler på klasser som eksponeres gjennom navnerommet System.Windows.Controls. Disse klassene lar en bruker samhandle for eksempel med en applikasjon gjennom forskjellige innmatings- og utmatingsmuligheter så vel som ytterligere fremvisningsfunksjonalitet.

• AccessKey - AccessKey er et FrameworkElement-element som pakker inn et datategn som angir at det skal motta "keyboard cue decorations" og angir datategnet som

et tastatur-husketegn. Som standard er dette understrekingstasten.

• Audio - Audio-element.

• Border - Tegner en kantlinje, en bakgrunn eller begge deler på eller rundt et annet element. Button - Representerer den standard aktiveringsknapp-komponenten som respon- derer til hendelsen Click. • Canvas - Definerer et felt der en bruker eksplisitt kan posisjonere underelementer med bruk av koordinater relativt Canvas-feltet. • CheckBox - En avkryssingsboks som anvendes for å gi brukeren en valgmulighet, for eksempel "true" / "false". Avkrysningsboksen lar brukeren velge fra en liste av valg-muligheter. CheckBox-baserte kontroller lar brukeren velge en kombinasjon av valg-muligheter.

CheckedChangedEventArgs - Klassen CheckedChangedEventArgs inneholder ytterligere informasjon om hendelsen CheckedChangedEvent.

CheckStateChangedEventArgs - Klassen CheckStateChangedEventArgs inneholder ytterligere informasjon om hendelsen CheckStateChangedEvent.

• ClickEventArgs - Inneholder informasjon om hendelsen Click.

• ColumnStyle - Representerer et foranderlig ColumnStyle-objekt.

• ColumnStyles - Foranderlig IList-objekt som er en samling av Changeable-elementer. ComboBox - ComboBox-kontroll.

ComboBoxltem - En kontroll som implementerer et selekterbart element innenfor en

Com boBox-kontroll.

• ContactPickerDialog - Lar en bruker velge én eller flere kontakter.

• ContactPropertyRequest - Lar en applikasjon be om informasjon om en kontakt-egenskap gjennom en ContactPickerDialog. Denne klassen kan det ikke avledes

underklasser fra.

• ContactPropertyRequestCollection - Representerer en samling av

ContactPropertyRequest-objekter.

ContactSelection - Informasjon om en valgt kontakt fra Microsoft<®>Windows<®->fil-systemet med kodenavn "WinFS" eller Microsoft Active Directory<®>.

• ContactSelectionCollection - Representerer en samling av ContactSelection-objekter. • ContactTextBox - En redigeringskontroll som støtter valg av kontakter eller kontakters egenskaper. • ContactTextBoxSelectionChangedEventArgs - Argumenter til hendelsen

ContactTextBoxSelectionChanged.

ContactTextBoxTextChangedEventArgs - Argumenter til hendelsen ContactTextBoxTextChanged. • ContactTextBoxTextResolvedEventArgs - Argumenter til hendelsen TextResolvedToContact.

• ContentChangedEventArgs - Argumentene til hendelsen ContentChangedEvent.

• ContentControl - Baseklasse for alle kontroller med ett enkelt stykke innhold.

• ContentPresenter - ContentPresenter anvendes innenfor stilen til en innholdskontroll for å angi hvor i kontrollens visuelle tre (chrome template) innholdet skal legges til. ContextMenu - En kontroll som definerer en meny av valg som brukere kan anrope. ContextMenuEventArgs - Dataene som sendes ved en ContextMenuEvent-hendelse. Control - Baseklasse for alle bruker-interaktive elementer. Denne klassen tilveie bringer et grunnleggende sett av egenskaper til sine underklasser. Decorator - Baseklasse for elementer som anvender effekter på eller rundt ett enkelt underelement, for eksempel Border. • DockPanel - Definerer et felt hvor man kan anordne underelementer enten horison-talt eller vertikalt, i forhold til hverandre. • DragDeltaEventArgs - Klassen DragDeltaEventArgs inneholder ytterligere informasjon om hendelsen DragDeltaEvent. • FixedPanel - FixedPanel er rot-elementet som anvendes i dokumenter med fast format for å inneholde faste sider for sideinndeling. FixedPanel viser sideinndelt

innhold én side om gangen eller som en rullbar sekvens av sider.

• FlowPanel - FlowPanel anvendes for å bryte opp, pakke inn og innrette innhold som overstiger lengden til én enkelt linje. FlowPanel tilveiebringer linjedelings- og innrettingsegenskaper som kan anvendes når flyten av containerens innhold, for

eksempel Text-elementer, lett vil kunne overstige lengden til én enkelt linje.

Frame - Et felt som kan laste innholdet i et annet formatkodet tre.

• Generator - Generator er objektet som genererer et brukergrensesnitt på vegne av en ItemsControl, som kjører under tilsyn av en GeneratorFactory. • GeneratorFactory - En GeneratorFactory har ansvar for å generere brukergrensesnittet på vegne av en ItemsControl. Den opprettholder forbindelsen mellom elementene i kontrollens ItemsCollection (flat visning) og de tilhørende bruker-grensenittselementene. Kontrollens element-container kan be fabrikken om en

Generator, som besørger den faktiske genereringen av brukergrensesnittet.

• GridPanel - Definerer et gridd-inndelt område bestående av kolonner og rader.

• HeaderltemsControl - Baseklasse for alle kontroller som inneholder flere elementer og har en header.

• HorizontalScrollBar - Klassen HorizontalScrollBar.

• HorisontalSlider - Klassen HorisontalSlider.

• HyperLink - Klassen HyperLink implementerer navigeringskontroll. Standard presenteringsklasse er TextPresenter.

Image - Tilveiebringer en enkel måte å innlemme et bilde i et dokument eller en

applikasjon.

IncludeContactEventArgs - Argumenter som sendes til hendelsesbehandlere for

hendelsen ContactPickerDialog.IncludeContact.

ItemCollection - Opprettholder en samling av diskrete elementer innenfor en kontroll.

Tilveiebringer metoder og egenskaper som gjør det mulig å endre innholdet i samlingene og få tak i data vedrørende innholdet.

ItemsChangedEventArgs - Hendelsen ItemsChanged trigges av en GeneratorFactory

for å informere layouter om at elementsamlingen er endret.

ItemsControl - Baseklasse for alle kontroller som har flere underelementer. ItemsView - ItemsView tilveiebringer en flat visning av en ItemCollection. KeyboardNavigation - Klassen KeyboardNavigation tilveiebringer metoder for logisk

(tab-) og retningsbasert (pil-) navigering mellom fokuserbare kontroller.

• ListBox - Kontroll som implementerer en liste av selekterbare elementer.

• Listltem - Kontroll som implementerer et selekterbart element innenfor en ListBox-kontroll.

• Menu - Kontroll som definerer en meny med valg som brukere kan gjøre.

• Menultem - Underelement av Menu. Menultem-elementer kan bli selektert for å iverksette kommandoer. Menultem-elementer kan være separatorer. Menultem-elementer kan være headere for undermenyer. Menultem-elementer kan være

merket eller ikke.

• PageViewer - Representerer en kombinert kontroll for fremvisning av dokumenter som omfatter en sideinndelingskontroll, en verktøylinje og en "page bar"-kontroll. • PaginationCompleteEventArgs - Argumentene for hendelsen PaginationCompleteEvent. • PaginationProgressEventArgs - Argumentene for hendelsen PaginationProgressEvent. • Pane - Tilveiebringer en måte å angi vindusegenskaper i et formateringsspråk (f.eks. "XAML") uten å starte et nytt vindu. • Panel - Baseklasse for alle panel-elementer. For å instansiere et Panel-element anvendes en avledet, konkret underklasse. • RadioButton - RadioButton implementerer en alternativknapp med to tilstander: "true" eller "false". • RadioButtonList - Denne kontrollen tjener som grupperingskontroll for RadioButton-elementer, og er den som håndterer gjensidig utelukking for RadioButton. RadioButtonList arver fra Selector. RadioButtonList er hovedsaklig en envalgs-modus-selektor, og konseptet med seleksjon (fra Selector) er basert på egenskapen

"Checked" i det RadioButton-elementet den grupperer.

• RowStyle - Foranderlige Changeable-elementer.

• RowStyles - Foranderlig IList-objekt som representerer en samling av Changeable-elementer. • ScrollChangeEventArgs - ScrollChangeEventArgs beskriver en endring av rulle-tilstand.

• ScrollViewer -

• SelectedltemsCollection - En container for de selekterte elementene i en Selector.

• SelectionChangedEventArgs - Inndata til en seleksjonsendring-hendelsebehandler.

• SimpleText - SimpleText er et lettvekts, ettformat-basert tekstelement med flere linjer beregnet for bruk i brukergrensesnitt-scenarier. SimpleText eksponerer flere av de samme formateringsegenskapene som Text, og kan ofte anvendes for å øke ytelsen

på bekostning av en viss reduksjon av allsidigheten.

StyleSelector - StyleSelector gjør det mulig for en applikasjonsutvikler å tilveiebringe spesialtilpasset seleksjonslogikk. For eksempel, med en klasse Bug som Content, kan man anvende en gitt stil for "bugs" med førsteprioritet og en annen stil for "bugs" med annenprioritet. En applikasjonsutvikler kan overskygge metoden SelectStyle i en avledet underklasse av Selector og tilordne en instans av denne klassen til egenskapen StyleSelector i klassen ContentPresenter.

• Text - Representerer en tekstkontroll som muliggjør rendring av flere tekstformater. Text-elementet er best egnet til bruk i en applikasjons brukergrensesnitt; mer avanserte tekst-scenarier har mer nytte av det ekstra funksjonalitetssettet som tilbys av TextPanel. I de fleste tilfeller hvor det kun er behov for støtte for forholdsvis enkel tekstfunksjonalitet er Text det foretrukne elementet på grunn av sin enkle oppbygning

og funksjonalitet.

• TextBox - Kontroll som tilveiebringer et redigerbart felt som tillater innmating av tekst. • TextChangedEventArgs - Klassen TextChangedEventArgs representerer en type

RoutedEventArgs som er aktuell for hendelser trigget av TextRange.SetText(). TextPanel - Formaterer, dimensjonerer og skriver tekst. TextPanel støtter flere tekstlinjer og flere tekstformater.

ToolTip - Kontroll for å vise informasjon når brukeren beveger en pekeranordning

over en kontroll.

ToolTipEventArgs - Dataene som tilveiebringes i forbindelse med hendelsen ToolTipEvent.

• TransformDecorator - TransformDecorator inneholder et underelement og anvender en spesifisert transformasjon på det. TransformDecorator implementerer logikk for å avpasse og innrette underelementet i sine lokale (pre-transformasjons) koordinater, slik at etter transformasjonen, underelementet passer akkurat innenfor dekoratorens plass og tar opp maksimal plass. Underelementet trenger derfor ikke å vite at det har

undergått transformasjon.

• UlElementCollection - En UlElementCollection er er en ordnet samling av UlElement-elementer. • ValueChangedEventArgs - Klassen ValueChangedEventArgs inneholder ytterligere informasjon om hendelsen ValueChangedEvent.

VerticalScrollBar - Klassen VerticalScrollBar.

VerticalSlider - Klassen VerticalSlider.

• Video - Spiller av en streamet lyd- eller videofil i et spesifisert rektangel innenfor det gjeldende brukerkoordinatsystemet. • VisibleChangedEventArgs - Klassen VisibleChangedEventArgs inneholder ytterligere informasjon om hendelsen VisibleChangedEvent.

Navnerommet System.Windows.Controls inneholder også forskjellige "enum"-lister.

Følgende liste inneholder eksempler på enum-lister tilknyttet navnerommet System.Windows.Controls.

CharacterCase - Spesifiserer typen til datategn (versal/minuskel) i en TextBox-kontroll når teksten er typet. • CheckState - Spesifiserer tilstanden til en kontroll, så som en avmerkingsboks, som kan merkes, avmerkes eller settes i en ubestemt tilstand.

• ClickMode - Spesifiserer når hendelsen Click skal trigges.

• ContactControlPropertyPosition - Styrer plasseringen og fremvisningen av kontaktens egenskap. • ContactPickerDialogLayout - Spesifiserer hvordan ContactPickerDialog skal vise selekterte egenskaper. • ContactPropertyCategory - Spesifiserer hvilken verdi å anvende som standardverdi dersom en egenskap har flere verdier som brukeren kan velge blant. Dersom for eksempel "Work" er spesifisert som foretrukket kategori når det spørres etter en telefonnummer-egenskap fra ContactPickerDialog og brukeren selekterer en kontakt som står oppført med både jobb-telefonnummer og privat telefonnummer, vises jobb-telefonnummeret som standard. Brukeren kan da bruke brukergrensesnittet og velge

privatnummeret isteden.

ContactPropertyType - Spesifiserer en egenskap ved en kontakt som

ContactPickerDialog kan be brukeren om.

• ContactType - Spesifiserer hvilke kontakttyper å vise i en ContactPickerDialog.

• Direction - Denne enum-listen anvendes av GeneratorFactory og Generator for å spesifisere i hvilken retning generator-objektet genererer brukergrensesnitt.

• Dock - Spesifiserer posisjonen til et underelement innenfor et DockPanel.

• GeneratorStatus - Denne enum-listen anvendes av GeneratorFactory for å angi status.

KeyNavigationMode - Typen TabNavigation-egenskap spesifiserer hvordan

containeren vil flytte fokus ved navigering med bruk av "tab"-tasten.

• MenultemBehavior - Definerer de forskjellige oppførseler som et Menultem kan ha.

• MenultemType - Definerer de forskjellige typene plassering av Menultem-elementer.

• Orientation - Slider-orienteringstyper.

• PageViewerFit - Velger hvordan sider skal avpasses innenfor PageViewer sitt klient-felt. • PageViewerMode - Velger gjeldende PageViewer-modus, som reflekteres i modus-rullegardinlisten.

• ScrollerVisibility - ScrollerVisibilty definerer synlighetsoppførselen til et rullefelt.

• SelectionMode - Spesifiserer seleksjonsoppførsel for ListBox.

"Position" er et eksempel på struktur tilknyttet navnerommet

System.Windows.Controls. En bruker av Generator beskriver posisjoner ved anvendelse av denne strukturen. For å begynne å generere forover fra begynnelsen av elementlisten, spesifiserer man for eksempel posisjonen (-1, 0) og retningen forover ("Forward"). For å begynne å generere bakover fra enden av listen, spesifiserer man posisjonen (-1, 0) og retningen bakover ("Backward"). For å generere elementene etter elementet med indeks k, spesifiserer man posisjonen (k, 0) og retningen "Forward".

Følgende liste inneholder eksempler på delegater tilknyttet navnerommet System.Windows.Controls. • CheckedChangedEventHandler - Denne delegaten anvendes av hendelsesbehandlere for hendelsen CheckedChangedEvent. • CheckStateChangedEventHandler - Denne delegaten anvendes av hendelsesbehandlere for hendelsen CheckStateChangedEvent.

• ClickEventHandler - Representerer metodene som behandler hendelsen Click.

• ContactTextBoxSelectionChangedEventHandler - En delegat-behandler for hendelsen ContactTextBoxSelectionChanged. • ContactTextBoxTextChangedEventHandler - En delegat-behandler for hendelsen

ContactTextBoxTextChanged.

• ContactTextBoxTextResolvedEventHandler - En delegat-behandler for hendelsen

TextResolvedToContact.

ContentChangedDelegate - Delegat for hendelsen ContentsChangedEvent.

• ContextMenuEventHandler - Typen tilbakekall for behandling av en

ContextMenuEvent-hendelse.

• DragDeltaEventHandler - Denne delegaten anvendes av hendelsesbehandlere for hendelsen DragDeltaEvent. • IncludeKontaktEventHandler -Hendelsesbehandler for hendelsen

ContactPickerDialog.IncludeContact.

• ItemsChangedEventHandler - Delegaten å anvende for behandlere som mottar

ItemsChangedEventArgs.

• OpenedEventHandler - Hendelsesbehandler for hendelsen

ContactPickerDialog.Opened.

• PaginationCompleteDelegate - Delegat for hendelsen PaginationCompleteEvent.

• PaginationProgressDelegate - Delegate for hendelsen PaginationProgressEvent.

• ScrollChangeEventHandler - Denne delegaten anvendes av hendelsesbehandlere for hendelsen ScrollChangeEvent. • SelectionChangedEventHandler - Typen delegat for behandling av en hendelse vedrørende endring av seleksjon. • TextChangedEventHandler -Delegat å anvende for behandlere som mottar

TextChangedEventArgs.

• ToolTipEventHandler - Type tilbakekall for behandling av en ToolTipEvent.

• ValueChangedEventHandler - Denne delegaten anvendes av hendelsesbehandlere for hendelsen ValueChangedEvent.

VisibleChangedEventHandler - Denne delegaten anvendes av hendelsesbehandlere for hendelsen VisibleChangedEvent.

Et annet navnerom, System.Windows.Controls.Atoms, er et under-navnerom under navnerommet System.Windows.Controls. Navnerom System.Windows.Controls.Atoms omfatter tilhørende kontroller, hendelsesargumenter og hendelsesbehandlere. Følgende liste inneholder eksempler på klasser tilknyttet navnerommet

System.Windows.Controls.Atoms.

• PageBar - Representerer en rullbar pagineringskontroll.

• PageElement - Rendrer en gitt side av paginert innhold. Siden som skal rendres spesifiseres av egenskapen SideSource. • PageHoveredEventArgs - PageHoveredEventArgs tilveiebringer informasjon om hvor musepekeren beveges.

PageScrolledEventArgs - PageScrolledEventArgs inneholder informasjon om

hendelsen PageScrolledEvent.

• PageSelectedEventArgs - Hendelsen PageSelectedEvent trigges når det foretas en ny seleksjon av rader/kolonner. • PageSelector - PageSelector lar brukeren selektere et sett av rader/kolonner i sider for fremvisning. • PageSource - Identifiserer kilden for innholdet som skal pagineres. Tilveiebringer også egenskaper og metoder for å formatere paginert innhold.

Følgende liste inneholder eksempler på delegater tilknyttet navnerommet System.Windows.Controls.Atoms. • PageHoveredEventHandler - Denne delegaten anvendes av hendelsesbehandlere for hendelsen PageHoveredEvent. • PageScrolledEventHandler - Denne delegaten anvendes av hendelsesbehandlere for hendelsen PageHovered. • PageSelectedEventHandler - Denne delegaten anvendes av hendelsesbehandlere for hendelsen PageSelectedEvent.

Et navnerom System.Windows.Controls.Primitives er et annet under-navnerom under navnerommet System.Windows.Controls. Som angitt tidligere omfatter under-navnerommet "Primitives" kontroller som er beregnet for bruk som primitiver av andre, mer komplekse kontroller. Følgende liste inneholder eksempler på klasser tilknyttet navnerommet System.Windows.Controls.Primitives.

• ButtonBase - Når den overskygges i en avledet klasse, definerer den relevante hendelser og egenskaper og tilveiebringer hendelsesbehandlere for de aktuelle

innmatingshendelser.

• Popup - En kontroll som genererer et "fly-out"-vindu med innhold.

• RangeBase - Baseklasse for elementer som har et spesifikt område. Eksempler på slike elementer er rullefelter og progresjonsfelter. Denne klassen definerer de relevante hendelser og egenskaper og tilveiebringer hendelsesbehandlere for

hendelsene.

• RepeatButton - Kontrollen RepeatButton legger til repetisjonssemantikk for når hendelsen Click inntreffer.

ScrollArea - ScrollArea er det faktiske elementet for rulling. Det inneholder innhold som det klipper til og tilveiebringer egenskaper for å eksponere innholdets offset og utstrekning. Det tilveiebringer også standard innmatingshåndtering slik at rulling kan

bevirkes programmatisk eller med bruk av et tastatur eller et rullehjul på en mus.

• ScrollBar - Klassen ScrollBar.

• Selector - Baseklasse for kontroller som selekterer elementer blant sine underelementer.

Slider - Klassen Slider.

Thumb - Denne kontrollen muliggjør grunnleggende "merk-og-dra"-basert flytte-funksjonalitet for rullefelter og kontroller for å endre vindusstørrelse.

"lEnsureVisible" er et eksempel på grensesnitt som er tilknyttet navnerommet System.Windows.Controls.Primitives. lEnsureVisible implementeres på et grafisk objekt for å rulle/flytte et grafisk underelement slik at det kommer til syne.

Følgende liste inneholder eksempler på enum-lister tilknyttet navnerommet System.Windows.Controls.Primitives.

• ArrowButtonStates -

• CloseModeType - Beskriver hvordan et popup-vindu skal reagere på forskjellige mus-hendelser.

Part - Part anvendes for å angi den semantiske bruken av kontrollene som danner

rullefeltet.

• PartStates - "ScrollBar-PartStates".

• PlacementType - Beskriver hvor på skjermen et popup-vindu skal plasseres.

• SizeBoxStates -

Et navnerom for dokumenter 312 er en samling av semantikk- og formaterings-elementer som anvendes for å frembringe rikt formaterte og semantisk rike dokumenter. I en utførelsesform er et "element" en klasse som primært anvendes i forbindelse med et hierarki av elementer (referert til som et "tree"). Disse elementene kan være interaktive (f.eks. motta brukerinnmating via et tastatur, en mus eller en annen innmatings-anordning), kan rendre bilder eller objekter og kan være til hjelp under anordning av andre elementer. Eksempler på elementer omfatter et "Block"-element som implementerer en generisk blokk, et "Body"-element som representerer innhold som omfatter en tabells kropp, et "Cell"-element som inneholder data innenfor en tabell, et "Header"-element som representerer innholdet i en tabells header samt et "PageBreak"-element som anvendes for å dele opp innhold over flere sider.

Følgende liste inneholder eksempler på klasser som eksponeres av navnerommet System.Windows.Documents.

AdaptiveMetricsContext - AdaptiveMetricsContext er rot-elementet for "adaptive-flow-formaf-dokumenter. Når et underpanel innkapsles i et AdaptiveMetricsContext-element, blir panelets innhold prosessert av RME-(Reading Metrics Engine)-motoren. Størrelsen til underpanelet anvendes for å beregne antallet og størrelsen til

eventuelle kolonner, så vel som optimale fontstørrelser og linjehøyder.

Block - Implementerer et generisk blokk-element som ikke implementerer standard

rendringsoppførsel.

BlockElement - Baseklasse for alle Block-elementer.

Body - Representerer innholdet som danner kroppen til et Table-element.

Bold - Implementerer et fet bokstavtype-element avledet fra Inline.

BreakRecord - Lagrer informasjon som er nødvendig for å fortsette formatering av paginert innhold etter sideskift. Avled en underklasse fra denne klassen for å tilveiebringe støtte for sideinndeling. Dette er en abstrakt klasse.

Cell - Cell-elementer inneholder tabelldata innenfor en Table. Cell-elementer er inne-holdt i en Row.

• CellCollection - Ordnet samling av celler i en tabell.

• Column - Column-elementet anvendes for å fordele innholdet i en GridPanel eller

Table.

• ColumnCollection - Et ColumnCollection-element er en ordnet samling av Column-elementer. • ColumnResult - Representerer en kolonnes fremvisningsrelaterte informasjon. ContainerParagraphResult - Gir tilgang til beregnede layout-parametere for et

Paragraph-objekt som kun inneholder andre Paragraph-objekter.

• ContentPosition - Representerer posisjonen til innhold innenfor et avsnitt. Avled en underklasse fra denne klassen for å beskrive posisjonen til assosiert innhold. Dette

er en abstrakt klasse.

• Document - Formålet med klassen Document er å avkople innholdet i et dokument fra "brukergrensesnitt-rammen" som omgir det. Med å "avkople" menes at man kan forfatte et dokument uten å tenke på (og uten å binde seg til) dets brukergrensesnitt. Klassen Document holder dokumentinnhold, typisk et TextPanel eller et FixedPanel og dets underelementer. Et tre av grafiske objekter (PageViewer som standard)

assosieres med dette elementet gjennom WPP-kontrollstilingsmekanismen.

• DocumentPage - Representerer layoutinformasjon for en kontroll assosiert med en side av et paginert dokument. Avled en underklasse fra denne klassen for å implementere en beskrivelse av layoutinformasjonen for disse kontrollene. Dette er

en abstrakt klasse.

DocumentPageParagraphResult - Gir tilgang til beregnede layoutparametere for

objekter som er berørt av sideinndeling.

• FindEngine - Baseklasse for find-algoritmer.

• FindEngineFactory - Fabrikk for find-algoritmer.

• FixedPage - Gir tilgang til én enkelt side av innhold i et layout-dokument med fast format.

• Footer - Representerer innholdet som omfatter bunnteksten i et Table-element.

• Header - Representerer innholdet som omfatter toppteksten i et Table-element.

• Heading - Implementerer et blokk-nivå element som rendrer tekst som en heading.

• HyphenationDictionary - HyphenationDictionary representerer en datakatalog for det formål å tilveiebringe støtte for orddeling i applikasjoner. Den kan inneholde både en intern datakatalog og en referanse til en ekstern datakatalog. Den interne data-katalogen har høyere prioritet og vil bli anvendt før poster i den eksterne data-katalogen. • Hyphenator - Hyphenator-objektet holder en referanse til orddelingsdata i en

HyphenationDictionary og utfører også orddeling.

• Inline - Implementerer et generisk "inline"-element som ikke implementerer noen standard rendringsoppførsel.

InlineElement - Implementerer et generisk inline-element som baseklasse for alle

inline-elementer.

• Italic - Implementerer et kursiv-element avledet fra Inline.

• LineBreak - Formateringselement som påtvinger et linjeskift.

• LineResult - Gir tilgang til beregnet informasjon om en tekstlinje.

• List - Implementerer et listeelement. List-elementer er blokk-nivå elementer som er innrettet for formatering med markører, så som punkter eller nummerering. • ListElementltem - Implementerer et element i et listeelement, som støtter markører så som punkter eller nummerering. • Note - Implementerer en kommentar eller en bemerkning, tilsvarende "note"-elementet i HTML. • PageBreak - Representerer et formateringselement som anvendes for å dele opp innhold over forskjellige sider. • PageDescriptor - Implementerer en sidebeskriver som lagrer informasjon som er nødvendig for å frembringe sideinndelt layout. • Paragraph - Implementerer et blokk-nivå element som brukes til å rendre tekst i et avsnitt. Rendringsoppførselen er tilsvarende den til "paragraph"-elementet i HTML. • ParagraphResult - Gir tilgang til beregnede layout-parametere for et Paragraph-objekt.

• Row - Definerer en rad i et GridPanel- eller Table-element.

• RowCollection - RowCollection representerer an ordnet samling av Row-elementer. • RowGroup - Spesifiserer standardverdier for egenskaper for en gruppe av rader i et

Table- eller GridPanel-element.

• Section - Implementerer et generisk containerelement. Rendringsoppførselen er tilsvarende "div"-elementet i HTML. • SmallCaps - Implementerer et inline SmallCaps-element. SmallCaps er typografiske former som rendrer små bokstaver som mindre, store bokstaver for å fremheve, for

eksempel i en tittel.

• Subscript - Representerer et inline-element med senket skrift. Tegn i senket skrift blir skrevet rett under, under og til venstre for eller under og til høyre for andre datategn. • Superscript - Representerer et inline-element med hevet skrift. Tegn i hevet skrift er typisk bokstaver eller tall og blir rendret rett over, over og til venstre for eller over og

til høyre for andre datategn.

• Table - Table anvendes for å vise komplekse data i tabellform ved anvendelse av et formateringsspråk (f.eks. "XAML").

• TextArray - Base-API for aksess og manipulering av tekst.

• TextChangedEventArgs - TextChangedEventArgs definerer hendelsesargumentene som sendes når et TextArray endres. • TextElement - TextElement tilveiebringer TextRange-funksjonalitet for TextTree. Det er en uforanderlig, kontinuerlig TextRange med faste endepunkter. Det gir støtte for innmating, fokusering og hendelsesbehandling for ContentElement. Det gir også

støtte for DependencyObject-egenskapen.

• TextNavigator - Dette elementet kan spesifisere tekstlig innhold. Implementerer en bevegelig TextPosition. Det kan flytte seg med tekstflyten eller være plassert et kjent

sted i teksten.

• TextParagraphResult - Gir tilgang til beregnede layout-parametere for tekst, inkludert flytende objekter og figurer.

TextPosition - Dette objektet representerer en gitt posisjon i et TextArray. Et kompakt objekt som representerer en posisjon i tekst opprettholder automatisk posisjonen når teksten endrer seg. Sammenlikningsoperasjoner kan kun gjøres for to posisjoner innenfor samme TextArray (samme Context). Tekstposisjonen kan være statisk eller dynamisk. Egenskapen IsChangeable spesifiserer typen posisjon.

TextRange - TextRange er en abstrakt klasse som tilveiebringer generisk assosia-sjon av null eller flere deltekster med egenskaper. Manipulering av deltekster

defineres i avledede klasser.

TextRangeMovable - TextRangeMovable er en abstrakt klasse for bevegelige TextRange-elementer. Den legger til muighet for å flytte start- og endepunkter basert

på TextUnit-elementer.

TextTreeChangedEventArgs - TextChangedEventArgs definerer hendelsesargumentene som sendes når et TextArray endres.

TextTreeDumper - TreeDumper er en tre-testingsklasse som er "public" som følge av

innpakkingshensyn.

TextTreeNavigator - Dette er et objekt som representerer en gitt bevegelig posisjon i et TextTree. Det er en spesifikk implementasjon av TextNavigator for bruk kun i

TextTree-elementer.

TextTreePosition - Dette er et objekt som representerer en gitt uforanderlig posisjon i et TextTree. Den er en spesifikk implementasjon av TextPosition for bruk kun i

TextTree-elementer.

TextTreeRange - Tilveiebringer TextRange-funksjonalitet for TextTree. Den er en

foranderlig, kontinuerlig TextRange med bevegelige endepunkter. TextTreeRangeContentEnumerator - Liste av underobjekter direkte under et

TextTreeRange.

• TextUnit - Utvidbar tekstnavigeringsenhet.

• TextUnits - Mye brukte tekstenheter for TextPosition og TextRange.

• Typography - Gir tilgang til et rikt sett av "OpenType"-typografiegenskaper.

• UlElementParagraphResult - ParagraphResult-element for et avsnitt som utelukkende består av et UlElement. Anvendes for flytende enheter, figurer og innbygde

blokk-nivå Ul Elementer.

Underline - Implementerer et understrekingselement avledet fra InlineElement.

Følgende liste inneholder eksempler på grensesnitt assosiert med navnerommet System.Windows.Documents.

IDocumentContentHost - Implementer dette grensesnittet på en innholdsvert for at underelementer i denne verten skal kunne varsle verten når innholdet endrer seg.

• IDocumentFormatter - Implementer dette grensesnittet på et element for å tilveiebringe støtte for dokumentformateringsfunksjoner så som sideinndeling. • ITextDocumentResult - Implementer dette grensesnittet for å holde kolonne-informasjon for et dokument. • ITextParagraphResult - Dette grensesnittet implementeres for å tilveiebringe tekst-og posisjonsinformasjon for tekstavsnitt.

Følgende liste inneholder eksempler på enum-lister assosiert med navnerommet System.Windows.Documents.

• ElementEdge - Identifiserer kanten til et objekt hvor en TextPosition befinner seg.

• FindAdvancedOptions - Avanserte søkealternativer som anvendes av klassene FindAlgoritme (initialisering av søk) og TextRangeMovable / TextSelection (utførelse

av forenklede søk).

FindOptions - Forenklede søkealternativer som anvendes av metoden TextBox.Find.

• LogicalDirection - LogicalDirection definerer en logisk retning for forflytning i tekst. Den anvendes også for å finne ut hvor en TextPosition vil ende opp når innhold

settes inn ved den aktuelle tekstposisjonen.

• TextArray Ru nType - Identifiserer flyten hvor en TextPosition befinner seg, tatt hensyn til LogicalDirection. • TextChangeOptions - Mulige tekstendringer for foranderlig tekst (CanChangeText). • TextMoveOptions - Styrer bevegelsen til TextNavigator ved å spesifisere betingelser for å avbryte navigering.

Følgende liste inneholder eksempler på delegater tilknyttet navnerommet System.Windows.Documents. • ObjectCloneDelegate - Tilbakekallsmetode for å tilveiebringe et klon eller en kopi av et DependencyObject når en andel av et TextArray kopieres eller flyttes. • TextChangedEventHandler - Delegaten TextChangedEventHandler anropes med argumentene TextChangedEventArgs hver gang innhold blir lagt til eller fjernet fra TextTree.

Et navnerom Shapes 314 er en samling av vektorgrafikk-elementer som anvendes for å generere bilder og objekter. Bruken av vektorgrafikk-elementer gjør det enkelt å endre størrelsen til elementer i tilpasning til kravene for et gitt grensesnitt eller en gitt fremvisningsanordning. Følgende liste inneholder eksempler på klasser som eksponeres gjennom navnerommet System.Windows.Shapes.

• Ellipse - Tegner en ellipse.

• Glyphs - Representerer en ideogram-form i et formateringsspråk så som "XAML".

Ideogrammer anvendes for å representere fonter.

• Line - Tegner en rett linje mellom to punkter.

Path - Tegner en serie av forbundne linjer og kurver.

Polygon - Tegner et polygon (en forbundet sekvens av linjer som danner en lukket

kurve).

• Polyline - Tegner en serie av forbundne, rette linjer.

• Rectangle - Tegner et rektangel.

• Shape - En abstrakt klasse som tilveiebringer grunnleggende funksjonalitet for form-elementer, så som ellipse, polygon og rektangel.

Navnerommene System.Windows.Controls, System.Windows.Documents og System.Windows.Shapes tilveiebringer et integrert system for utvikling av applikasjoner og relaterte komponenter. Dette integrerte systemet gir en felles programmeringsmodell for alle tre navnerommene, og forenkler med det utvikling av brukerprogramvare. Dette samspillet mellom de tre navnerommene gjør at utviklere kun trenger å lære seg én enkelt programmeringsarkitektur som kan anvendes for all funksjonalitet som tilveiebringes av tre navnerom. For eksempel anvendes et felles formateringsspråk i alle tre navnerommene. Dette felles formateringsspråket besørger avbildning av klasser og egenskaper spesifisert i XML-format til et instansiert objekttre.

Videre anvendes en ensartet programmeringsmodell og ensartede tjenester i de tre navnerommene. For eksempel anvendes et ensartet hendelsessystem for å iverksette og behandle forskjellige hendelser. Et felles egenskapssystem anvendes for å tilpasse forskjellige egenskaper, binde data til en egenskap eller animere en egenskap, uavhengig av hvorvidt egenskapen er tilknyttet navnerommet "Controls", "Documents" eller "Shapes". I tillegg er innmatingsmodellene og layout-håndteringen den samme i alle tre navnerommene. For eksempel kan forskjellige kontroller fra navnerommet System.Windows.Controls bli nestet midt i et dokument innhold som er definert med bruk av dunksjonalitet fra navnerommet System.Windows.Documents.

Eksempler på kildefiler vil omfatte et sett av vinduer og "panes" eller paneler (også referert til som "sider") som er deklarativt definert ved anvendelse av "Controls", "Documents" og "Shapes". Interaksjonslogikk er også tilveiebragt for vinduene og panelene. Interaksjonslogikken identifiserer programkode som skal kjøres som reaksjon på en gitt handling foretatt av en bruker eller som reaksjon på forekomst av en hendelse eller aktivitet. Interaksjonslogikken kan for eksempel være definert ved anvendelse av et CLR-(Common Language Runtime)-språk. CLR er et kjøremiljø som tar seg av kjøring av programkode (f.eks..NET-basert programkode) og tilbyr forskjellige tjenester så som sikkerhetrelaterte tjenester og minnerelaterte tjenester. Eksempler på CLR-språk omfatter C# og Visual Basic. Kildefiler kan også omfatte andre alenestående programmeringsspråk-filer, så som C#- eller Visual Basic-filer.

Selv om denne beskrivelsen er rettet mot integrasjon av navnerommene "Controls", "Documents" og "Shapes", kan denne integrasjonen anvendes for hvilke som helst eller alle de navnerom og under-navnerom som er beskrevet her.

Et navnerom Data 316 omfatter klasser og grensesnitt som anvendes for å binde elementers egenskaper til datakilder, datakilde-klasser, og data-spesifikke implementa-sjoner av sett og fremvisninger av data. Disse klassene og grensesnittene anvendes også for å behandle unntak i forbindelse med datainnmating og muliggjøre opprettelse av et brukergrensesnitt under kjøring basert på informasjon fra forskjellige datakilder. Data kan bli vist som tekst eller kan anvendes for å endre formateringen av fremvisningen, for eksempel til å vise kronebeløp med rød skrift dersom de er negative. Eksempler på klasser omfatter en klasse "Bind" som representerer et bindingsdeklarasjonsobjekt som administrerer bindinger mellom et brukergrensesnitt for dynamiske egenskaper og kildedata, og en klasse "XmlDataSource" som tjener som datakilde for data tilknyttet XML-formaterte innholdsnoder.

Et navnerom Media 318 tilveiebringer forskjellige mediaklasser. Applikasjonsutviklere så vel som komponentutviklere kan anvende disse klassene for å utvikle forskjellig presentasjonsfunksjonalitet. Eksempler på klasser i navnerommet Media 318 omfatter en klasse "ImageEffect" som muliggjør utvalgte billedbehandlingseffekter (f.eks. diffusering og gråverdiskala), og en klasse "Brush" som tilbyr en mekanisme for å fylle et område med farger, gradienter, bilder, video og liknende.

Navnerommet Media 318 omfatter et under-navnerom System.Windows.Media.Animation som omfatter tjenester som lar en utvikler animere egenskaper og koordinere et sett av animasjoner med et sett av tidslinjer. En animasjon er et objekt som endrer en verdi i løpet av et tidsrom. Animasjonseffekter omfatter flytting av et objekt i fremvisningen og endring av et objekts størrelse, form eller farge. Flere animasjons-klasser er tilveiebragt som implementerer forskjellige animasjonseffekter. Effekter kan oppnås ved å assosiere en animasjon med verdien til et elements egenskap. For eksempel, for å generere et rektangel som forsvinner og kommer til syne igjen, kan man assosiere én eller flere animasjoner med rektangelets opasitetsverdi.

Navnerommet Media 318 omfatter også et under-navnerom System.Windows.Media.TextFormatting som tilbyr forskjellige tjenester knyttet til tekstbehandling. For eksempel tilbyr en tekstmotor "TextFormatter" tjenester for å dele opp tekstlinjer og formatere tekst som presenteres i en fremvisning. "TextFormatter" støtter forskjellige teksttegnformater og avsnittsstiler, så vel som internasjonal tekstlayout.

Et navnerom Design 320 tilveiebringer klasser som muliggjør redigering av skjemaer og tekst, formatering av data samt deling av data på tvers av prosesser. Disse klassene danner et utvidbart rammeverk for redigering av dokumenter, applikasjoner og annet innhold.

Et navnerom Input 322 omfatter en innmatingsstyrer som koordinerer innmating som mottas av systemet. Navnerommet Input 322 omfatter også klasser som letter administrering og tilveiebringer styring av forskjellige innmatingsanordninger, så som et tastatur eller en mus.

Et navnerom Navigation 324 tilveiebringer et sett av klasser og tjenester som gjør det mulig å bygge applikasjoner med navigeringsmodeller, så som en nettleser. Disse klassene og tjenestene muliggjør utvikling av applikasjoner med spesialiserte navige-ringsopplevelser. For eksempel, i forbindelse med kjøp av et produkt eller en tjeneste fra en "online"-leverandør, kan for eksempel det å klikke på "Tilbake"-knappen forårsake at applikasjonen viser en ny side som spør brukerne om de ønsker å kansellere eller endre sin ordre. Som et annet eksempel kan det å aktivere en "Oppdater"-knapp forårsake at en applikasjon henter nye data umiddelbart i stedet for først å laste inn applikasjonen på nytt og deretter hente de nye dataene. Navnerommet Navigation 324 omfatter også sidelokale funksjoner som tilbyr en mekanisme for å generere et hierarki av spørsmål som presenteres for en bruker.

Et navnerom Automation 326 omfatter et sett av klasser som støtter automatise-ring av tilgjengelighet og brukergrensesnitt.

Et navnerom Serialization 328 omfatter en parser som kan laste eller lagre et hierarki av objekter (f.eks. elementer) fra eller til en XML-fil eller en fil med en binær representasjon. Denne prosessen setter også egenskaper knyttet til objektene og tilknytter hendelsesbehandlere.

Et navnerom Interop 330 tilveiebringer et sett av klasser som muliggjør sam-handling med andre operativsystemer eller databehandlingsplattformer.

Et navnerom Forms.lnterop 332 tilveiebringer et element gjør det mulig for en applikasjon å være vert for en skjemakontrolleringsoperasjon.

Et annet navnerom, System.lO.CompoundFile (ikke vist i figur 3), omfatter tjenester for å anvende en sammensatt fil hvor det er lagret forskjellige distribuerbare filer. Disse tjenestene muliggjør kryptering og komprimering av innhold. Tjenestene støtter også lagring av flere forskjellige gjengivelser av det samme innholdet, så som et flytende (reflowable) dokument og et fast formatert (fixed format) dokument.

Eksempel pAdatabehandlingssystem og -miljø

Figur 4 illustrerer et eksempel på et egnet databehandlingsmiljø 400 der programmeringsrammeverket 132 kan implementeres (enten helt eller delvis). Databehandlingsmiljøet 400 kan anvendes i de datamaskin- og nettverksarkitekturene som er beskrevet her.

Det illustrerte miljøet 400 er bare ett eksempel på mulig miljø, og er ikke ment å antyde noen som helst begrensning vedrørende bruksområdet eller funksjonaliteten til datamaskin- og anordningsarkitekturene. Heller ikke skal miljøet 400 tolkes å ha noen som helst avhengighet av eller krav vedrørende noen enkelt komponent eller noen kombinasjon av komponenter som er illustrert i det eksemplifiserte miljøet 400.

Rammeverket 132 kan realiseres med en rekke forskjellige andre generelle eller spesialiserte databehandlingssystemer, -miljøer eller -anordninger. Eksempler på vel-kjente databehandlingssystemer, -miljøer og/eller -anordninger som kan være egnet for bruk omfatter, men er ikke begrenset til, personlige datamaskiner, tjenermaskiner, fler-prosessorsystemer, mikroprosessor-baserte systemer, personlige datamaskiner i nettverk, minidatamaskiner, stormaskiner, distribuerte databehandlingsmiljøer som omfatter hvilke som helst av systemene eller anordningene over og annet. Kompakte versjoner eller delversjoner av rammeverket kan også bli implementert i klientanordninger med begrensede ressurser, så som mobiltelefoner, personlige digitale assistenter, håndholdte datamaskiner eller andre anordninger for kommunikasjon eller databehandling.

Rammeverket 132 kan beskrives i den generelle sammenhengen datamaskin-eksekverbare instruksjoner, så som programmoduler, som eksekveres av én eller flere datamaskiner eller andre anordninger. Generelt omfatter programmoduler rutiner, programmer, objekter, komponenter, datastrukturer og liknende som utfører spesifikke oppgaver eller implementerer spesifikke abstrakte datatyper. Rammeverket 132 kan også tilpasses for distribuerte databehandlingsmiljøer der oppgaver blir utført av fjerne prosesseringsanordninger som er forbundet via et kommunikasjonsnettverk. I et distribuert databehandlingsmiljø kan programmoduler være lagret i både lokale og fjerne datamaskin-lagringsmedier som omfatter minnelagringsanordninger.

Databehandlingsmiljøet 400 omfatter en generell databehandlingsanordning i form av en datamaskin 402. Komponentene i datamaskinen 402 kan omfatte, men er ikke begrenset til, én eller flere prosessorer eller prosesseringsenheter 404, et systemminne 406 og en systembuss 408 som kopler forskjellige systemkomponenter inklusive prosessoren 404 til systemminnet 406.

Systembussen 408 representerer én eller flere av mange mulige typer busstrukturer, omfattende en minnebuss eller minnekontrolller, en periferienhet-buss, en akselerert grafikkport og en prosessor- eller lokal buss, som anvender en hvilken som helst av en rekke tilgjengelige bussarkitekturer. Som eksempler kan slike bussarkitekturer omfatte en ISA-(lndustry-Standard-Architecture)-buss, en MCA-(Micro-Channel-Architecture)-buss, en EISA-(Enhanced ISA)-buss, en lokal VESA-(Video-Electronics-Standards-Association)-buss og en PCI-(Peripheral-Component-lnterconnect)-buss, også kjent som en Mezzanine-buss.

Datamaskinen 402 omfatter typisk forskjellige datamaskin-lesbare medier. Et slikt medium kan være et hvilket som helst tilgjengelig medium som kan aksesseres av datamaskinen 402, og omfatter både volatile og ikke-volatile medier samt flyttbare og stasjonære medier.

Systemminnet 406 omfatter datamaskin-lesbare medier i form av volatilt minne, så som et direkteaksessminne (RAM) 410 og/eller ikke-volatilt minne, så som leseminne (ROM) 412. Et BIOS (Basic Input/Output System) 414, som inneholder de grunnleggende rutinene som hjelper til med å overføre informasjon mellom elementer i datamaskinen 402, for eksempel under oppstart, er lagret i ROM 412. RAM 410 inneholder typisk data og/eller programmoduler som er umiddelbart tilgjengelige for og/eller som opereres på av prosesseringsenheten 404.

Datamaskinen 402 kan også omfatte andre flyttbare/stasjonære, volatile/ikke-volatile datamaskin-lagringsmedier. Som et eksempel illustrerer figur 4 en harddisk-stasjon 416 for å lese fra og skrive til et stasjonært, ikke-volatilt magnetisk medium (ikke vist), en magnetdiskstasjon 418 for å lese fra og skrive til en flyttbar, ikke-volatil magnetdisk 420 (f.eks. en "diskett"), samt en optisk disk-stasjon 422 for å lese fra og/eller skrive til en flyttbar, ikke-volatil optisk disk 424, så som en CD, en DVD eller et annet optisk medium. Harddiskstasjonen 416, magnetdiskstasjonen 418 og optisk disk-stasjonen 422 er koplet til systembussen 408 via ett eller flere datamedium-grensesnitt 426. Alternativt kan harddiskstasjonen 416, magnetdiskstasjonen 418 og optisk disk-stasjonen 422 være koplet til systembussen 408 gjennom ett eller flere grensesnitt (ikke vist).

Lagringsmedium-stasjonene og deres assosierte datamaskin-lesbare medier tilveiebringer ikke-volatil lagring av datamaskin-lesbare instruksjoner, datastrukturer, programmoduler og andre data for datamaskinen 402. Selv om eksempelet illustrerer en harddisk 416, en flyttbar magnetdisk 420 og en flyttbar optisk disk 424, må det forstås at andre typer datamaskin-lesbare medier kan lagre instruksjoner som kan aksesseres av en datamaskin, så som magnetkassetter eller andre magnetiske lagringsanordninger, flashminnekort, CD'er, DVD'er eller andre optiske lagre, RAM, ROM, EEPROM (Electrically-Erasable Programmable Read-Only Memory) og liknende også kan anvendes for å realisere det eksemplifiserte databehandlingssystemet og -systemet.

Et hvilket som helst antall programmoduler kan være lagret i harddisken 416, magnetdisken 420, den optiske disken 424, ROM 412 og/eller RAM 410, for eksempel omfattende et operativsystem 426, ett eller flere brukerprogrammer 428, andre programmoduler 430 og programdata 432. Operativsystemet 426, det ene eller de flere applika-sjonsprogrammene 428, de andre programmodulene 430 og programdataene 432 (eller en hvilken som helst kombinasjon av disse) kan alle innbefatte deler av programmeringsrammeverket 132.

En bruker kan mate inn kommandoer og informasjon til datamaskinen 402 via innmatingsanordninger så som et tastatur 434 og en pekeranordning 436 (f.eks. en

"mus"). Andre innmatingsanordninger 438 (ikke vist spesifikt) kan omfatte en mikrofon, en styrespak, en spillkontroll, en parabolantenne, en serieport, en skanner og/eller liknende. Disse og andre innmatingsanordninger er koplet til prosesseringsenheten 404 via inn/ut-grensesnitt 440 som er koplet til systembussen 408, men kunne også ha vært tilkoplet via andre grensesnitt og busstrukturer, så som en parallellport, en spillutgang eller en USB-(Universal Serial Bus)-port.

En monitor 442 eller en annen type fremvisningsanordning kan også være koplet til systembussen 408 via et grensesnitt, så som et videoadapter 444.1 tillegg til monitoren 442 kan andre periferiske utmatingsanordninger omfatte elementer så som høyttalere (ikke vist) og en skriver 446, som kan stå i forbindelse med datamaskinen 402 via inn/ut-grensesnittene 440.

Datamaskinen 402 kan kjøre i et nettverksmiljø som anvender logiske forbindelser til én eller flere fjerne datamaskiner, så som en fjern-dataanordning 448. Som et eksempel kan fjern-dataanordningen 448 være en personlig datamaskin, en bærbar datamaskin, en tjeneranordning, en ruteranordning, en nettverksdatamaskin, en peer-anordning, en annen nettverksnode eller annet. Fjern-dataanordningen 448 er illustrert som en bærbar datamaskin som kan omfatte mange av eller alle de elementer og trekk som er beskrevet her i forbindelse med datamaskinen 402.

Logiske forbindelser mellom datamaskinen 402 og fjern-datamaskinen 448 er vist i form av et lokalt nettverk (LAN) 450 og et generelt regionalt nettverk (WAN) 452. Slike nettverksmiljøer er vanlige i kontorer, bedriftsomspennende datanettverk, intranett og Internett.

Når den anvendes i et LAN-nettverksmiljø, er datamaskinen 402 koplet til et lokalt nettverk 450 via et nettverksgrensesnitt eller nettverkskort 454. Når den anvendes i et WAN-nettverksmiljø, omfatter datamaskinen 402 typisk et modem 456 eller en annen anordning for å etablere kommunikasjon over det regionale nettverket 452. Modemet 456, som kan være internt eller eksternt i forhold til datamaskinen 402, kan være koplet til systembussen 408 via inn/ut-grensesnittene 440 eller andre egnede mekanismer. Det må forstås at de illustrerte nettverksforbindelsene kun er eksempler, og at andre midler for å etablere én eller flere kommunikasjonsforbindelser mellom datamaskinene 402 og 448 kan anvendes.

I et nettverksmiljø, så som det illustrert av databehandlingsmiljøet 400, kan programmoduler som er vist i forbindelse med datamaskinen 402, eller deler av disse, være lagret i en fjern lokalisert lagringsanordning. Som et eksempel befinner fjern-applikasjonsprogrammer 458 seg i en lagringsanordning i fjern-dataanordningen 448. For illustrasjonsformål er brukerprogramvare og andre kjørbare programkomponenter så som operativsystemet her vist som separate blokker, selv om en forstår at slike programmer og komponenter til forskjellige tider befinner seg i forskjellige lagringskomponenter i data-behandlingsanordningen 402 og eksekveres av prosessoren(e) i datamaskinen.

En utførelse av rammeverket 132, og spesielt API'et 142 eller anrop som gjøres til API'et 142, kan være lagret på eller bli overført over en eller annen form for datamaskin-lesbart medium. Et datamaskin-lesbart medium kan være et hvilket som helst tilgjengelig medium som kan aksesseres av en datamaskin. Som eksempler, og uten begrensning, kan datamaskin-lesbare medier omfatte "datamaskin-lagringsmedier" og "kommunikasjonsmedier". "Datamaskin-lagringsmedier" omfatter volatile og ikke-volatile samt flyttbare og stasjonære medier som er realisert med en hvilken som helst metode eller teknologi for lagring av informasjon, så som datamaskin-lesbare instruksjoner, datastrukturer, programmoduler eller andre data. Datamaskin-lagringsmedier omfatter, men er ikke begrenset til, RAM, ROM, EEPROM, flashminne eller annen minneteknologi, CD-ROM, DVD'er eller andre optiske lagre, magnetkassetter, magnetbånd, magnetplatelagre eller andre magnetiske lagringsanordninger, eller et hvilket som helst annet medium som kan anvendes for å lagre den ønskede informasjonen og som kan aksesseres av en datamaskin.

Et "kommunikasjonsmedium" innlemmer typisk datamaskin-lesbare instruksjoner, datastrukturer, programmoduler eller andre data i et modulert datasignal så som en bærebølge eller en annen transportmekanisme. Kommunikasjonsmedier omfatter også et hvilket som helst informasjonsleveringsmedium. Med "modulert datasignal" menes et signal som får én eller flere av sine karakteristika satt eller endret slik at det kodes inn informasjon i signalet. Som et eksempel, og uten begrensning, omfatter kommunikasjonsmedier kablede medier så som et kabelnettverk eller en direktekoplet forbindelse, samt trådløse medier så som akustiske, RF-baserte, infrarødt-baserte og andre trådløse medier. Enhver kombinasjon av det ovennevnte er også omfattet innenfor rammen av datamaskin-lesbare medier.

Alternativt kan deler av rammeverket implementeres i maskinvare eller i en kombinasjon av maskinvare, programvare og/eller fastvare. For eksempel kan én eller flere applika-sjonsspesifikke integrerte kretser (ASICer) eller programmerbare logikkanordninger (PLD'er) konstrueres for eller programmeres til å realisere én eller flere deler av rammeverket.

Et programmeringsgrensesnitt (eller enklere, et grensesnitt) kan betraktes som en hvilken som helst mekanisme, prosess eller protokoll som gjør det mulig for ett eller flere kodesegmenter å kommunisere med eller aksessere funksjonaliteten som tilveiebringes av ett eller flere andre kodesegmenter. Alternativt kan et programmeringsgrensesnitt betraktes som et antall mekanismer, metoder, funksjonsanrop, moduler, objekter, osv. i en komponent i et system med mulighet til kommunikasjonsetablerende kopling til et antall mekanismer, metoder, funksjonanrop, moduler, osv. i andre komponenter. Betegnelsen "kodesegment" i setningen over er ment å omfatte én eller flere instruksjoner eller kodelinjer, og omfatter for eksempel kodemoduler, objekter, subrutiner, funksjoner og annet uavhengig av terminologien som anvendes eller hvorvidt kodesegmentene er kompilert hver for seg, hvorvidt kodesegmentene er tilveiebragt i form av kildekode, delvis kompilert kode eller objektkode, hvorvidt kodesegmentene anvendes i et kjøresystem eller en prosess, hvorvidt de befinner seg på samme maskin, på forskjellige maskiner eller er distribuert over flere maskiner, eller hvorvidt funksjonaliteten som implementeres av kodesegmentene er realisert utelukkende i programvare, utelukkende i maskinvare eller i en kombinasjon av maskinvare og programvare.

Begrepsmessig kan et programmeringsgrensesnitt betraktes generisk, som vist i figur 5 eller figur 6. Figur 5 illustrerer et grensesnitt Interfacel som en kanal som første og andre kodesegmenter kommuniserer over. Figur 6 illustrerer et grensesnitt som omfattende grensesnittsobjekter 11 og 12 (som kan, men ikke trenger å være en del av de første og andre kodesegmentene) som gjør det mulig for første og andre kodesegmenter i et system å kommunisere over et medium M. I illustrasjonen i figur 6 kan man betrakte grensesnittsobjektene 11 og 12 som atskilte grensesnitt i det samme systemet, men man kan også betrakte objektene 11 og 12 pluss mediet M som grensesnittet. Selv om figurene 5 og 6 viser dataflytpiler som peker i begge retninger og grensesnitt på hver side av pilene, kan enkelte utførelser ha informasjonsflyt kun i én retning (eller ingen informasjonsflyt som beskrevet nedenfor) eller kun ha et grensesnittsobjekt på én side. Som et eksempel, og ingen begrensning, er begreper som applikasjonsprogrammeringsgrensesnitt/applikasjonsprogram-grensesnitt (API), inngangspunkt, metode, funksjon, subrutine, RPC-anrop og komponentobjektmodell-(COM)-grensesnitt omfattet innenfor definisjonen av programmeringsgrensesnitt.

Aspekter ved et slikt programmeringsgrensesnitt kan omfatte på hvilken måte det første kodesegmentet sender informasjon (idet "informasjon" anvendes i sin mest generelle betydning og omfatter data, kommandoer, forespørsler, osv.) til det andre kodesegmentet; på hvilken måte det andre kodesegmentet mottar informasjonen; samt informasjonens oppbygning, sekvens, syntaks, organisering, skjema, timing og innhold. I denne henseende kan det underliggende transportmediet være uviktig for grensesnittets virkemåte, uavhengig av hvorvidt mediet er kablet, trådløst eller en kombinasjon av begge, så lenge informasjonen transporteres på den måten som defineres av grense snittet. I visse tilfeller trenger ikke informasjon bli sendt i den ene retningen eller begge retninger på tradisjonell måte, idet overføring av informasjon enten kan skje gjennom en annen mekanisme (f.eks. plassering av informasjon i et buffer, en fil, osv. separat fra informasjonsflyten mellom kodesegmentene) eller ikke forekomme, som når ett kodesegment bare aksesserer funksjoner som utføres av et annet kodesegment. Et hvilket som helst av eller alle disse aspektene kan være viktige i en gitt situasjon, f.eks. avhengig av hvorvidt kodesegmentene er del av et system med en løst koplet eller tett koplet oppbygning, slik at denne listen skal betraktes som illustrerende og ikke-begrensende.

Denne forestillingen om et programmeringsgrensesnitt er kjent for fagmannen, og fremgår tydelig av den foregående detaljerte beskrivelsen av oppfinnelsen. Det finnes imidlertid andre måter å realisere et programmeringsgrensesnitt, og dersom de ikke uttrykkelig utelukkes, er disse også ment å være omfattet av kravene som følger etter denne beskrivelsen. Slike andre måter kan synes mer avanserte eller kompliserte enn de overforenklede illustrasjonene i figurene 5 og 6, men de utfører ikke desto mindre en tilsvarende funksjon for å oppnå samme endelige resultat. Vi vil nå kort beskrive noen illustrerende, alternative realiseringer av et programmeringsgrensesnitt.

A. FAKTORISERING

En kommunikasjon fra ett kodesegment til et annet kan bevirkes indirekte ved å dele opp kommunikasjonen i flere atskilte kommunikasjoner. Dette er illustrert skjematisk 1 figurene 7 og 8. Som illustrert kan noen grensesnitt beskrives med hensyn til oppdele-lige sett av funksjonalitet. Grensesnittsfunksjonaliteten i figurene 5 og 6 kan således bli delt opp, men likevel gi samme resultat, akkurat som man matematisk kan skrive 24 som 2 ganger 2 ganger 3 ganger 2. Følgelig, som illustrert i figur 7, kan funksjonaliteten som tilbys av grensesnittet Interfacel deles opp for å konvertere kommunikasjonene i grensesnittet til et antall grensesnitt Interfacel A, Interfacel B, Interfacel C, osv. som gir samme resultat. Som illustrert i figur 8 kan funksjonaliteten som tilbys av grensesnittet 11 deles opp i flere grensesnitt 11a, 11b, 11c, osv. som gir samme resultat. Tilsvarende kan grensesnittet 12 i det andre kodesegmentet, som mottar informasjon fra det første kodesegmentet, deles opp i et antall grensesnitt I2a, I2b, I2c, osv. Etter oppdelingen trenger ikke antallet grensesnitt innlemmet i kodesegment 1 overensstemme med antallet grensesnitt innlemmet i kodesegment 2.1 eksemplene i figurene 7 og 8 forblir de funksjonelle trekkene til grensesnittene Interfacel og 11 henholdsvis de samme som i figurene 5 og 6. Oppdelingen av grensesnitt kan også følge assosiative, kommutative og andre matematiske trekk, slik at oppdelingen kan være vanskelig å se. For eksempel kan rekkefølgen for utførelse av operasjoner være uviktig, og følgelig kan en funksjon som utføres av et grensesnitt bli utført lenge før den kommer til grensesnittet, av et annet kodesegment eller grensesnitt, eller bli utført av en separat komponent i systemet. Dessuten vil en gjennomsnittlig programmerer vite at det finnes mange måter å gjøre forskjellige funksjonsanrop som oppnår samme resultat.

B. REDEFINISJON

I noen tilfeller kan det være mulig å ikke ta hensyn til, legge til eller omdefinere visse aspekter (f.eks. parametere) ved et programmeringsgrensesnitt og fortsatt oppnå det ønskede resultatet. Dette er illustrert i figurene 9 og 10. Anta for eksempel at grensesnittet Interfacel i figur 5 omfatter et funksjonsanrop Square( inndata, presisjon, utdata), et anrop som omfatter tre parametere: inndata, presisjon og utdata, og som gjøres fra kodesegment 1 til kodesegment 2. Dersom den midtre parameteren presisjon ikke har noen funksjon i et gitt scenario, som illustrert i figur 9, kunne den like gjerne blitt ignorert eller til og med erstattet med en meningsløs (i dette tilfellet) parameter. Man kan også legge til en ytterligere betydningsløs parameter. I alle tilfeller kan funksjonaliteten til funksjonen square oppnås så lenge utdata returneres etter at inndata er kvadrert av det andre kodesegmentet. Presisjon kan meget godt være en meningsfylt parameter for en nedstrøms eller annen del av databehandlingssystemet; når det innses at parameteren presisjon ikke er nødvendig for kvadreringsformålet, kan den imidlertid erstattes med noe annet eller ignoreres. For eksempel kan man i stedet for å sende med en gyldig presi-sjonsverdi sende med en meningsløs verdi så som en fødselsdagsdato uten å påvirke resultatet. Tilsvarende, som kan sees i figur 10, kan grensesnittet 11 bli erstattet med et grensesnitt 11', som er redefinert til ikke å ta hensyn til eller å legge til parametere i grensesnittet. Grensesnittet 12 kan på semme måte bli erstattet med et grensesnitt 12', som er redefinert til å ikke ta hensyn til unødvendige parametere eller parametere som kan prosesseres et annet sted. Poenget her er at et programmeringsgrensesnitt i noen tilfeller kan omfatte aspekter, så som parametere, som ikke er nødvendige for et gitt formål, som således kan ignoreres eller redefineres, eller prosesseres andre steder for andre formål.

C. INLINE-KODING

Det kan også være mulig å slå sammen noe av eller all funksjonaliteten til to adskilte kodemoduler, slik at "grensesnittet" mellom dem endrer form. Foreksempel kan funksjo- naliten i figurene 5 og 6 henholdsvis bli omgjort til funksjonaliteten i figurene 11 og 12.1 figur 11 er de tidligere kodesegmentene 1 og 2 i figur 5 slått sammen i en modul som inneholder begge. I dette tilfellet kan kodesegmentene fortsatt kommunisere med hverandre, men grensesnittet kan ha en form som er bedre egnet for den enkeltstående modulen. For eksempel trenger således ikke lenger formelle anrop- og retur-yttringer være nødvendig, men tilsvarende prosessering eller respons(er) i samsvar med grensesnittet Interfacel kan fortsatt bli utført. Tilsvarende, som kan sees i figur 12, kan deler av (eller hele) grensesnittet 12 i figur 6 skrives inline i grensesnittet 11 for å danne grensesnitt 11". Som illustrert er grensesnittet 12 delt inn i grensesnitt-andeler I2a og I2b, og grensesnitt-andelen I2a er kodet inline med grensesnittet 11 for å danne et grensesnitt 11". Som et konkret eksempel, anta at grensesnittet 11 i figur 6 gjør et funksjonsanrop square( inndata, utdata) som mottas av grensesnittet 12, som etter prosessering av verdien til inndata (for å kvadrere den) av det andre kodesegmentet returnerer det kvadrerte resultatet i utdata. I et slikt tilfelle kan operasjonen som utføres av det andre kodesegmentet (kvaderering av inndata) utføres av det første kodesegmentet uten å anrope grensesnittet.

D. FRASKILLING

En kommunikasjon fra ett kodesegment til et annet kan gjøres indirekte ved å dele opp kommunikasjonen i flere separate kommunikasjoner. Dette er illustrert skjematisk i figurene 13 og 14. Som kan sees i figur 13, er ett eller flere mellomliggende grensesnitt (fraskillingsgrensesnitt, siden de separerer funksjonalitet og/eller grensesnittsfunksjoner fra det opprinnelige grensesnittet) tilveiebragt for å tilpasse kommunikasjonene i det første grensesnittet, Interfacel, til et annet grensesnitt, i dette tilfellet grensesnittene lnterface2A, lnterface2B og lnterface2C. Dette kan for eksempel gjøres når det eksisterer en installert base av applikasjoner som er innrettet for å kommunisere med kode, så som et operativsystem, i henhold til en protokoll for Interfacel, men operativsystemet deretter endres til å anvende et annet grensesnitt, i dette tilfellet grensesnittene lnterface2A, lnterface2B og lnterface2C. Poenget er at det grensesnittet som opprinnelig ble anvendt av kodesegment 2 er endret, slik at det ikke lenger er kompatibelt med grensesnittet som anvendes av kodesegment 1 og at det derfor blir anvendt et mellomledd for å gjøre de gamle og nye grensesnittene kompatible. Tilsvarende, som kan sees i figur 14, kan det bli introdusert et tredje kodesegment med fraskillingsgrensesnittet DM for å motta kommunikasjonene fra grensesnittet 11 og med fraskillingsgrensesnittet DI2 for å over-føre grensesnittsfunksjonaliteten til for eksempel grensesnittene I2a og I2b, som er konstruert for å fungere med DI2, men likevel gi samme funksjonelle resultat. Tilsvarende kan DI1 og DI2 jobbe sammen for å oversette funksjonaliteten i grensesnittene 11 og 12 i figur 6 til et nytt operativsystem, mens de fortsatt gir samme eller tilsvarende funksjonelle resultat.

E. OMSKRIVING

Nok en annen mulighet er å dynamisk omskrive koden for å erstatte grensesnittsfunksjonaliteten med noe annet som gir det samme endelige resultatet. For eksempel kan det eksistere et system der et kodesegment presentert i et mellomspråk (f.eks. Microsoft IL, Java ByteCode, osv.) blir levert til en JIT-(Just-ln-Time)-kompilator eller - tolkemaskin i et kjøremiljø (så som det som tilveiebringes av .Net-rammeverket, Java Runtime Environment eller andre, tilsvarende "runtime"-type miljøer). JIT-kompilatoren kan være skrevet for dynamisk å omgjøre kommunikasjonene fra kodesegment 1 til kodesegment 2, dvs. å tilpasse dem til et annet grensesnitt som kan være nødvendig for kodesegment 2 (enten det opprinnelige eller et annet kodesegment 2). Dette er illustrert i figurene 15 og 16. Som kan sees i figur 15 er denne tilnærmingen tilsvarende fraskilling-scenariet beskrevet ovenfor. Den kan for eksempel benyttes når en installert base av applikasjoner er innrettet for å kommunisere med et operativsystem i henhold til en protokoll for Interfacel, men operativsystemet deretter endres til å anvende et annet grensesnitt. JIT-kompilatoren vil kunne brukes til fortløpende å tilpasse kommunikasjonene fra de installerte applikasjonene til operativsystemets nye grensesnitt. Som kan sees i figur 16 kan denne tilnærmingen med dynamisk å omskrive grensesnittet/grensesnittene også anvendes for dynamisk å dele opp eller på annen måte endre grensesnittet/grensesnittene.

Det bemerkes videre at de ovenfor beskrevne scenariene for å oppnå samme eller tilsvarende resultat som et gitt grensesnitt gjennom alternative utførelsesformer også kan kombineres på forskjellige måter, serielt og/eller parallelt, eller med annen innskutt kode. De alternative utførelsesformene beskrevet ovenfor er således ikke gjensidig utelukkende og kan blandes, tilpasses og kombineres for å frembringe de samme eller ekvivalente scenarier som de generiske scenariene illustrert i figurene 5 og 6. Det bemerkes også at, som med de fleste programmeringskonstruksjoner, det finnes andre tilsvarende måter å frembringe samme eller tilsvarende funksjonalitet i et grensesnitt som ikke nødvendigvis er beskrevet her, men som allikevel omfattes av oppfinnelsens ramme og idé. Mer spesifikt er det i hvert fall delvis funksjonaliteten som tilveiebringes og de fordelaktige resultatene som muliggjøres av et grensesnitt som representerer verdien til et grensesnitt.

Selv om oppfinnelsen har blitt beskrevet i språk som er spesifikt for oppbygnings-messige trekk og/eller trinn i fremgangsmåter, må det forstås at oppfinnelsen som definert i de etterfølgende patentkravene, ikke nødvendigvis er begrenset til de spesifikke trekk eller handlinger som er beskrevet. Snarere er de spesifikke trekk og handlinger beskrevet som eksempler på mulige utførelser av den krevede oppfinnelsen.

Claims (18)

1. Fremgangsmåte for å organisere et sett av typer i et enkelt hierarkisk navnerom for generering av presentasjoner av applikasjoner, dokumenter eller media i et programmeringsgrensesnitt, der fremgangsmåten omfatter følgende trinn: å opprette et flertall av grupper fra settet av typer, hver gruppe omfattende minst én type som eksponerer eller tilgjengeliggjør logisk beslektet funksjonalitet; å tilordne et navn til hver gruppe i flertallet av grupper, hvor en første gruppe (310) av flertallet omfatter funksjoner knyttet til generering av grafiske objekter, en annen gruppe (312) av flertallet omfatter funksjoner knyttet til formatering av innhold, og en tredje gruppe (314) av flertallet omfatter funksjoner knyttet til opprettelse av komponenter i de grafiske objektene, og å velge en toppnivå-identifikator og å prefikse navnet på hver gruppe med toppnivå-identifikatoren for å referere til typene i hver gruppe med et hierarkisk navn som omfatter den valgte toppnivå-identifikatoren prefikset foran navnet på gruppen som inneholder typen.

2. Fremgangsmåte ifølge krav 1, hvor den første gruppen, den andre gruppen og den tredje gruppen deler en felles programmeringsmodell.

3. Fremgangsmåte ifølge krav 1, hvor den første gruppen, den andre gruppen og den tredje gruppen anvender et felles formateringsspråk.

4. Fremgangsmåte ifølge krav 1, hvor den første gruppen, den andre gruppen og den tredje gruppen deler en felles hendelsessystem.

5. Fremgangsmåte ifølge krav 1, hvor den første gruppen, den andre gruppen og den tredje gruppen deler et felles system for definisjon av egenskaper.

6. Fremgangsmåte ifølge krav 1, hvor den første gruppen, den andre gruppen og den tredje gruppen deler en felles innmatingsmodell for å administrere og sørge for styring av forskjellige innmatingsanordninger.

7. Fremgangsmåte ifølge krav 1, hvor den første gruppen, den andre gruppen og den tredje gruppen deler et felles system for å neste elementer knyttet til en gitt gruppe innenfor elementer knyttet til en annen gruppe.

8. Fremgangsmåte ifølge krav 1, hvor den første gruppen omfatter en ytterligere funksjonalitet for å bestemme et fremtoningstrekk ved de grafiske objektene.

9. Fremgangsmåte ifølge krav 1, hvor den første gruppen omfatter en ytterligere funksjonalitet for å bestemme en oppførsel som utvises av de grafiske objektene.

10. Fremgangsmåte ifølge krav 1, hvor den første gruppen omfatter en ytterligere funksjonalitet for å bestemme en anordning av de grafiske objektene.

11. Fremgangsmåte ifølge krav 1, hvor den første gruppen omfatter et flertall av nestede elementer som definerer de grafiske objektene.

12. Fremgangsmåte ifølge krav 1, hvor de grafiske objektene utgjøres av ett eller flere elementer definert av vektorgrafikk.

13. Fremgangsmåte ifølge krav 1, hvor den første gruppen omfatter en ytterligere funksjonalitet for å definere vindusegenskaper i et formateringsspråk uten å starte opp ett nytt vindu.

14. Fremgangsmåte ifølge krav 1, hvor den første gruppen omfatter en ytterligere funksjonalitet for å generere et brukergrensesnitt som inneholder et flertall av grafiske objekter.

15. Fremgangsmåte ifølge krav 1, hvor den andre gruppen omfatter videre funksjoner for å arrangere eller anordne de grafiske objektene.

16. System for tilgjengeliggjøring eller eksponering av sett av funksjoner organisert i et enkelt hierarkisk navnerom i et programmeringsgrensesnitt, der systemet omfatter: midler for tilgjengeliggjøring av et første sett (310) av funksjoner som muliggjør generering av grafiske objekter; midler for tilgjengeliggjøring av et andre sett (312) av funksjoner som muliggjør formatering av innhold for fremvisning, og midler for tilgjengeliggjøring av et tredje sett (314) av funksjoner som muliggjør opprettelse av komponenter i de grafiske objektene, der komponentene i de grafiske objektene omfatter et antall av geometriske former, og der det første settet av funksjoner, det andre settet av funksjoner og den tredje sett av funksjoner deler en felles programmeringsmodell.

17. System ifølge krav 16, hvor det første settet av funksjoner, det andre settet av funksjoner og det tredje settet av funksjoner anvender et felles formateringsspråk.

18. System ifølge krav 16, hvor det første settet av funksjoner, det andre settet av funksjoner og det tredje settet av funksjoner deler et felles hendelsessystem og et felles system for definisjon av egenskaper.