Artikkelen fortsetter serien "Første trinn i utviklingen på 1C", den diskuterer i detalj følgende problemer:

• Hva er en programvaremodul og hvilke deler består den av?
• Hva er applikasjonsmodulen for? Hvorfor er det to av dem? Når lanseres hvilken? Hva er subtilitetene i verket?
• Hvilke hendelser er knyttet til oppstart av systemdrift, hvordan og hvor skal de behandles?
• Hva er den eksterne tilkoblingsmodulen til? Når og hvordan bruke det?
• Når brukes øktmodulen?
• Hva er vanlige moduler? Hva er dens egenskaper og driftsregler? Hvorfor bruke egenskapen «Gjenbruk av returverdier»?
• Når brukes skjemamodulen og hvilke hendelser kan behandles i den?
• Hva er objektmodulen til? Hvilke seksjoner består den av? Hvordan se tilgjengelige modulhendelser?
• Hva er finessene ved å jobbe med verdihåndteringsmoduler (for konstanter) og rekordsettmoduler (for registre)?
• Hva er forskjellene mellom en objektmodul og en ledermodul? Når bør du bruke sistnevnte?

Anvendbarhet

Artikkelen diskuterer 1C:Enterprise-plattformen 8.3.4.496. Materialet er også relevant for aktuelle plattformutgivelser.

Moduler i "1C:Enterprise 8.3"

Moduler er de objektene som inneholder programkode.

Det er et ganske stort antall typer moduler i plattformen, som hver har sitt eget formål og funksjoner.

Enhver kodelinje må være i en modul. Det er generelle moduler og objektmoduler. Noen moduler kan kompileres på både klienten og serveren, og noen kun på serveren.

En modul kan bestå av flere seksjoner. Variabelbeskrivelsesdelen beskriver lokale variabler for denne modulen, som senere kan brukes i enhver prosedyre.

Innenfor hver prosedyre kan du få tilgang til en modulvariabel. I tillegg kan det innenfor selve prosedyren være en annen variabeldeklarasjon med samme navn. Dette vil være en lokal variabel i denne prosedyren.

Til tross for samme navn er dette to forskjellige variabler: den ene brukes i en bestemt prosedyre, og den andre brukes utenfor den.

I noen moduler kan variabler indikere plasseringen av kompilering (tilgjengelighet) på serveren eller på klienten. For eksempel:

Avsnittet som beskriver variabler etterfølges av et avsnitt med prosedyrer og funksjoner, hvor lokale metoder for denne modulen er indikert. Noen moduler må spesifisere hvor prosedyren eller funksjonen skal kompileres.

I utgangspunktet kan sammenstillingsdirektivet utelates. I dette tilfellet er standard kompileringsdirektiv Server. For å gjøre det enklere å analysere programkode, anbefales det imidlertid å eksplisitt angi hvor en gitt prosedyre vil bli kompilert. Rekkefølgen prosedyrene beskrives i spiller ingen rolle.

På slutten av modulen, etter å ha beskrevet alle prosedyrene og funksjonene, er det en del av hovedprogrammet, som kan inneholde noen operatører og initialisere lokale variabler i skjemamodulen. Denne delen utføres når du får tilgang til modulen.

Så, for eksempel, når du åpner et elementskjema, kjøres hovedprogramdelen av skjemamodulen først.

Det skal bemerkes at variabeldeklarasjonsdelen og hovedprogramdelen ikke eksisterer for alle moduler (dvs. disse delene er ikke gyldige i enkelte moduler). En seksjon for å beskrive prosedyrer og funksjoner kan eksistere i absolutt alle moduler.

Applikasjonsmodul

Denne modulen er utviklet for å håndtere hendelser med oppstart og avslutning av applikasjoner. For eksempel, når du starter programmet, kan du laste ned valutakurser fra Internett. Når du avslutter en applikasjon, kan du bekrefte med brukeren at han eller hun har til hensikt å avslutte.

Også i applikasjonsmodulen er det spesielle behandlere som lar deg avskjære eksterne hendelser fra utstyret.

Dette kan være hendelser fra en magnetisk kortleser eller skatteregistrator. Og disse hendelsene kan også bearbeides på en eller annen måte.

Vær oppmerksom på at det er den interaktive oppstarten av systemet som overvåkes i applikasjonsmodulen.

Applikasjonsmodulen vil ikke fungere hvis 1C-programmet startes, for eksempel i com-tilkoblingsmodus. I dette tilfellet opprettes ikke programvinduet.

Det skal bemerkes at i Platform 8.3 er det to forskjellige applikasjonsmoduler: Managed Application-modulen og Regular Application-modulen. Administrerte applikasjonsmodulhendelser behandles når den tynne og tykke klienten for administrert applikasjon og nettklient startes.

Modul Vanlig søknad fungerer når du kjører den tykke klienten i modus Vanlig søknad, som inneholder det vanlige kommandogrensesnittet i skjemaet Hovedmeny.

Hvis applikasjonen kjører inn Fikk til, og i modus Vanlig søknad, så er det nødvendig å beskrive behandlerprosedyrene som for modulen Administrert applikasjon, og for modulen Vanlig søknad.

Modul Administrert applikasjon kan velges fra kontekstmenyen til rotkonfigurasjonsnoden.

Denne modulen kan også åpnes fra egenskapspaletten til rotkonfigurasjonselementet.

For å åpne en modul Vanlig søknad, bør du se konfigurasjonsinnstillingene (kommando Alternativer på menyen Service).

Skjemaet åpnes Alternativer. På bokmerket Er vanlig Konfigurasjonsredigeringsmodus må spesifiseres Administrert applikasjon Og Vanlig søknad.

I dette tilfellet modulen Vanlig søknad det vil også være mulig å åpne fra egenskapene til rotnoden.

Liste over hendelser som kan behandles for Fikk til Og Vanlig søknad er lik.

Denne modulen kan inneholde en variabel deklarasjonsdel, en beskrivelsesdel av vilkårlige prosedyrer og funksjoner, og en hovedprogramdel. Men i tillegg til vilkårlige prosedyrer og funksjoner, kan spesielle hendelsesbehandlere lokaliseres i modulen.

Listen over tilgjengelige behandlere kan vises ved å kalle opp listen over prosedyrer og funksjoner for gjeldende modul når modulen er åpen.

Vinduet Prosedyrer og funksjoner som åpnes viser alle prosedyrene og funksjonene til denne modulen, samt hendelser som behandlere ennå ikke er opprettet for.

Det er to hendelser knyttet til starten av systemet ("før" og "ved"). To hendelser knyttet til systemavslutning ("før" og "ved"). Og også behandling av eksterne hendelser (for eksempel hendelser med kommersielt utstyr).

Når en "før" hendelsesbehandler blir utført, anses handlingen for å ikke ha funnet sted ennå. Når hendelsesbehandleren "at" er utført, er handlingen allerede fullført.

Begivenhet Før du starter systemet oppstår i det øyeblikket Enterprise 8.3 er lansert, men selve applikasjonen har ennå ikke dukket opp på skjermen. Denne hendelsen har følgende parameter: Avslag.

Hvis denne parameteren tar verdien ekte, vil ikke applikasjonen starte. Begivenhet Når du starter systemet forutsetter at handlingen allerede er fullført, vinduet er allerede opprettet, og i dette tilfellet kan vi for eksempel vise et spesielt skjema. Det er ikke lenger mulig å nekte oppskytingen.

På samme måte, før du slår av systemet, er applikasjonen fortsatt åpen, og du kan nekte å lukke den. Når systemet slås av, er programvinduet allerede lukket. Det er bare mulig å utføre ytterligere handlinger, for eksempel å slette noen filer eller sende en e-post.

I modulen Administrert applikasjon Direktiv for kompilering av prosedyrer og funksjoner er ikke spesifisert, siden modulen i sin helhet er kompilert på klientsiden. Dette betyr at vi i prosedyrene og funksjonene til modulen ikke vil kunne få direkte tilgang til for eksempel oppslagsverk.

Hvis fra modul Administrert applikasjon trenger å foreta et serveranrop, så for dette må du opprette spesielle med et flagg .

I modulen Vanlig søknad Det er ingen slike begrensninger, siden denne modulen vil bli kompilert når du laster den tykke klienten. Nesten alle typer data er tilgjengelige i den tykke klienten.

Prosedyrer, funksjoner og variabler til en applikasjonsmodul kan beskrives som eksporter.

Siden modulen er kompilert utelukkende på klienten, betyr dette at vi i klientprosedyrer kan få tilgang til denne metoden og denne egenskapen.

Du kan for eksempel kalle en prosedyre eller funksjon til en applikasjonsmodul fra skjemamodulen til et objekt. Det anbefales imidlertid å bruke vanlige moduler for å beskrive generelle algoritmer. Hovedformålet med applikasjonsmodulen er å behandle startpunkt og sluttpunkt.

I analogi med en applikasjonsmodul er denne modulen designet for å behandle programåpningshendelsen og avslutningshendelsen.

I motsetning til applikasjonsmodulen, som startes i øyeblikket av interaktiv oppstart av applikasjonen, fungerer den eksterne tilkoblingsmodulen i COM-tilkoblingsmodus, dvs. når et 1C:Enterprise 8-objekt opprettes og kobles til en bestemt database.

Denne modulen har hendelser: Når du starter systemet Og Ved systemavslutning.

Den eksterne tilkoblingsmodulen kan åpnes ved å bruke enten kontekstmenyen på rotkonfigurasjonsobjektnivået, eller egenskapspaletten for rotnoden.

Selve prosessen med ekstern tilkobling er en prosess med programmatisk arbeid med informasjonsbasen, og ikke interaktiv. Følgelig kan du for øyeblikket ikke bruke dialogskjemaer eller vise advarselsmeldinger, siden det ikke er noe brukergrensesnitt.

I External Connection Module er det mulig å beskrive eksportvariabler og eksportmetoder som vil være tilgjengelige på siden hvor det eksterne kallet til 1C:Enterprise 8.3 skjer.

Siden det ikke er noe brukergrensesnitt i en ytre sammenføyning, er Outer Join-modulen kompilert utelukkende på serveren.

Sesjonsmodul

Denne modulen er nødvendig for å initialisere øktparametere. Sesjonsparametere er raske globale variabler hvis verdier er tilgjengelige hvor som helst i konfigurasjonen.

Du kan åpne sesjonsmodulen enten gjennom kontekstmenyen eller gjennom egenskapspaletten til rotnoden.

Sesjonsmodulen gir en hendelse SettingSessionParameters.

Når applikasjonen starter, kalles denne prosedyren først. Sesjonsparametere er nødvendige for enhver applikasjonsoperasjon: både når den startes interaktivt og når den startes i ekstern tilkoblingsmodus.

Sesjonsmodulen beskriver ulike handlinger for å initialisere sesjonsparametere avhengig av ulike forhold.

Denne modulen beskriver som regel flere prosedyrer som kalles opp fra prosedyren SettingSessionParameters. Derfor er alle disse prosedyrene delt inn i en egen modul.

Sesjonsmodulen kjører alltid i privilegert modus. Dette betyr at ingen tillatelsessjekk vil bli utført når du får tilgang til databasen. Sesjonsmodulen er kompilert på Serveren, dvs. Det er mulig å få tilgang til alle servermetoder (inkludert lesing av verdier fra databasen).

I Session Module er det mulig å definere kun prosedyrer og funksjoner, dvs. det er ingen variabelbeskrivelsesdel og ingen hovedprogramdel. Du kan ikke definere eksportmetoder i en øktmodul.

Hvis det, når du starter systemet, er nødvendig å utføre noen handlinger på serveren, for eksempel å lage et element i en katalog, er det som et alternativ mulig å bruke sesjonsmodulen, fordi den er kompilert på serveren og utføres alltid pålitelig ved systemstart. Følgende punkter må imidlertid tas i betraktning:

• fremgangsmåte SettingSessionParameters utføres ikke bare ved oppstart av systemet, men også ved tilgang til uinitialiserte sesjonsparametere. De. SetSessionParameters-behandleren kan kalles gjentatte ganger under applikasjonsdrift;
• hvis antall elementer i sesjonsparametermatrisen er null (matrisen av nødvendige parametere har en datatype Udefinert), så er dette øyeblikket applikasjonen startes;
• siden sesjonsmodulen opererer i privilegert modus og det ikke vil være noen kontroll av tilgangsrettigheter, bør du arbeide veldig nøye med databaseobjekter, siden brukeren kan få tilgang til data som ikke skal gis til ham;
• Når systemet starter, er det ennå ikke kjent med sikkerhet om applikasjonen vil bli lansert. I dette tilfellet kan unødvendige handlinger utføres i hendelsesbehandleren SetSessionParameters.

Disse modulene representerer en beskrivelse av noen generelle algoritmer, dvs. prosedyrer og funksjoner som kan kalles opp fra ulike steder.

Logisk relaterte metoder kan grupperes i forskjellige vanlige moduler. Disse modulene er opprettet i General-grenen.

Du kan legge til et hvilket som helst antall delte moduler. For å gjøre Common Module-metoder tilgjengelige andre steder i konfigurasjonen, må de defineres med nøkkelordet Eksporter. Klientprosedyrer for vanlige moduler vil være tilgjengelige på klienten, og servere - på serveren.

I generelle moduler er kun delen som beskriver prosedyrer og funksjoner tilgjengelig. De. i General Module kan du ikke beskrive variabler og du kan ikke beskrive en del av hovedprogrammet.

Hvis en global variabel er nødvendig, kan du bruke enten sesjonsparametere ellerr.

For generelle moduler kan du angi noen parametere som vil påvirke oppførselen til denne modulen. Hvis den globale egenskapen er angitt for en generell modul, vil eksportmetodene som er deklarert i denne modulen være tilgjengelige direkte utenfra, uten ytterligere instruksjoner.

De. de Generell modul vil delta i dannelsen av den globale konfigurasjonskonteksten.

Eiendom Global for generelle moduler kan det være nyttig. Du bør imidlertid ikke bruke den overalt for alle vanlige moduler.

De , som er merket med skiltet Global, vil bli kompilert ved systemstart. Jo flere slike moduler, jo tregere starter programmet.

Hvis flagget Global Til Generell modul ikke er spesifisert, vil kompilering av denne modulen bli utført på tidspunktet for det første kallet til den (dvs. etter at systemet starter).

I tillegg påvirker bruken av globale fellesmoduler forståelsen av koden. Metoder for en ikke-global felles modul kalles gjennom navnet Generell modul og navnet på metoden, for eksempel:
Cost Calculation Module.DistributeIndirectCosts();

I dette tilfellet må navnene på vanlige moduler gjenspeile innholdet i prosedyrene beskrevet i dem. Å spesifisere navnet på fellesmodulen når du kaller en prosedyre hjelper deg med å forstå koden bedre.

Til Generell modul V Egenskaper palett du kan angi egenskapen Priviligert.

Den privilegerte modulen kontrollerer ikke tilgangsrettigheter. Dette er nødvendig hvis Generell modul Det er nødvendig å utføre massedatabehandling, hente data fra databasen.

Å kontrollere tilgangsrettigheter øker tiden det tar å få tilgang til en database, og massealgoritmer må ofte fungere så raskt som mulig.

For eksempel er lønn en ressurskrevende operasjon. Det må gjøres så raskt som mulig. For å gjøre dette, er algoritmer som beregner lønn plassert i privilegert .

Samtidig ligger alle prosedyrer som sikrer utfylling av lønnsdokumenter utenfor disse Vanlige moduler. Det er i disse prosedyrene at tilgangsrettighetskontrollen utføres.

På denne måten kan betydelige ytelsesforbedringer oppnås. Dette gjelder spesielt når du bruker en mekanisme for rad-for-rad tilgangskontroll til tabellposter.

Hvis en fellesmodul er privilegert, kan prosedyrene for denne modulen kun kompileres på serveren.

Det er situasjoner der et objekt skal være utilgjengelig for brukeren, for eksempel en bestemt katalog. Men når du utfører et dokument, er det nødvendig å referere til denne oppslagsboken.

De. Det er behov for å utvide brukerrettighetene midlertidig og deretter returnere dem til sin opprinnelige tilstand. Denne effekten kan oppnås ved å bruke privilegert Vanlige moduler.

For å gjøre dette i en privilegert Generell modul bør du opprette en prosedyre som gir tilgang til de nødvendige dataene.

Denne prosedyren vil bli kalt fra det tilsvarende dokumentet. De. brukeren gis faktisk utvidede rettigheter på det tidspunktet denne prosedyren kalles.

Til Vanlige moduler Det er mulig å spesifisere kompileringsstedet. Flaggene brukes til å bestemme om fellesmodulen vil være tilgjengelig på klienten (administrert applikasjon), på serveren eller i ekstern tilkoblingsmodus.

I tillegg, hvis du bytter konfigurasjonsredigeringsmodus til Administrert applikasjon og vanlig applikasjon, vil en annen kompileringskontekst være mulig - Klient (vanlig applikasjon).

Dermed er det fire alternativer for hvordan programmet fungerer. Avhengig av applikasjonen som kjører, avhengig av arbeidet på klienten eller på serveren, vil visse fellesmoduler være tilgjengelige eller utilgjengelige.

I tillegg til muligheten til å spesifisere kompileringsflagg, er det mulig å spesifisere kompileringsdirektiver for prosedyrer og funksjoner som ligger i fellesmodulen.

Hvis et kompileringsdirektiv er spesifisert for en metode, så vil selv om Common Module er tilgjengelig i alle spesifiserte sammenhenger, tilgjengeligheten til den spesifikke metoden være begrenset av kompileringsdirektivet.

I dette tilfellet kan ikke prosedyren nås i en kontekst som ikke er tilgjengelig for hele modulen.

Hvis du ikke spesifiserer et kompileringsdirektiv for en prosedyre (funksjon), vil det bli kompilert i alle kontekster som er definert for modulen.

De. I hovedsak vil det bli laget flere kopier av prosedyren. Valget av en bestemt kompilert instans avhenger av hvor prosedyren kalles (av den nærmeste kalleregelen). Det bør tas i betraktning at koden for en slik prosedyre må skrives under hensyntagen til tilgjengeligheten i alle sammenhenger definert for modulen.

Generiske moduler som samtidig er tilgjengelige i flere ulike kontekster er primært designet for å lage prosedyrer som er tilgjengelige i flere sammenhenger.

Når du oppretter en felles modul, anses det som god praksis å ikke spesifisere kompileringsdirektiver. De. Tilgjengeligheten av prosedyrer og funksjoner bør bestemmes av egenskapene til selve modulen.

Med denne tilnærmingen vil klientprosedyrer være plassert i separate fellesmoduler, og serverprosedyrer vil bli plassert i separate fellesmoduler.

Moduler som har flere kompileringsflagg satt brukes ekstremt sjelden i praksis. Dette er noen vanlige handlinger tilgjengelig på både klient og server. Vanligvis er dette noen enkle beregninger.

Viktig! Det er mulig for klienten å få tilgang til eksportservermetoder for en fellesmodul, men bare hvis denne fellesmodulen kun er kompilert på serveren. I dette tilfellet er det gitt et spesielt flagg for å sikre tilgang fra klienten .

For ikke-globale Common-moduler er det mulig å cache verdiene som returneres av funksjoner. De. Etter det første kallet til en funksjon, kan systemet huske resultatet av dens utførelse. Hvis denne funksjonen kalles opp igjen med de samme parameterne, vil systemet returnere verdien fra cachen.

Hensikten med denne mekanismen er å fremskynde gjentatte anrop. For å konfigurere denne virkemåten må du Egenskaper palett modul, angi riktig verdi for Gjenbruk av returverdier-egenskapen.

Som standard er denne egenskapen satt til Ikke bruk. Andre mulige verdier: cache Under samtalen, eller For varigheten av økten.

Denne egenskapen er fornuftig å bruke bare for de funksjonene hvis resultater avhenger utelukkende av inngangsparameterne. Denne mekanismen er kun tilgjengelig for ikke-globale fellesmoduler.

Hvis verdien til den korresponderende parameteren For varigheten av samtalen er valgt, vil hurtigbufferen fungere så lenge prosedyren som General Module-metoden ble kalt fra, kjører. Hvis verdien for varigheten av økten er valgt, antas det betinget at hurtigbufferen vil fungere mens brukeren jobber.

Det er imidlertid visse tidsbegrensninger. Bufferen tømmes automatisk 20 minutter etter at verdien kommer inn i hurtigbufferen.

Skjemamodul

Denne modulen er utviklet for å behandle brukerhandlinger. Beskriv for eksempel algoritmen for hvordan et program reagerer når en knapp trykkes. Eller, for eksempel, i øyeblikket du legger inn en verdi i et felt, sjekk umiddelbart for riktighet.

I tillegg til hendelser knyttet til skjemakontroller (knapper, inndatafelt), er det hendelser knyttet direkte til selve skjemaet.

Du kan for eksempel håndtere skjemaets åpningshendelse og utføre en initial initialisering. Du kan også håndtere skjemalukkingshendelsen og sjekke om brukeren har skrevet inn alt riktig.

Det er kontrollerte skjemaer og vanlige skjemaer. Modulene til disse skjemaene skiller seg først og fremst ved at den administrerte skjemamodulen er tydelig delt inn i kontekst. Hver prosedyre (funksjon) må ha et kompileringsdirektiv. I normal form brukes all kode på Klienten.

I en administrert skjemamodul kan du deklarere prosedyrer og funksjoner, du kan deklarere variabler og du kan beskrive en del av hovedprogrammet.

Programkoden til hovedprogrammet vil bli utført på tidspunktet for initialisering av skjemaet, dvs. når brukeren begynner å åpne den. Figuren viser en liste over standardhendelser for et administrert skjema.

Listen over hendelser for et administrert skjema er også synlig i listen over egenskaper direkte for selve skjemaet. Denne listen kalles opp i redigeringsprogrammet for administrerte skjemaer.

I et administrert skjema kan du håndtere elementets skrivehendelse. Denne hendelsen er kun til stede for objektskjemaer (kataloger, dokumenter og noen andre). Hvis skjemaet ikke er bundet til et spesifikt objekt, er det ingen skrivehendelse.

For en modul av vanlig form er listen over standardhendelser noe mindre, fordi I en administrert form lages mange hendelser for å pares (en utføres på klienten og den andre på serveren). I sin normale form blir all kode utført på klienten.

Objektmodul

Disse modulene er typiske for kataloger, dokumenter, planer for typer beregninger, kontoplaner og mange andre objekter. Objektmodulen er designet for å håndtere standardhendelser. For eksempel en hendelse for å legge inn et katalogelement, en hendelse for å skrive et element, slette, legge inn et dokument, etc.

I prinsippet eksisterer skrivehendelsen også i skjemamodulen. Men skrivehendelsen i skjemamodulen skjer under den interaktive opptaksprosessen, når du arbeider med et spesifikt skjema.

Skrivehendelsen i objektmodulen vil bli utført på enhver skriving fra hvilken som helst form for det gitte objektet. I tillegg, hvis objektet er skrevet programmatisk, vil objektets modulhendelse utløses.

I skrivehendelsen til objektmodulen kan du bygge inn alle kontroller for riktigheten av dataene som skrives, siden denne prosedyren vil bli utført på tidspunktet for absolutt ethvert opptak.

Modulen til dette objektet kan kalles opp gjennom kontekstmenyen, fra objektegenskapspaletten og fra objektredigeringsvinduet.

Figuren nedenfor viser en liste over tilgjengelige katalogmodulhendelser.

I Objektmodulen kan du plassere en seksjon for å beskrive variabler, for å beskrive vilkårlige funksjoner som kanskje ikke er knyttet til en hendelse, samt en seksjon av hovedprogrammet.

I hovedprogramdelen kan du for eksempel initialisere lokale variabler for en gitt modul. Denne programkoden vil bli utført når denne objektmodulen åpnes.

Det skal bemerkes at alle prosedyrer for objektmodulen er kompilert på serveren. Følgelig er det ikke nødvendig med kompileringsdirektiver for prosedyrer og funksjoner til objektmodulen. Noen konfigurasjonsobjekter har ikke objektmoduler.

Dette skyldes egenskapene til selve gjenstandene. Slike gjenstander inkluderer Konstanter Og Registrerer. Til Konstant det er ingen objektmodul, men det er en veldig lignende modul kalt Verdiforvaltermodul.

I Verdiforvaltermodul du kan håndtere skrivehendelser Konstanter og fyllingsverifiseringsbehandling.

Hele modulkonteksten kjøres på serveren.

For registre er det en Recordset Module.

Denne modulen har også muligheten til å håndtere skrivehendelser og utføre beleggskontroller.

I Object Modules, Value Manager Modules (for konstanter) og Recordset Modules (for registre) kan du beskrive metoder som kan gjøres eksporterbare, og disse metodene vil være tilgjengelige fra utsiden.

De. I tillegg til å bruke de faste metodene til en objektklasse, kan du opprette flere metoder for et objekt i objektmodulen. Denne modulen skal beskrive den tilsvarende prosedyren med nøkkelordet Eksport.

Da vil det være mulig å få tilgang til denne prosedyren utenfra. Dessuten vil denne metoden vises i kontekstverktøytipset. Nye metoder i kontekstverktøytipset er uthevet med blå skrift (blått ikon p() for prosedyrer og f() for funksjoner).

På samme måte kan du opprette en ny egenskap ved å deklarere en variabel med nøkkelordet Eksport. Denne eiendommen kan også nås fra utsiden.

På denne måten er det mulig å utvide funksjonaliteten til objekter (å definere nye metoder og nye egenskaper). Egenskapene er imidlertid dynamiske og lagres ikke i databasen.

Hvis du trenger å bruke en egenskap for et objekt som skal lagres i databasen, bør du opprette et objektattributt.

Ledermodul

Denne modulen finnes for mange objekter (kataloger, dokumenter, registre osv.). Modulen åpnes enten gjennom kontekstmenyen for objektet eller gjennom Egenskaper palett, eller gjennom redigeringsvinduet.

I Manager-modulen kan du overstyre noen standardhendelser, for eksempel i BehandlerReceivingSelectionData, når et element er valgt fra katalogen, kan noe ekstra filtrering eller kontroll gjøres.

I tillegg kan du opprette flere metoder i Manager-modulen og angi at de er eksportmetoder. I dette tilfellet er det mulig å få tilgang til disse metodene utenfra.

For å utføre denne samtalen er det nødvendig å få tak i datatypen DirectoryManager.

Forskjellen mellom eksportmetodene til ledermodulen og objektmodulen er at for å få tilgang til metoden til objektmodulen, må du først skaffe selve objektet (det vil si på en eller annen måte skaffe en kobling og deretter konvertere denne koblingen til et objekt) .

Etter dette vil eksportvariabler og metoder for objektmodulen være tilgjengelige. For Manager-modulen er samtalen enklere, for eksempel:
Kataloger.Motparter.Metodenavn

Dette er to forskjellige appeller. Konverter fra referanse til objekt (metode GetObject) er en ganske alvorlig handling for systemet, siden når du mottar et objekt, leses absolutt alle dataene til dette objektet, noe som kan være ganske langvarig.

Den andre forskjellen er det Objektmodul kalles i sammenheng med et bestemt element. Følgelig kan vi anta at det er aktuelt for et gitt element (i de fleste tilfeller er dette nøyaktig logikken som brukes).

Når det gjelder Manager-modulen, beskriver den en vanlig handling for en gruppe eller for alle elementer i en katalog eller et dokument. Hvis du for eksempel trenger å skrive ut et katalogelement, kan du bruke objektmodulen.

Men i Manager-modulen er det mulig å lage en mer universell mekanisme som vil skrive ut blant annet en gruppe elementer.

I tillegg er tilgang til objektmodulen fortsatt en lengre handling. Derfor er det mer å foretrekke å løse dette problemet i managermodulen.

Dette avslutter vårt bekjentskap med modulene i 1C:Enterprise-systemkonfigurasjonen. Hvis vi kort oppsummerer alt ovenfor, er bunnlinjen følgende konklusjoner:

• En programvaremodul er en del av konfigurasjonen som kun kan inneholde tekst på det innebygde 1C-språket
• Programvaremoduler er klassifisert i henhold til typene vi diskuterte i denne artikkelen. Hver visning bestemmes av plasseringen og tilgjengelig programkontekst.
• Strukturen til modulen består av flere seksjoner, som er ordnet i en bestemt rekkefølge. Sammensetningen av seksjoner bestemmes av type modul.

Merk også at vi med vilje har utelatt én type modul, nemlig kommandomodulen. Det er ikke noe bemerkelsesverdig, og vi inviterer deg til å gjøre deg kjent med funksjonaliteten.

Så langt har vi vurdert all programkoden vår separat fra applikasjonsløsningen, og som regel skrev vi den i en egen liten testkonfigurasjon. Er du klar over at "du kan ikke bare gå" og begynne å redigere koden til en standardkonfigurasjon? Nei? Så i den neste artikkelen vil vi forklare det hele!

1.1. Felles moduler er laget for å implementere prosedyrer og funksjoner forent i henhold til noen karakteristika. Som regel er prosedyrer og funksjoner for ett konfigurasjonsdelsystem (salg, innkjøp) eller prosedyrer og funksjoner med lignende funksjonalitet (arbeid med strenger, generell formål) plassert i en felles modul.

1.2. Når du utvikler delte moduler, bør du velge en av fire kodeutførelseskontekster:

	Vanlig modultype	Eksempel på navn	Serveranrop	Server	Ytre skjøt	Klient (vanlig søknad)	Klient (administrert applikasjon)
1.	Server	General Purpose (eller General Purpose Server)
2.	Server å ringe fra klient	GeneralPurposeCallServer
3.	Klient	General Purpose Client (eller General Purpose Global)
4.	Klient server	General PurposeClientServer

2.1. Server felles moduler er ment å være vert for serverprosedyrer og funksjoner som ikke er tilgjengelige for bruk fra klientkode. De implementerer all den interne server forretningslogikken til applikasjonen.
For korrekt drift av konfigurasjonen i ekstern tilkobling, administrerte og vanlige applikasjonsmoduser, serverprosedyrer og funksjoner bør plasseres i vanlige moduler med følgende egenskaper:

• Server(avmerkingsboks Serveranrop nullstille),
• Klient (vanlig søknad),
• Ytre skjøt.

I dette tilfellet er muligheten til å kalle serverprosedyrer og funksjoner med parametere av mutable typer garantert (for eksempel, DirectoryObject, DocumentObject og så videre.). Vanligvis er dette:

• behandlere for abonnementer på hendelser av dokumenter, kataloger osv., som tar en mutbar verdi (objekt) som parameter.
• serverprosedyrer og -funksjoner, som et objekt sendes til som en parameter fra moduler av kataloger, dokumenter osv., samt fra moduler med hendelsesabonnement.

Delte moduler på serversiden er navngitt i henhold til generelle regler for navngivning av metadataobjekter.
For eksempel: Arbeide med filer, Generelt formål

I noen tilfeller kan en postfix legges til for å forhindre navnekonflikter med globale kontekstegenskaper "Server".
For eksempel: RutineTasksServer, Data ExchangeServer.

2.2. Server vanlige moduler for anrop fra klient inneholde serverprosedyrer og funksjoner som kan brukes fra klientkode. De utgjør ktil applikasjonsserveren.
Slike prosedyrer og funksjoner er plassert i vanlige moduler med følgende funksjon:

• Server(avmerkingsboks Serveranrop installert)

Server-side vanlige moduler for å ringe fra en klient navngis i henhold til de generelle reglene for navngivning av metadataobjekter og må navngis med en postfix "CallServer".
For eksempel: Arbeide med FilesCalling Server

Vær oppmerksom på at eksportprosedyrer og -funksjoner i slike delte moduler ikke må inneholde parametere av mutable typer ( DirectoryObject, DocumentObject etc.), siden deres overføring fra (eller til) klientkode er umulig.

Se også:Begrensning på innstilling av "Server Call"-flagget for vanlige moduler

2.3. Klientens fellesmoduler inneholder klientforretningslogikk (funksjonalitet definert kun for klienten) og har følgende egenskaper:

• Klient (administrert applikasjon))
• Klient (vanlig søknad)

Unntaket er når klientprosedyrer og -funksjoner bare må være tilgjengelige i administrert applikasjonsmodus (kun i vanlig applikasjonsmodus eller bare i ekstern tilkoblingsmodus). I slike tilfeller er en annen kombinasjon av disse to egenskapene akseptabel.

Vanlige klientmoduler er navngitt med en postfix "Klient".
For eksempel: Arbeide med FilesClient, General Purpose Client

Se også: minimere kode som kjører på klienten

2.4. I noen tilfeller er det tillatt å lage klient-server felles moduler med prosedyrer og funksjoner, hvis innhold er det samme på både serveren og klienten. Slike prosedyrer og funksjoner er plassert i vanlige moduler med følgende egenskaper:

• Klient (administrert applikasjon)
• Server(avmerkingsboks Serveranrop nullstille)
• Klient (vanlig søknad)
• Ytre skjøt

Vanlige moduler av denne typen er navngitt med postfix "Klient server".
For eksempel: Arbeide med FilesClient, General PurposeClientServer

Generelt anbefales det ikke å definere vanlige moduler for både serveren og klienten (administrert applikasjon). Det anbefales å implementere funksjonalitet definert for klienten og for serveren i forskjellige vanlige moduler - se avsnitt. 2.1 og 2.3. Denne eksplisitte separasjonen av klient- og servervirksomhetslogikk er diktert av hensyn til å øke modulariteten til applikasjonsløsningen, forenkle utviklerkontroll over klient-server-interaksjon og redusere risikoen for feil på grunn av grunnleggende forskjeller i kravene til utvikling av klient og server. kode (behovet for å minimere kode utført på klienten, ulik tilgjengelighet av objekter og typer plattformer, etc.). I dette tilfellet må du huske på den uunngåelige økningen i antall vanlige moduler i konfigurasjonen.

Et spesielt tilfelle av blandede klient-server-moduler er skjema- og kommandomoduler, som er spesielt designet for å implementere server- og klientforretningslogikk i én modul.

3.1. Det anbefales at navn på vanlige moduler følger de generelle reglene for navngivning av metadataobjekter. Navnet på den generelle modulen må samsvare med navnet på delsystemet eller den separate mekanismen, prosedyrene og funksjonene som den implementerer. Det anbefales å unngå slike generelle ord som "Prosedyrer", "Funksjoner", "Behandlere", "Modul", "Funksjonalitet" osv. i navnene på vanlige moduler. og bruk dem bare i unntakstilfeller når de mer fullstendig avslører formålet med modulen.

For å skille mellom vanlige moduler i ett delsystem, som er opprettet for å implementere prosedyrer og funksjoner utført i forskjellige sammenhenger, anbefales det å gi dem postfiksene beskrevet tidligere i avsnitt. 2,1-2,4.

Hva er moduler og hva er de ment for? Modulen inneholder programkoden. Dessuten er det verdt å merke seg at, i motsetning til 7.7-plattformen, hvor koden kan være plassert i egenskapene til skjemaelementer og i cellene i layouttabellene, i 8.x-plattformen må enhver kodelinje være plassert i en modul . Vanligvis består en modul av tre seksjoner - en seksjon for å beskrive variabler, en seksjon for å beskrive prosedyrer og funksjoner, og en seksjon for hovedprogrammet. Denne strukturen er typisk for nesten alle plattformmoduler, med noen unntak. Noen moduler har ikke en variabel beskrivelsesdel eller en hovedprogramdel. For eksempel sesjonsmodul og en hvilken som helst generell modul.

Utførelseskonteksten til moduler er generelt delt inn i klient og server. I tillegg kan noen moduler kompileres både på klientsiden og på serversiden. Og noen er utelukkende på serversiden eller klientsiden. Så:

Applikasjonsmodul

Modulen er designet for å fange øyeblikkene av applikasjonsstart (konfigurasjonslasting) og avslutning av driften. Og verifikasjonsprosedyrer kan plasseres i de tilsvarende hendelsene. For eksempel, når du starter en applikasjon, oppdater noen referansekonfigurasjonsdata, og når du er ferdig med arbeidet, spør om det er verdt å forlate det i det hele tatt, kanskje arbeidsdagen ikke er over ennå. I tillegg avskjærer den hendelser fra eksternt utstyr, for eksempel handel eller finans. Det er verdt å merke seg at applikasjonsmodulen fanger opp de beskrevne hendelsene bare når den startes interaktivt. De. når selve programvinduet er opprettet. Dette skjer ikke hvis applikasjonen startes i com-tilkoblingsmodus.

Det er to forskjellige applikasjonsmoduler i 8.2-plattformen. Dette er modulen for vanlige applikasjoner og moduler for administrert applikasjon. De utløses når forskjellige klienter lanseres. Dette er hvordan den administrerte applikasjonsmodulen utløses når nettklienten, tynnklienten og tykk klienten startes i administrert applikasjonsmodus. Og den vanlige applikasjonsmodulen utløses når den tykke klienten startes i normal applikasjonsmodus.

En applikasjonsmodul kan inneholde alle seksjoner - beskrivelser av variabler, prosedyrer og funksjoner, samt beskrivelser av hovedprogrammet. Applikasjonsmodulen er kompilert på klientsiden, så dette begrenser oss i stor grad når det gjelder tilgjengeligheten av mange typer data. Du kan utvide applikasjonsmodulens kontekst ved å bruke metoder for vanlige moduler som har egenskapen "Server Call" satt. Alle variabler og metoder som er merket som eksport vil være tilgjengelige i enhver konfigurasjonsmodul som kjører på klientsiden. Men hvor fristende det enn er, bør du ikke legge ut et stort antall metoder her. Jo mer kode den inneholder, desto lengre blir kompileringstiden, og dermed applikasjonens starttid, noe som er veldig irriterende for brukerne.

Som nevnt ovenfor håndterer applikasjonsmodulen applikasjonsoppstart og avslutningshendelser. For å håndtere hver av disse hendelsene i applikasjonsmodulen, er det et par behandlere Før... og Når... Forskjellene mellom dem er slik at når du utfører koden i Før...-behandleren, har ikke handlingen ennå funnet sted, og vi kan nekte å utføre den. Det er dette alternativet Avvis er for. I On..-behandlerne har handlingen allerede funnet sted, og vi kan ikke nekte å starte programmet eller avslutte det.

Ekstern tilkoblingsmodul

Hensikten med modulen er lik formålet med applikasjonsmodulen. Den behandler start- og sluttpunktene for søknaden. Den eksterne tilkoblingsmodulen utløses når applikasjonen startes i com-tilkoblingsmodus. Selve den ytre sammenføyningsprosessen er en ikke-interaktiv prosess. I denne modusen skjer programmatisk arbeid med informasjonsbasen og applikasjonsvinduet åpnes ikke, noe som pålegger visse begrensninger på bruken av metoder beregnet for interaktivt arbeid. I denne modusen kan ikke anrop til dialogskjemaer, advarselsmeldinger osv. brukes. De vil bare ikke fungere.

Som i applikasjonsmodulen er seksjoner for å beskrive variabler, metoder og en seksjon for hovedprogrammet tilgjengelig her. Du kan også deklarere eksportvariabler og -metoder. Forskjellen er at i com-tilkoblingsmodus skjer alt arbeid med infobasen på serversiden, så den eksterne tilkoblingsmodulen kompileres utelukkende på serveren. Følgelig er eksportvariabler og metoder for vanlige klientmoduler ikke tilgjengelige i den.

Sesjonsmodul

Dette er en svært spesialisert modul og er kun beregnet på initialisering av øktparametere. Hvorfor trengte du å lage din egen modul for dette? Dette skyldes det faktum at initialiseringsprosessen kan kreve kjøring av noe kode, og i tillegg kan applikasjonen startes under forskjellige klienter (noe som fører til kjøring av forskjellige applikasjonsmoduler eller en ekstern tilkoblingsmodul), og initialisering av sesjonsparametere må gjøres i enhver startmodus. Derfor var det nødvendig med en tilleggsmodul som kjører i enhver applikasjonsstartmodus.

I øktmodulen er det en enkelt hendelse "SettingSessionParameters", som utføres aller først, selv før applikasjonsmodulhendelsen BeforeSystemStartOperation. Variabeldeklarasjonsdelen og hovedprogramdelen er ikke tilgjengelig i den. Du kan heller ikke deklarere eksportmetoder. Modulen er kompilert på serversiden.

Du bør ikke la deg friste av det faktum at denne modulen kjøres hver gang applikasjonen startes, og du bør ikke plassere kode i den som ikke er direkte relatert til initialiseringen av sesjonsparametere. Dette skyldes det faktum at SetSessionParameters-behandleren kan kalles gjentatte ganger under systemdrift. Dette skjer for eksempel i tilfeller der vi får tilgang til uinitialiserte parametere. Og selv om det er mulig å fange øyeblikket for den første lanseringen av denne hendelsen (RequiredParameters er av typen Undefined), bør det tas i betraktning at denne modulen er kompilert i privilegert modus, dvs. den kontrollerer ikke tilgangsrettigheter. Og det andre poenget er at vi fortsatt ikke kan være hundre prosent sikre på at systemet vil bli lansert. Plutselig oppstår det en feil i applikasjonsmodulen, og vi prøver å utføre noen handlinger med databasen.

Vanlige moduler

Moduler er ment å beskrive noen vanlige algoritmer som vil bli kalt fra andre konfigurasjonsmoduler. Den generelle modulen inneholder ikke en variabelbeskrivelsesdel og en hovedprogramdel. Du kan deklarere eksportmetoder i den, hvis tilgjengelighetskontekst vil bli bestemt av kompilasjonsflagg. På grunn av det faktum at variabelbeskrivelsesdelen ikke er tilgjengelig, kan ikke globale variabler defineres i vanlige moduler. For å gjøre dette må du bruke funksjonene til vanlige moduler med bufring av returverdier eller en applikasjonsmodul. Det er verdt å huske på at selv om gjenbruksegenskapen for delt modul er satt til "For varigheten av økten", så i dette tilfellet overstiger ikke levetiden til bufrede verdier 20 minutter fra øyeblikket av siste tilgang til dem.
Oppførselen til en felles modul avhenger av parameterne som er satt (globalt eller ikke, ulike kompileringsflagg, om et serverkall er tilgjengelig osv.). I denne artikkelen vil vi ikke vurdere alle typer innstillinger, så vel som atferdstrekk og fallgruver som oppstår når du setter eiendomsflagg på en urimelig måte. Dette er et tema for en egen artikkel. La oss dvele ved bare noen få punkter som bør følges når du setter flagg:

• En god tommelfingerregel er å ikke bruke det globale flagget overalt. Dette vil redusere oppstartstiden til applikasjonen, og også forbedre lesbarheten til koden (selvfølgelig hvis fellesmodulen har et fullstendig meningsfylt navn).
• Det er ikke tilrådelig å bruke mer enn ett kompilasjonsflagg. Det er ikke mange metoder som må utføres i ulike sammenhenger, og hvis slike metoder fortsatt kreves, kan det tildeles en egen felles modul for dem.
• "Server Call"-flagget gir bare mening hvis modulen er kompilert "På serveren". Derfor bør alle andre kompilasjonsflagg fjernes for å unngå ulike problemer.
• Hvis modulmetoder involverer massiv databehandling, lesing og skriving til databasen, er det bedre å deaktivere tilgangsrettighetskontrollen for å øke hastigheten ved å sette "Privileged"-flagget. Denne modusen er kun tilgjengelig for delte moduler kompilert på serveren.

Skjemamodul

Den er designet for å behandle brukerhandlinger, dvs. ulike hendelser knyttet til dataregistrering og behandling av riktigheten av deres oppføring. En modul av vanlig form er satt sammen utelukkende på klienten. En administrert skjemamodul er tydelig avgrenset av utførelseskontekst, så alle variabler og metoder må ha et kompileringsdirektiv. Hvis direktivet ikke er eksplisitt spesifisert, vil denne variabelen eller metoden bli kompilert på serversiden. Skjemamodulen inneholder seksjoner for beskrivelser av variabler og metoder, samt seksjon for hovedprogrammet.

Objektmodul

Denne modulen er typisk for mange konfigurasjonsobjekter og er vanligvis beregnet på å behandle objekthendelser. For eksempel hendelser for registrering og sletting av objekter, hendelser for å legge ut dokumenter, etc.

Noen objektmodulhendelser dupliserer skjemamodulhendelsene. For eksempel hendelser knyttet til et opptak. Vær imidlertid klar over at skjemamodulhendelser vil bli utført utelukkende på objektets spesifikke skjema. Generelt kan det være flere av disse formene. Og hendelsene til objektmodulen vil bli kalt i alle fall, selv i øyeblikket av programmatisk arbeid med objektet. Derfor, hvis du trenger å kjøre noe kode i alle tilfeller, er det bedre å bruke en objektmodulhendelse for dette.

Objektmodulen kompileres utelukkende på serveren. I den kan du definere eksportvariabler og metoder som vil være tilgjengelige i andre konfigurasjonsmoduler. Ved å bruke disse egenskapene og metodene kan vi utvide funksjonaliteten til objektet betydelig.

Objektbehandlingsmodul

Denne modulen finnes for mange konfigurasjonsobjekter. Hovedformålet med denne modulen er å omdefinere standardvalghendelsen som oppstår når du går inn på en linje og å utvide funksjonaliteten til lederen. Modulen er kompilert på serversiden. Den lar deg definere eksportegenskaper og metoder. Å kalle lederens eksportmetoder krever ikke å opprette selve objektet.

Til alt det ovennevnte kan du legge til et bilde av noen konfigurasjonsmoduler og måter å gjensidig kalle metoder i administrert applikasjonsmodus. Pilen angir retningen du kan snu for å ringe den tilsvarende metoden. Som det fremgår av diagrammet, er serverkonteksten helt lukket. Men fra klientkonteksten er det mulig å få tilgang til servermetoder.

Symboler på diagrammet: O.M. Klient - Klient felles modul; O.M. Server - Server delt modul; M.F. Klient - Klientprosedyrer for skjemamodulen; M.F. Server - Serverprosedyrer for skjemamodulen.

Programvaremoduler inneholder kjørbar kode på 1C-språket, som er nødvendig for å svare på en bestemt måte på handlingene til systemet eller brukeren når visuelle utviklingsverktøy ikke er nok. Vi kan også beskrive våre egne metoder (prosedyrer og funksjoner) i programvaremoduler.

Vanligvis består en programvaremodul av tre seksjoner:

• variabelt deklarasjonsområde;
• område for beskrivelse av prosedyrer og funksjoner;
• hovedteksten i programmet.

Eksempel på strukturen til en programvaremodul:

//******************* VARIABEL ANGIVELSESOMRÅDE ***********************

Perem Etternavn Eksport; / /dette er en global variabel
Endre navn, patronym; //dette er en modulvariabel
Perem fullt navn; //dette er også en modulvariabel og kan nås

//fra hvilken som helst prosedyre og funksjon i vår modul

//*************** OMRÅDEBESKRIVELSE AV PROSEDYRER OG FUNKSJONER ****************

Prosedyre Prosedyre 1 ()
Variabel total ; / /Resultat er en lokal variabel (prosedyrevariabel)

Totalt = Etternavn + " "+ Fornavn + " "+ Mellomnavn;

Sluttprosedyre

Funksjon Funksjon1()

// funksjonsoperatorer

Return(Etternavn + " "+ Fornavn);

EndFunction

//******************* HOVEDTEKST PÅ PROGRAMMET ***********************

Etternavn = "Ivanov";
Navn = "Ivan";
Patronymisk = "Ivanovich";

//******************************************************************************

I en bestemt programvaremodul kan noen av områdene mangle.
Variabelt deklarasjonsområde plassert fra begynnelsen av modulteksten til den første prosedyre- eller funksjonssetningen eller en kjørbar setning. Denne delen kan bare inneholde variabelvariabelerklæringer.

Område for beskrivelse av prosedyrer og funksjoner plassert fra den første prosedyre- eller funksjonssetningen til enhver kjørbar setning utenfor hoveddelen av prosedyren eller funksjonsbeskrivelsen.

Hovedprogramtekstområde plasseres fra den første kjørbare setningen utenfor hoveddelen av prosedyrer eller funksjoner til slutten av modulen. Denne delen kan bare inneholde kjørbare setninger. Hovedprogramtekstområdet utføres i øyeblikket av modulinitialisering. Vanligvis, i en del av hovedprogrammet, er det fornuftig å plassere operatører for initialisering av variabler med spesifikke verdier som må tilordnes før det første kallet til prosedyrer eller funksjoner i modulen.

Programvaremoduler er plassert på de stedene i konfigurasjonen som kan kreve en beskrivelse av spesifikke driftsalgoritmer. Disse algoritmene bør formaliseres i form av prosedyrer eller funksjoner som vil bli kalt av systemet selv i forhåndsbestemte situasjoner (for eksempel når du åpner et katalogskjema, når du trykker på en knapp i en dialogboks, når du endrer et objekt, etc.) .

Hver enkelt programvaremodul oppfattes av systemet som en helhet, slik at alle prosedyrer og funksjoner til programvaremodulen utføres i en enkelt kontekst.

Modulutførelseskonteksten er delt inn i klient og server. I tillegg kan noen programvaremoduler kompileres både på klientsiden og serversiden.

Applikasjonsmodul (administrert eller vanlig)

Applikasjonsmodulen beskriver prosedyrene (behandlerne) for hendelser som initialiseres ved starten og slutten av systemet. For eksempel, når applikasjonen begynner å kjøre, kan du oppdatere noen konfigurasjonsdata, og når du avslutter applikasjonen kan du spørre om det er verdt å avslutte programmet i det hele tatt. I tillegg fanger denne modulen opp hendelser fra eksternt utstyr, for eksempel handel eller finans. Det er verdt å merke seg at applikasjonsmodulen kun kjøres når applikasjonen startes interaktivt, det vil si når programvinduet startes. Dette skjer ikke hvis applikasjonen startes i com-tilkoblingsmodus.
I 1C 8-plattformen er det to forskjellige applikasjonsmoduler. Dette er modulen for vanlige applikasjoner og moduler for administrert applikasjon. De utløses når forskjellige klienter lanseres. Dermed utløses modulen for administrerte applikasjoner når nettklienten, tynnklienten og tykk klienten startes i administrert applikasjonsmodus. Og den vanlige applikasjonsmodulen utløses når den tykke klienten startes i normal applikasjonsmodus. Innstillingen for programstartmodus er spesifisert i konfigurasjonsegenskapen "Grunnleggende oppstartsmodus".

En applikasjonsmodul kan inneholde alle 3 seksjoner - deklarasjoner av variabler, beskrivelser av prosedyrer og funksjoner, samt hovedteksten til programmet. Applikasjonsmodulen er kompilert på klientsiden, noe som i stor grad begrenser vår bruk av mange datatyper. Du kan utvide applikasjonsmodulens kontekst ved å bruke metoder for vanlige moduler som har egenskapen "Server Call" satt. Alle applikasjonsmodulvariabler og -metoder som er merket som eksport vil være tilgjengelige i enhver konfigurasjonsmodul som kjører på klientsiden. Men hvor fristende det enn er, bør du ikke plassere et stort antall prosedyrer og funksjoner her. Jo mer kode det er i en gitt modul, desto lengre er kompileringstiden, og følgelig applikasjonens starttid.

Som nevnt ovenfor håndterer applikasjonsmodulen applikasjonsoppstart og avslutningshendelser. For å håndtere hver av disse hendelsene i applikasjonsmodulen, er det et par behandlere Før... og Når... Forskjellene mellom dem er som følger: når du kjører kode i Før...-behandleren, har ikke handlingen ennå funnet sted, og vi kan nekte å utføre den. Det er dette alternativet Avvis er for. I On..-behandlerne har handlingen allerede funnet sted, og vi kan ikke nekte å starte programmet eller avslutte det.

Ekstern tilkoblingsmodul

• kan inneholde alle 3 områdene
• plassert i rotdelen av konfigurasjonen

Hensikten med modulen er lik formålet med applikasjonsmodulen. Den behandler start- og slutthendelsene for applikasjonen. Den eksterne tilkoblingsmodulen utløses når applikasjonen startes i com-tilkoblingsmodus. Selve den ytre sammenføyningsprosessen er ikke en interaktiv prosess. I denne modusen skjer programmatisk arbeid med informasjonsbasen og applikasjonsvinduet åpnes ikke, noe som pålegger visse begrensninger på bruken av metoder beregnet for interaktivt arbeid. I denne modusen kan ikke anrop til dialogskjemaer, advarsler og meldinger til brukeren osv. brukes. De vil rett og slett ikke bli henrettet.

Som i applikasjonsmodulen er alle tre områdene tilgjengelige her: variable deklarasjoner, beskrivelser av prosedyrer og funksjoner, samt hovedteksten til programmet. Hovedforskjellen fra applikasjonsmodulen er at i com-tilkoblingsmodus skjer alt arbeid med infobasen på serversiden, så den eksterne tilkoblingsmodulen er kompilert på serversiden. Følgelig er eksportvariabler og metoder for vanlige klientmoduler ikke tilgjengelige i den.

Sesjonsmodul

• kjører på serversiden
• plassert i rotdelen av konfigurasjonen

Dette er en svært spesialisert modul designet eksklusivt for initialisering av øktparametere. Hvorfor trengte du å lage din egen modul for dette? Bruken skyldes det faktum at selve applikasjonen kan startes i forskjellige moduser (som resulterer i kjøring av enten en administrert applikasjonsmodul, en vanlig applikasjonsmodul eller en ekstern tilkoblingsmodul), og initialisering av sesjonsparametere må gjøres uansett av oppstartsmodus. For ikke å skrive samme programkode i alle disse tre modulene, trengte vi en tilleggsmodul som kjører uavhengig av applikasjonsstartmodus.

I øktmodulen er det én enkelt hendelse "SettingSessionParameters", som utføres aller først, selv før applikasjonsmodulhendelsen BeforeSystemStartOperation. Variabeldeklarasjonsdelen og hovedprogramdelen er ikke tilgjengelig i den. Du kan heller ikke deklarere eksportmetoder. Modulen er kompilert på serversiden.

Vanlige moduler

• kan inneholde et område som beskriver prosedyrer og funksjoner
• utført på server- eller klientsiden (avhengig av modulinnstillingene)
• er plassert i tregrenen til konfigurasjonsobjektene "Generelt" - "Generelle moduler"

Vanlige moduler er ment å beskrive noen vanlige algoritmer som vil bli kalt fra andre konfigurasjonsmoduler. Den generelle modulen inneholder ikke variable deklarasjonsområder og hovedprogramteksten. Du kan erklære eksportmetoder i den, hvis tilgjengelighet vil bli bestemt av modulinnstillingene (på hvilken side det utføres: på server- eller klientsiden). På grunn av det faktum at variabelbeskrivelsesdelen ikke er tilgjengelig, kan ikke globale variabler defineres i vanlige moduler. Du kan bruke en applikasjonsmodul til dette.

Oppførselen til en felles modul avhenger av parameterne som er satt (globalt eller ikke, ulike kompileringsflagg, om et serverkall er tilgjengelig osv.). Her er noen tips for å sette opp vanlige moduler:

Det er god praksis å ikke bruke det globale flagget overalt. Dette vil redusere oppstartstiden til applikasjonen, og også forbedre lesbarheten til koden (selvfølgelig hvis fellesmodulen har et fullstendig meningsfylt navn);
– Det er ikke tilrådelig å bruke mer enn ett kompileringsflagg. Det er ikke så mange metoder som må utføres i ulike sammenhenger, og hvis slike metoder fortsatt kreves, kan det tildeles en egen felles modul for dem;
- "Call server"-flagget gir mening bare hvis modulen er kompilert "På serveren". Derfor bør alle andre kompilasjonsflagg fjernes for å unngå ulike problemer;
- hvis modulmetodene involverer massiv databehandling, lesing og skriving til databasen, er det bedre å deaktivere tilgangskontroll for å øke hastigheten ved å sette flagget "Privileged". Denne modusen er kun tilgjengelig for delte moduler kompilert på serveren.

Skjemamodul

• kan inneholde alle 3 områdene
• utføres på server- og klientsiden

Skjemamodulen er laget for å behandle brukerhandlinger med dette skjemaet (behandling av en knappeklikkhendelse, endring av skjemaattributter osv.). Det er også hendelser knyttet direkte til selve skjemaet (for eksempel åpning eller lukking). Moduler av administrerte og vanlige skjemaer skiller seg først og fremst ved at modulen til et administrert skjema er tydelig delt inn i kontekst. Hver prosedyre eller funksjon må ha et kompileringsdirektiv. Hvis kompileringsdirektivet ikke er spesifisert, blir denne prosedyren eller funksjonen utført på serversiden. I sin normale form kjøres all kode på klientsiden.

Strukturen til et administrert skjema inneholder en seksjon for deklarasjoner av variabler, beskrivelser av prosedyrer og funksjoner, og hovedteksten til programmet (utført på tidspunktet for initialisering av skjemaet). Vi kan få tilgang til standardskjemahendelser gjennom listen over forventede prosedyrer og funksjoner i skjemaet (Ctrl+Alt+P), eller gjennom egenskapspaletten til selve skjemaet.

Hvis et skjema har tildelt et hovedattributt, blir egenskapene og metodene til applikasjonsobjektet som brukes som hovedattributt, tilgjengelig i skjemamodulen.

Objektmodul

• kan inneholde alle 3 områdene
• kjører på serversiden

Denne modulen er tilgjengelig for de fleste konfigurasjonsobjekter og er generelt ment for behandling av hendelser direkte relatert til objektet. For eksempel hendelser med opptak og sletting av objekter, kontroll av fullføring av objektdetaljer, posting av et dokument, etc.

Noen objektmodulhendelser dupliserer skjemamodulhendelsene. For eksempel hendelser knyttet til et opptak. Imidlertid skal det forstås at hendelsene i skjemamodulen vil bli utført utelukkende i den spesifikke formen til objektet, det vil si når det spesifikke skjemaet åpnes. Og hendelsene til objektmodulen vil bli kalt i alle fall, selv i øyeblikket av programmatisk arbeid med objektet. Derfor, hvis du trenger metoder knyttet til et objekt uten å være knyttet til en bestemt form av objektet, så er det bedre å bruke objektmodulen til dette.

Objektbehandlingsmodul

• kan inneholde alle 3 områdene
• kjører på serversiden

Objektbehandlingsmodulen dukket bare opp fra versjon 1C 8.2. Managermodulen finnes for alle applikasjonsobjekter og er designet for å administrere dette objektet som et konfigurasjonsobjekt. Managermodulen lar deg utvide funksjonaliteten til et objekt ved å introdusere (skrive)prosedyrer og funksjoner som ikke er relatert til en spesifikk forekomst av et databaseobjekt, men til selve konfigurasjonsobjektet. Objektbehandlingsmodulen lar deg plassere generelle prosedyrer og funksjoner for et gitt objekt og få tilgang til dem utenfra, for eksempel fra behandling (selvfølgelig hvis denne prosedyren eller funksjonen har Eksporter nøkkelordet). Hva nytt gir dette oss? Generelt, ingenting annet enn å organisere prosedyrer etter objekter og lagre dem på separate steder - Objektbehandlingsmoduler. Vi kan like hell plassere disse prosedyrene og funksjonene i generelle moduler, men 1C anbefaler å plassere generelle prosedyrer og funksjoner til objekter i Object Manager-modulen. Eksempler på bruk av prosedyrene og funksjonene til objektbehandlingsmodulen: innledende utfylling av individuelle detaljer om en katalog eller et dokument under visse betingelser, kontroll av fullføringen av detaljer i en katalog eller et dokument under visse betingelser, etc.

Kommandomodul

• kan inneholde en del som beskriver prosedyrer og funksjoner
• utført på klientsiden

Kommandoer er objekter som er underordnet applikasjonsobjekter eller konfigurasjonen som helhet. Hver kommando har en kommandomodul der en forhåndsdefinert CommandProcess()-prosedyre kan beskrives for å utføre den kommandoen.

I nye versjoner av 1C:Enterprise systemkonfigurasjoner har mange funksjoner og prosedyrer flyttet fra objektmoduler (dokumenter, kataloger osv.) til administratormoduler. La oss se på forskjellene mellom disse to modulene.

I følge teorien om objektorientert programmering er objektmetoder delt inn i to grupper: statiske og enkle. Enkle metoder har bare tilgang til en spesifikk forekomst av en klasse. Statiske metoder har ikke tilgang til objektdata, men fungerer med klassen som helhet.

Hvis vi oversetter alt dette til 1C:Enterprise-systemet, da Objektmodul inneholder enkle metoder. For å bruke dem må du først anskaffe et spesifikt objekt: et element i en katalog, et dokument, etc. Ledermodul inneholder statiske metoder. For å bruke det er det ikke nødvendig å skaffe hvert enkelt objekt separat, det lar deg jobbe med hele samlingen på en gang.

Objektmodul kan ha prosedyrer og funksjoner som kan brukes eksternt. For dette formålet er en slik prosedyre eller funksjon betegnet med ordet Eksport.

Funksjon NewFunction () Eksporter

For å bruke en slik funksjon fra en objektmodul, må du først, ha en lenke til det nødvendige objektet, få den ved å bruke funksjonen GetObject().

Per = Objekt. NewFunction() ;

På samme måte kan du lage nye variabler som kan brukes fra ulike konfigurasjonsobjekter.

Variabel NewVariable Export

Katalogelement = Kataloger. Nomenklatur. FinnByKode("000000001" );
Objekt = Katalogelement. GetObject() ;
En gjenstand. NewVariable= );

På denne måten kan du supplere standard prosedyrer, funksjoner og egenskaper (variabler) til objekter. Slike variabler er dynamiske, de lagres ikke i infobasen og eksisterer kun mens de arbeider med det mottatte objektet.

Ledermodul har alle de samme egenskapene, den eneste forskjellen er at du ikke trenger å skaffe et spesifikt objekt for å bruke det, lar deg jobbe med hele samlingen av objekter av en bestemt type.

Prosedyre NewProcedure() Eksport

Katalogelement = Kataloger. Nomenklatur. NewProcedure();

Eller for en variabel:

Variabel NewVariable Export

Katalogelement = Kataloger. Nomenklatur. nyVariabel;

La oss se på forskjellene i bruken av objektmodulen og managermodulen ved å bruke eksemplet på prosedyren for å lage en trykt form av et dokument.

Når du bruker objektmodulen, vil koden se slik ut:

Funksjon Skriv ut dokument (lenke) Eksport
//Du må sende en lenke til et spesifikt dokument til denne funksjonen
Returner TabDoc;
EndFunction

På dokumentskjemaet må du opprette en prosedyre som sender en lenke til dokumentet til utskriftsfunksjonen.

&OnClient
Prosedyreutskrift (kommando)
TabDoc = PrintOnServer();
TabDoc. Forestilling() ;
Sluttprosedyre
&På server
Funksjon PrintOnServer()
Doc = FormAttributesValue("Objekt" ) ;
Returner dok. PrintDocument(Object.Link) ;
EndFunction

Ulempen med denne metoden er at den kun skriver ut ett objekt. Hvis du trenger å skrive ut flere dokumenter samtidig, må du hente hvert av dem, og deretter kalle opp funksjonen fra objektmodulen. Dette krever betydelige systemressurser fordi når et objekt hentes, blir hele objektet plassert i RAM.

Fra et ytelsessynspunkt er det mye bedre å bruke ledermodulen når det er mulig. I vårt eksempel vil løsningen på problemet se slik ut.
Funksjon PrintOnServer()
Returner dokumenter. Vårt dokument. PrintDocument(ArrayLinks);
EndFunction

Hvis du bruker managermodulen, kan utskriftsprosedyren kalles både fra dokumentskjemaet og fra listeskjemaet, ved å sende lenker til flere dokumenter i en matrise. I dette tilfellet trenger ikke systemet å hente hvert dokument fra matrisen, noe som sparer systemressurser betydelig.

Så når skal man bruke en objektmodul og når man skal bruke en managermodul?

Alt avhenger av oppgaven. Hvis en referanse til et objekt er nok til å fullføre det (for eksempel en utskriftsoppgave), er det bedre å bruke managermodulen. Hvis oppgaven er å endre data, for eksempel fylle ut et dokument, så må du hente det og bruke objektmodulen.