1c företagsmoduler och deras syfte. Vanliga moduler

Artikeln fortsätter serien "Första stegen i utvecklingen på 1C", den diskuterar i detalj följande frågor:

Vad är en mjukvarumodul och vilka sektioner består den av?
Vad är applikationsmodulen till för? Varför är det två av dem? När börjar vilken? Vilka är subtiliteterna i verket?
Vilka händelser är förknippade med start av systemdrift, hur och var ska de behandlas?
Vad är den externa anslutningsmodulen till för? När och hur ska man använda det?
När används sessionsmodulen?
Vad är vanliga moduler? Vilka är dess egenskaper och verksamhetsregler? Varför använda egenskapen "Återanvändning av returvärden"?
När används formulärmodulen och vilka händelser kan behandlas i den?
Vad är objektmodulen till för? Vilka avsnitt består den av? Hur kan jag se tillgängliga modulhändelser?
Vilka är finesserna i att arbeta med moduler för värdehanterare (för konstanter) och moduler för postuppsättningar (för register)?
Vad är skillnaderna mellan en objektmodul och en managermodul? När ska du använda den senare?

Tillämplighet

Artikeln diskuterar 1C:Enterprise-plattformen 8.3.4.496. Materialet är även relevant för aktuella plattformssläpp.

Moduler i "1C:Enterprise 8.3"

Moduler är de objekt som innehåller programkod.

Det finns ett ganska stort antal typer av moduler i plattformen, som var och en har sitt eget syfte och funktioner.

Alla kodrader måste finnas i någon modul. Det finns generella moduler och objektmoduler. Vissa moduler kan kompileras på både klienten och servern, och vissa bara på servern.

En modul kan bestå av flera sektioner. Variabelbeskrivningsavsnittet beskriver lokala variabler för denna modul, som sedan kan användas i alla förfaranden.

Inom varje procedur kan du komma åt en modulvariabel. Dessutom kan det inom själva proceduren finnas en annan variabeldeklaration med samma namn. Detta kommer att vara en lokal variabel i denna procedur.

Trots samma namn är dessa två olika variabler: en används i en specifik procedur och den andra används utanför den.

I vissa moduler kan variabler indikera platsen för kompilering (tillgänglighet) på servern eller på klienten. Till exempel:

Avsnittet som beskriver variabler följs av ett avsnitt med procedurer och funktioner, där lokala metoder för denna modul anges. Vissa moduler måste ange var proceduren eller funktionen kommer att kompileras.

Sammanställningsdirektivet kan i princip utelämnas. I det här fallet är standardkompileringsdirektivet Server. Men för att underlätta analys av programkod, rekommenderas det att uttryckligen ange var en given procedur kommer att kompileras. Ordningen i vilken procedurerna beskrivs spelar ingen roll.

I slutet av modulen, efter att ha beskrivit alla procedurer och funktioner, finns det en del av huvudprogrammet, som kan innehålla några operatorer och initiera lokala variabler i formulärmodulen. Detta avsnitt exekveras vid åtkomst till en modul.

Så, till exempel, när du öppnar ett elementformulär, exekveras huvudprogramdelen av formulärmodulen först.

Det bör noteras att sektionen för variabeldeklaration och huvudprogramsektionen inte finns för alla moduler (dvs dessa sektioner är inte giltiga i vissa moduler). En sektion för att beskriva procedurer och funktioner kan finnas i absolut vilken modul som helst.

Applikationsmodul

Den här modulen är utformad för att hantera händelser av applikationsstart och uppsägning. Till exempel, när du startar programmet kan du ladda ner valutakurser från Internet. När du avslutar en applikation kan du bekräfta med användaren att han eller hon har för avsikt att avsluta.

Även i applikationsmodulen finns det speciella hanterare som låter dig fånga upp externa händelser från utrustningen.

Dessa kan vara händelser från en magnetisk kortläsare eller skatteregistrator. Och dessa händelser kan också bearbetas på något sätt.

Observera att applikationsmodulen övervakar den interaktiva lanseringen av systemet.

Applikationsmodulen kommer inte att fungera om 1C-programmet startas, till exempel i com-anslutningsläge. I det här fallet skapas inte programfönstret.

Det bör noteras att det i Plattform 8.3 finns två olika applikationsmoduler: modulen Managed Application och Regular Application-modulen. Modulhändelser hanterad applikation bearbetas när den tunna och tjocka klienten för den hanterade applikationen och webbklienten startas.

Modul Regelbunden tillämpning fungerar när den tjocka klienten körs i läge Regelbunden tillämpning, som innehåller det vanliga kommandogränssnitt i formen Huvudmeny.

Om applikationen körs in Hanterade, och i läge Regelbunden tillämpning, då är det nödvändigt att beskriva hanterarprocedurerna som för modulen Hanterad applikation, och för modulen Regelbunden tillämpning.

Modul Hanterad applikation kan väljas från snabbmenyn för rotkonfigurationsnoden.

Denna modul kan också öppnas från egenskapspaletten för rotkonfigurationselementet.

För att öppna en modul Regelbunden tillämpning, bör du se konfigurationsinställningarna (kommando Alternativ i menyn Service).

Formuläret öppnas Alternativ. På bokmärket Allmän konfigurationsredigeringsläge måste anges Hanterad applikation Och Regelbunden tillämpning.

I det här fallet modulen Regelbunden tillämpning det kommer också att vara möjligt att öppna från rotnodens egenskaper.

Lista över händelser som kan behandlas för Hanterade Och Regelbunden tillämpningär densamma.

Denna modul kan innehålla en variabeldeklarationssektion, en beskrivningsdel av godtyckliga procedurer och funktioner och en huvudprogramsektion. Men förutom godtyckliga procedurer och funktioner kan speciella händelsehanterare finnas i modulen.

Listan över tillgängliga hanterare kan ses genom att anropa listan med procedurer och funktioner för den aktuella modulen när modulen är öppen.

Fönstret Procedurer och funktioner som öppnas visar alla procedurer och funktioner för denna modul, såväl som händelser för vilka hanterare ännu inte har skapats.

Det finns två händelser associerade med starten av systemet ("före" och "vid"). Två händelser associerade med systemavstängning ("före" och "vid"). Och även bearbetning av externa evenemang (till exempel evenemang med kommersiell utrustning).

När en före-händelsehanterare exekveras anses åtgärden inte ha ägt rum ännu. När händelsehanteraren "at" exekveras har åtgärden redan slutförts.

Händelse Innan du startar systemet inträffar i det ögonblick då Enterprise 8.3 startas, men själva applikationen har ännu inte dykt upp på skärmen. Denna händelse har följande parameter: Vägran.

Om denna parameter tar värdet Sann, då startar inte programmet. Händelse När du startar systemet antar att åtgärden redan har slutförts, fönstret har redan skapats, och i det här fallet kan vi till exempel visa någon speciell form. Det går inte längre att neka uppskjutning.

På samma sätt, innan du stänger av systemet, är applikationen fortfarande öppen och du kan vägra att stänga den. När systemet stängs av har programfönstret redan stängt. Det är bara möjligt att utföra ytterligare åtgärder, till exempel att radera vissa filer eller skicka ett e-postmeddelande.

I modulen Hanterad applikation Direktiv för kompilering av procedurer och funktioner är inte specificerade, eftersom modulen är helt kompilerad på klientsidan. Det innebär att vi i modulens rutiner och funktioner inte kommer att kunna direkt komma åt till exempel referensböcker.

Om från modul Hanterad applikation behöver ringa ett serveranrop, då måste du skapa special för detta med en flagga .

I modulen Regelbunden tillämpning Det finns inga sådana begränsningar, eftersom denna modul kommer att kompileras när den tjocka klienten laddas. Nästan alla typer av data är tillgängliga i den tjocka klienten.

Procedurer, funktioner och variabler för en applikationsmodul kan beskrivas som exporter.

Eftersom modulen helt och hållet är kompilerad på klienten betyder det att vi i klientprocedurer kan komma åt denna metod och denna egenskap.

Du kan till exempel anropa en procedur eller funktion för en applikationsmodul från ett objekts formulärmodul. Det rekommenderas dock att använda gemensamma moduler för att beskriva allmänna algoritmer. Huvudsyftet med applikationsmodulen är att bearbeta startpunkten och slutpunkten.

I analogi med en applikationsmodul är denna modul utformad för att behandla programöppningshändelsen och avstängningshändelsen.

Till skillnad från applikationsmodulen, som initieras i ögonblicket för interaktiv start av applikationen, arbetar den externa anslutningsmodulen i COM-anslutningsläge, dvs. när ett 1C:Enterprise 8-objekt skapas och kopplas till en specifik databas.

Den här modulen har händelser: När du startar systemet Och Vid systemavstängning.

Den externa anslutningsmodulen kan öppnas med antingen snabbmenyn på nivån för rotkonfigurationsobjektet, eller egenskapspaletten för rotnoden.

Själva den yttre sammanfogningsprocessen är en process programarbete Med informationsbas, inte interaktiv. Följaktligen kan du för närvarande inte använda dialogformulär eller visa varningsmeddelanden, eftersom det inte finns någon gräns-snittet.

I External Connection Module är det möjligt att beskriva exportvariabler och exportmetoder som kommer att finnas på den sida där det externa anropet till 1C:Enterprise 8.3 sker.

Eftersom det inte finns något användargränssnitt i den yttre anslutningen, kompileras Outer Join-modulen helt på servern.

Sessionsmodul

Denna modul behövs för att initiera sessionsparametrar. Sessionsparametrar är snabba globala variabler vars värden är tillgängliga var som helst i konfigurationen.

Du kan öppna sessionsmodulen antingen via snabbmenyn eller genom egenskapspaletten för rotnoden.

Sessionsmodulen tillhandahåller en händelse SettingSessionParameters.

När applikationen startar anropas denna procedur först. Sessionsparametrar behövs för alla programoperationer: både när den startas interaktivt och när den startas i externt anslutningsläge.

Sessionsmodulen beskriver olika åtgärder för att initiera sessionsparametrar beroende på olika förhållanden.

Denna modul beskriver som regel flera procedurer som anropas från proceduren SettingSessionParameters. Därför är alla dessa procedurer uppdelade i en separat modul.

Sessionsmodulen körs alltid i privilegierat läge. Detta innebär att ingen behörighetskontroll kommer att utföras vid åtkomst till databasen. Sessionsmodulen kompileras på Servern, d.v.s. Det är möjligt att komma åt alla servermetoder (inklusive att läsa värden från databasen).

I Sessionsmodulen är det möjligt att endast definiera procedurer och funktioner, d.v.s. det finns ingen variabelbeskrivningssektion och ingen huvudprogramsektion. Du kan inte definiera exportmetoder i en sessionsmodul.

Om det vid start av systemet är nödvändigt att utföra vissa åtgärder på servern, till exempel skapa ett element i en katalog, är det som ett alternativ möjligt att använda sessionsmodulen, eftersom den kompileras på servern och exekveras alltid tillförlitligt vid systemstart. Följande punkter måste dock beaktas:

förfarande SettingSessionParameters exekveras inte bara vid systemstart, utan även vid åtkomst till oinitierade sessionsparametrar. Dessa. SetSessionParameters-hanteraren kan anropas upprepade gånger under applikationsdrift;
om antalet element i sessionsparametrarnas array är noll (arrayen med nödvändiga parametrar har en datatyp av Odefinierad), då är detta ögonblicket då applikationen startas;
eftersom sessionsmodulen fungerar i privilegierat läge och det inte kommer att ske någon kontroll av åtkomsträttigheter, bör du arbeta mycket noggrant med databasobjekt, eftersom användaren kan få tillgång till data som inte ska tillhandahållas honom;
När systemet startar är det ännu inte säkert känt om applikationen kommer att startas. I det här fallet kan onödiga åtgärder utföras i händelsehanteraren SetSessionParameters.

Dessa moduler representerar en beskrivning av några generella algoritmer, dvs. rutiner och funktioner som kan anropas från olika ställen.

Logiskt relaterade metoder kan grupperas i olika gemensamma moduler. Dessa moduler skapas i grenen Allmänt.

Vilken kvantitet som helst kan läggas till gemensamma moduler. För att Common Module-metoder ska vara tillgängliga någon annanstans i konfigurationen måste de definieras med nyckelord Exportera. Klientprocedurer för vanliga moduler kommer att finnas tillgängliga på klienten och server - på servern.

I allmänna moduler är endast avsnittet som beskriver procedurer och funktioner tillgängligt. Dessa. i den allmänna modulen kan du inte beskriva variabler och du kan inte beskriva en del av huvudprogrammet.

Om en global variabel behövs kan du använda antingen sessionsparametrar eller.

För allmänna moduler kan du ställa in några parametrar som kommer att påverka denna moduls beteende. Om egenskapen Global är inställd för en Allmän modul, kommer exportmetoderna som deklareras i denna modul att vara tillgängliga utifrån direkt, utan några ytterligare instruktioner.

Dessa. given Allmän modul kommer att delta i bildandet av den globala konfigurationskontexten.

Egendom Global för allmänna moduler kan det vara användbart. Du bör dock inte använda den överallt för alla vanliga moduler.

Dessa , som är markerade med skylten Global, kommer att kompileras vid systemstart. Ju fler sådana moduler, desto långsammare startar programmet.

Om flaggan Global För Allmän modul inte specificeras, kommer kompilering av denna modul att utföras vid tidpunkten för det första anropet till den (dvs efter att systemet startar).

Dessutom påverkar användningen av globala gemensamma moduler förståelsen av koden. Metoder för en icke-global gemensam modul kallas genom namnet Allmän modul och namnet på metoden, till exempel:
Cost Calculation Module.DistributeIndirectCosts();

I detta fall måste namnen på gemensamma moduler återspegla innehållet i de procedurer som beskrivs i dem. Att specificera namnet på den gemensamma modulen när du anropar en procedur hjälper till att bättre förstå koden.

För Allmän modul V Egenskaper palett du kan ställa in egenskapen Privilegierad.

Den privilegierade modulen kontrollerar inte åtkomsträttigheter. Detta är nödvändigt om Allmän modul Det krävs för att utföra massdatabehandling, hämta data från databasen.

Att kontrollera åtkomsträttigheter ökar tiden det tar att komma åt en databas, och massalgoritmer behöver ofta fungera så snabbt som möjligt.

Löne är till exempel en resurskrävande verksamhet. Det måste göras så snabbt som möjligt. För att göra detta placeras algoritmer som beräknar löner i privilegierade .

Samtidigt ligger alla rutiner som säkerställer ifyllandet av lönehandlingar utanför dessa Vanliga moduler. Det är i dessa procedurer som kontroll av åtkomsträttigheter utförs.

På så sätt kan betydande prestandaförbättringar uppnås. Detta gäller särskilt när man använder en mekanism för rad-för-rad åtkomstkontroll till tabellposter.

Om en gemensam modul är privilegierad, kan procedurerna för denna modul endast kompileras på servern.

Det finns situationer då något objekt skulle vara otillgängligt för användaren, till exempel en viss katalog. Men när du utför ett dokument, vänder du dig till denna katalog nödvändig.

Dessa. det finns ett behov av att tillfälligt utöka användarrättigheterna och sedan returnera dem till initialtillstånd. Denna effekt kan erhållas genom att använda privilegierad Vanliga moduler.

Att göra detta i en privilegierad Allmän modul Du bör skapa en procedur som får åtkomst till de nödvändiga uppgifterna.

Denna procedur kommer att anropas från motsvarande dokument. Dessa. användaren beviljas faktiskt utökade rättigheter vid den tidpunkt då denna procedur anropas.

För Vanliga moduler Det är möjligt att ange kompileringsplatsen. Flaggorna används för att avgöra om den gemensamma modulen kommer att vara tillgänglig på klienten (hanterad applikation), på servern eller i läge för extern anslutning.

Dessutom, om du byter konfigurationsredigeringsläge till Hanterad applikation och vanlig applikation, kommer en annan kompileringskontext att vara möjlig - Klient (vanlig applikation).

Det finns alltså fyra alternativ för hur programmet fungerar. Beroende på kör applikation, beroende på arbetet på klienten eller servern, kommer vissa gemensamma moduler att vara tillgängliga eller otillgängliga.

Utöver möjligheten att specificera kompileringsflaggor är det möjligt att specificera kompileringsdirektiv för procedurer och funktioner som finns i Common Module.

Om ett kompileringsdirektiv specificeras för en metod, så kommer, även om den gemensamma modulen är tillgänglig i alla angivna sammanhang, tillgängligheten för den specifika metoden att begränsas av kompileringsdirektivet.

I det här fallet kan proceduren inte nås i ett sammanhang som inte är tillgängligt för hela modulen.

Om du inte anger ett kompileringsdirektiv för en procedur (funktion) kommer den att kompileras i alla sammanhang som definieras för modulen.

Dessa. I huvudsak kommer flera kopior av proceduren att göras. Valet av en viss kompilerad instans beror på var proceduren anropas (av den närmaste anropsregeln). Det bör beaktas att koden för ett sådant förfarande måste skrivas med hänsyn till dess tillgänglighet i alla sammanhang som definieras för modulen.

Generiska moduler som samtidigt är tillgängliga i flera olika sammanhang är i första hand utformade för att skapa procedurer som är tillgängliga i flera sammanhang.

När du skapar en allmän modul anses det vara god praxis att inte specificera kompileringsdirektiv. Dessa. Tillgängligheten av procedurer och funktioner bör bestämmas av egenskaperna för själva modulen.

Med detta tillvägagångssätt kommer klientprocedurer att placeras i separata gemensamma moduler och serverprocedurer kommer att finnas i separata gemensamma moduler.

Moduler som har flera kompileringsflaggor används extremt sällan i praktiken. Det här är några vanliga åtgärder som är tillgängliga på både klient och server. Vanligtvis är det några enkla beräkningar.

Viktig! Det är möjligt för klienten att komma åt exportservermetoder för en gemensam modul, men endast om denna gemensamma modul endast kompileras på servern. I detta fall tillhandahålls en speciell flagga för att säkerställa åtkomst från klienten .

För icke-globala Common-moduler är det möjligt att cachelagra värdena som returneras av funktioner. Dessa. Efter det första anropet av en funktion kan systemet komma ihåg resultatet av dess exekvering. Om denna funktion kommer att anropas igen med samma parametrar, kommer systemet att returnera värdet från cachen.

Syftet med denna mekanism är att påskynda upprepade samtal. För att konfigurera detta beteende måste du Egenskaper palett modul, ställ in lämpligt värde för egenskapen Återanvändning av returvärden.

Som standard är den här egenskapen inställd på Använd inte. Andra möjliga värden: cache Under samtalet, eller Under sessionens varaktighet.

Den här egenskapen är vettig att endast använda för de funktioner vars resultat enbart beror på ingångsparametrarna. Denna mekanism Endast tillgängligt för icke-globala gemensamma moduler.

Om värdet för motsvarande parameter har valts Under samtalets varaktighet kommer cachen att fungera så länge som proceduren från vilken General Module-metoden anropades körs. Om värdet Under sessionens varaktighet är valt, antas det villkorligt att cachen kommer att fungera medan användaren arbetar.

Det finns dock vissa tidsbegränsningar. Cachen rensas automatiskt 20 minuter efter att värdet kommit in i cachen.

Formulärmodul

Den här modulen är utformad för att bearbeta användaråtgärder. Beskriv till exempel algoritmen för hur ett program reagerar när en knapp trycks ned. Eller, till exempel, när du anger ett värde i ett fält, kontrollera omedelbart om det är korrekt.

Förutom händelser som är kopplade till formulärkontroller (knappar, inmatningsfält) finns det händelser direkt kopplade till själva formuläret.

Du kan till exempel hantera formulärets öppningshändelse och utföra viss initialisering. Du kan också hantera formulärstängningshändelsen och kontrollera om användaren har skrivit in allt korrekt.

Det finns kontrollerade formulär och vanliga formulär. Modulerna i dessa former skiljer sig främst genom att modulen kontrollerad form tydligt åtskilda av sammanhang. Varje procedur (funktion) måste ha ett kompileringsdirektiv. I normal form används all kod på Klienten.

I en hanterad formulärmodul kan du deklarera procedurer och funktioner, du kan deklarera variabler och du kan beskriva en del av huvudprogrammet.

Programkoden för huvudprogrammet kommer att exekveras vid tidpunkten för initiering av formuläret, dvs. när användaren börjar öppna den. Bilden visar en lista över standardhändelser för ett hanterat formulär.

Listan över händelser för ett hanterat formulär är också synlig i listan över egenskaper direkt för själva formuläret. Den här listan anropas i redigeraren för hanterade formulär.

I ett hanterat formulär kan du hantera objektets skrivhändelse. Denna händelse är endast närvarande för objektformulär (kataloger, dokument och några andra). Om formuläret inte är bundet till ett specifikt objekt, så finns det ingen skrivhändelse.

För en modul av vanlig form är listan över standardhändelser något mindre, eftersom I en hanterad form görs många händelser för att paras (en exekveras på klienten och den andra på servern). I sin normala form exekveras all kod på klienten.

Objektmodul

Dessa moduler är typiska för kataloger, dokument, planer för typer av beräkningar, kontoplaner och många andra objekt. Objektmodulen är designad för att hantera standardhändelser. Till exempel en händelse för att gå in i ett katalogelement, en händelse för att skriva ett element, ta bort, lägga upp ett dokument, etc.

Skrivhändelsen finns i princip även i formulärmodulen. Men skrivhändelsen i formulärmodulen inträffar under den interaktiva inspelningsprocessen, när man arbetar med ett specifikt formulär.

Write-händelsen i objektmodulen kommer att exekveras på valfri skrivning från vilken form som helst av det givna objektet. Dessutom, om objektet skrivs programmatiskt, kommer objektets modulhändelse att aktiveras.

I skrivhändelsen av objektmodulen kan du bygga in alla kontroller för att data som skrivs är korrekta, eftersom denna procedur kommer att utföras vid tidpunkten för absolut all inspelning.

Modulen för detta objekt kan anropas via snabbmenyn, från paletten Objektegenskaper och från objektredigeringsfönstret.

Bilden nedan visar en lista över tillgängliga katalogmodulhändelser.

I objektmodulen kan du placera en sektion för att beskriva variabler, beskriva godtyckliga funktioner som kanske inte är associerade med en händelse, samt en sektion av huvudprogrammet.

I huvudprogramsektionen kan du till exempel initiera lokala variabler för en given modul. Denna programkod kommer att exekveras när denna objektmodul används.

Det bör noteras att alla procedurer för objektmodulen är kompilerade på servern. Följaktligen krävs inte kompileringsdirektiv för procedurer och funktioner för objektmodulen. Vissa konfigurationsobjekt har inte objektmoduler.

Detta beror på egenskaperna hos själva föremålen. Sådana föremål inkluderar Konstanter Och Register. För Konstant det finns ingen objektmodul, men det finns en mycket liknande modul som kallas Värdehanterare modul.

I Värdehanterare modul du kan hantera skrivhändelser Konstanter och.

Hela modulkontexten exekveras på servern.

För register finns en Recordset Module.

Denna modul har också förmågan att hantera skrivhändelser och utföra beläggningskontroller.

I Object Modules, Value Manager Modules (för konstanter) och Recordset Modules (för register) kan du beskriva metoder som kan göras exporterbara, och dessa metoder kommer att vara tillgängliga utifrån.

Dessa. Förutom att använda fasta metoder för en objektklass kan du skapa för ett objekt ytterligare metoder i objektmodulen. Denna modul ska beskriva motsvarande procedur med nyckelordet Exportera.

Då kommer det att vara möjligt att komma åt denna procedur utifrån. Dessutom denna metod kommer att visas i det sammanhangsberoende verktygstipset. Nya metoder i sammanhangsverktygstipset är markerade med blått teckensnitt (blå ikon p() för procedurer och f() för funktioner).

På samma sätt kan du skapa en ny egenskap genom att deklarera en variabel med nyckelordet Exportera. Denna fastighet kan också nås utifrån.

På så sätt är det möjligt att utöka funktionaliteten hos objekt (för att definiera nya metoder och nya egenskaper). Egenskaperna är dock dynamiska och sparas inte i databasen.

Om du behöver använda en egenskap för ett objekt som ska lagras i databasen bör du skapa ett objektattribut.

Managermodul

Denna modul finns för många objekt (kataloger, dokument, register, etc.). Modulen öppnas antingen via snabbmenyn för objektet eller genom Egenskaper palett, eller genom redigeringsfönstret.

I Manager-modulen kan du åsidosätta vissa standardhändelser till exempel i BearbetarReceivingSelectionData, när ett element väljs från katalogen kan ytterligare filtrering eller kontroll göras.

Dessutom kan du skapa ytterligare metoder i Manager Module och ange att de är exportmetoder. I det här fallet är det möjligt att komma åt dessa metoder utifrån.

För att utföra detta samtal är det nödvändigt att erhålla datatypen Directory Manager.

Skillnaden mellan exportmetoderna för Manager Module och Object Module är att för att komma åt metoden för Object Module måste du först skaffa själva objektet (det vill säga på något sätt skaffa en länk och sedan konvertera denna länk till ett objekt) .

Efter detta kommer exportvariabler och metoder för objektmodulen att vara tillgängliga. För Manager Module är samtalet enklare, till exempel:
Directorys.Counterpartyes.MethodName

Det är två olika överklaganden. Konvertera från referens till objekt (metod GetObject) är en ganska allvarlig åtgärd för systemet, eftersom när man tar emot ett objekt läses absolut all data för detta objekt, vilket kan vara ganska långt.

Den andra skillnaden är att Objektmodul kallas i samband med ett specifikt element. Följaktligen kan det anses vara tillämpligt för av detta element(i de flesta fall är detta exakt logiken).

När det gäller Manager-modulen, beskriver den en vanlig åtgärd för en grupp eller för alla delar av en katalog eller något dokument. Om du till exempel behöver skriva ut ett katalogobjekt kan du använda objektmodulen.

Men i Manager Module är det möjligt att skapa en mer universell mekanism som skriver ut bland annat en grupp av element.

Dessutom är åtkomst till objektmodulen fortfarande en längre åtgärd. Därför är det mer att föredra att lösa detta problem i managermodulen.

Detta avslutar vår bekantskap med modulerna i 1C:Enterprise-systemkonfigurationen. Om vi kort sammanfattar allt ovan, är slutsatserna följande slutsatser:

En mjukvarumodul är en del av konfigurationen som endast kan innehålla text på det inbyggda 1C-språket
Mjukvarumoduler klassificeras enligt de typer som vi diskuterade i den här artikeln. Varje vy bestäms av dess placering och tillgängliga programsammanhang.
Modulens struktur består av flera sektioner, som är arrangerade i en viss sekvens. Sammansättningen av sektioner bestäms av typen av modul.

Observera också att vi medvetet har utelämnat en typ av modul, nämligen kommandomodulen. Det är inget anmärkningsvärt, och vi inbjuder dig att bekanta dig med dess funktionalitet.

Hittills har vi tittat på all vår programkod i fragment från applikationslösning, och som regel skrev de det i några små testkonfiguration. Är du medveten om att "du kan inte bara gå" och börja redigera koden för en standardkonfiguration? Inga? Sedan i nästa artikel kommer vi att förklara allt!

Nästan alla konfigurationsobjekt har en hanterarmodul och för de flesta objekt en objektmodul. Ofta förstår nybörjare inte skillnaderna i syftet med dessa två moduler.

Genom att förstå skillnaden i deras syfte kan du skriva programkod som är mer korrekt i strukturen och i vissa fall spara 1C-serverresurser och öka applikationslösningens prestanda.

I artikeln kommer vi att titta på de grundläggande skillnaderna mellan dessa moduler både från den teoretiska sidan och med hjälp av ett specifikt praktiskt exempel.

Teori

Låt oss gå till grunderna för objektorienterad programmering (OOP) och dra en analogi med vårt exempel. I OOP kan metoder för objekt delas in i statisk och enkel. Enkla metoder kan endast anropas på ett specifikt objekt som vi har tillgång till i den aktuella kodkontexten. Statiska metoder inte har direkt tillgång till objektdata. För att komma åt ett objekt måste du först skapa en instans av det. Detsamma gäller plattformen 1C:Enterprise 8.x.

I objektmodulen lagrar plattformen procedurer och funktioner som endast kan anropas när man arbetar med ett specifikt objekt, till exempel med objektet för katalogposten "Nomenklatur". Managermodulen innehåller procedurer och funktioner som kan appliceras på alla objekt av denna typ, men med den första skapandet av en instans av detta objekt. Det vill säga, för att ändra en nomenklaturpost från denna modul, kör först metoden "GetObject()" för att referera till elementet och arbeta sedan med det.

Låt oss gå vidare från teori till praktik.

Öva

Låt oss gå vidare till ett praktiskt exempel. Låt oss anta att vi behöver lösa problemet med att skriva ut en lista över produkter. Användaren skriver ut en produkt antingen direkt från ett katalogelement eller från produktlistan. Låt oss överväga två sätt att slutföra uppgiften.

Utskriftsprocedur i objektmodul

Lägg till följande funktion i katalogobjektmodulen:

// Skicka en referens till ett katalogelement till funktionen Funktion PrintSelectedProducts(Link) Export TabDoc = New TabularDocument; Layout = Kataloger. Gods. GetLayout("Layout"); Request = Ny begäran; Begäran. Text = " VÄLJ | Produkter Request = Ny begäran; . Presentation AS Produkt, || Gods . MarkDeletion,. Artikel FRÅN| Katalog

. Produkter AS Produkter |VAR | Gods

. Länk B(&Product Array)

" ; Request. SetParameter(" Array of Products ", Link); //Välj via länk Programkoden är helt genererad av tryckdesignern. Det enda som är värt att notera är visningen med hänvisning till katalogelementet "Produkter" i begäran. Referensen skickas som en parameter till funktionen. Som ett resultat av anropet kommer funktionen "PrintSelectedProducts" att returneras kalkylarksdokument med en färdig produktposition. Programkoden för att anropa objektmetoden "PrintSelectedProducts" med hjälp av formulärkommandot "Print" presenteras i följande lista:&På klientprocedur Skriv ut (kommando) // Kontakta serverproceduren för att få det genererade kalkylarksdokumentet TabDoc = PrintServer() ; // Visa det genererade kalkylarksdokumentet TabDoc. Show() ; EndProcedure & OnServer-funktion PrintServer()

// Konvertera formulärobjektet till ett katalogobjekt "Produkter" för att anropa en funktion från objektmodulen

ObjectItem = FormAttributeValue("Objekt" ) ;

// Anropa objektmodulproceduren och skicka en länk till det aktuella katalogelementet dit. Resultat

// gå tillbaka till klientdel Layout = Kataloger. Gods. GetLayout("Layout"); Request = Ny begäran; Begäran. Text = " VÄLJ | Produkter Request = Ny begäran; . Presentation AS Produkt, || Gods . MarkDeletion,. Artikel FRÅN Returnera objektprodukt. PrintSelectedProducts(Object.Link) ; EndFunction Resultat = Begäran. Sikt(); HeaderArea = Layout. GetArea("Titel");

AreaFooter = Layout. GetArea(" Källare ");

TableHeadArea = Layout. GetArea("Tabellrubrik");

TableFooterArea = Layout. GetArea("TableFooter"); DetailRecordsArea = Layout . GetArea("Detaljer"); TabDoc. Rensa() ; TabDoc. Output(AreaTitle) ;

TabDoc. Output(TableHeadArea);

TabDoc. StartAutoGroupingRows() ; SelectionDetailRecords = Resultat. Välj() ; Medan SelectionDetailedRecords. Next() LoopDetailRecordArea. Alternativ. Fill(SelectionDetailRecords) ; TabDoc. Output(DetailedRecordsArea, DetailedRecordsSelection.Level()) ;

EndCycle ;

TabDoc. FinishAutoGroupingRows() ; TabDoc. Output(TableFooterArea); TabDoc. Output(AreaFootground) ; Returnera TabDoc; EndFunction Huvudskillnaden mot en funktion i en objektmodul är funktionsparametern. Nu skickas en array med länkar till produkter som behöver skrivas ut som en parameter. Programkoden för kommandomodulen "Skriv ut" ser ut så här:

I standardkonfigurationen av "Trade Management" version 11 används managermodulen överallt för utskrift av dokument. Om du tittar på "Management"-konfigurationen tillverkande företag", då används managermodulen praktiskt taget inte, eftersom konfigurationen skrevs i äldre versioner av plattformen, där det inte fanns något fullt stöd för denna mekanism.

Konfiguration med exempel från artikeln.

Plattformsmoduler 1C:Enterprise 8.3, 8.2

Vanliga moduler

Funktioner som deklareras med "export"-flaggan i en sådan modul kan anropas från var som helst i konfigurationen. Anropet görs via CommonModuleName.FunctionName().

Sådana moduler har inte en variabel sektion.

Utförandet av vanliga moduler beror på inställningarna i deras egenskaper:

Flagga "Global"

Om denna flagga är inställd, blir sammanhanget för en sådan modul global. Det vill säga, när du kommer åt dess exportfunktioner behöver du inte ange modulnamnet. Men namnen på dess exportfunktioner måste vara unika inom den globala konfigurationskontexten.

Serverflagga

Funktionerna för en sådan modul kan köras på servern.

Flaggan "Klient (vanlig applikation)".

Funktionerna för en sådan modul kan exekveras på klienten i läget regelbunden tillämpning.

Flaggan "Klient (hanterad applikation)".

Funktionerna för en sådan modul kan exekveras på klienten i hanterat applikationsläge.

Flaggan "Serveranrop".

Flaggan är tillgänglig för moduler med flaggan "Server". Tillåter klienten att anropa exportfunktionerna för denna modul (som kommer att köras på servern).

Extern Join-flagga

Exportfunktionerna för en sådan modul kan anropas när du ansluter från en extern källa.

Flagga "Privileged"

I en modul med denna flagga kommer rättighetskontroll att inaktiveras. Lämplig för produktivitet eller administrativa aktiviteter.

Återanvändningsalternativ

Om du aktiverar det här alternativet kommer returvärdena för exportfunktioner att cachelagras omedelbart efter det första samtalet. Cachning är möjligt under samtalets varaktighet (exekveringstiden för en specifik procedur) eller under användarsessionens varaktighet.

Applikationsmodul

Designad för att hantera applikationsstart och uppsägningshändelser. Det finns två typer: för vanliga och hanterade applikationer.

Du bör inte överbelasta det, eftersom det påverkar programmets starttid.

Sessionsmodul

En specialmodul som används för att initiera sessionsparametrar. Det är nödvändigt för att inte duplicera kod i olika applikationsmoduler.

Den bör användas med försiktighet, eftersom modulen kan köras flera gånger, och även kan exekveras utan att ytterligare starta databasen. Utförs före applikationsmoduler.

Med vänlig hälsning, (lärare och utvecklare).

Vad är moduler och vad exakt är de avsedda för? Modulen innehåller programkoden. Dessutom är det värt att notera att till skillnad från 7.7-plattformen, där koden kan finnas i egenskaperna för formulärelement och i cellerna i layouttabellerna, i 8.x-plattformen måste vilken kodrad som helst finnas i någon modul. Vanligtvis består en modul av tre sektioner - en sektion för att beskriva variabler, en sektion för att beskriva procedurer och funktioner och en sektion för huvudprogrammet. Denna struktur är typisk för nästan alla plattformsmoduler, med några undantag. Vissa moduler har inte en variabel beskrivningssektion eller en huvudprogramsektion. Till exempel sessionsmodul och valfri allmän modul.

Exekveringskontexten för moduler är i allmänhet uppdelad i klient och server. Dessutom kan vissa moduler kompileras både på klientsidan och på serversidan. Och vissa är uteslutande på serversidan eller klientsidan. Så:

Applikationsmodul

Modulen är utformad för att fånga ögonblicken för applikationsstart (konfigurationsladdning) och avbrytande av dess drift. Och verifieringsprocedurer kan placeras i motsvarande händelser. Till exempel, när du startar en applikation, uppdatera några referenskonfigurationsdata och när du avslutar arbetet, fråga om det är värt att lämna det överhuvudtaget, kanske arbetsdagen inte är över än. Dessutom avlyssnar den händelser från extern utrustning, till exempel handel eller fiskal. Det är värt att notera att applikationsmodulen fångar upp de beskrivna händelserna endast när den startas interaktivt. Dessa. när själva programfönstret skapas. Detta händer inte om applikationen startas i com-anslutningar.

Det finns två olika applikationsmoduler i 8.2-plattformen. Dessa är modulen Regular Application och Managed Application. De utlöses när olika klienter lanseras. Så här aktiveras den hanterade applikationsmodulen när webbklienten startar, tunn klient och tjock klient i hanterat applikationsläge. Och den vanliga applikationsmodulen utlöses när den tjocka klienten startas i normalt applikationsläge.

En applikationsmodul kan innehålla alla avsnitt - beskrivningar av variabler, procedurer och funktioner, samt beskrivningar av huvudprogrammet. Applikationsmodulen är kompilerad på klientsidan, så detta begränsar oss i hög grad när det gäller tillgången på många typer av data. Du kan utöka sammanhanget för en applikationsmodul med metoder för vanliga moduler som har egenskapen "Serveranrop". Alla variabler och metoder som är markerade som export kommer att vara tillgängliga i alla konfigurationsmoduler som körs på klientsidan. Men hur frestande det än är bör du inte lägga upp ett stort antal metoder här. Ju mer kod den innehåller, desto längre blir kompileringstiden och därför starttiden för applikationen, vilket är väldigt irriterande för användarna.

Som nämnts ovan hanterar applikationsmodulen applikationsstart och avslutningshändelser. För att hantera var och en av dessa händelser i applikationsmodulen finns det ett par hanterare Före... och När... Skillnaderna mellan dem är sådana att när man kör koden i Före...-hanteraren har åtgärden inte ännu ägt rum och vi kan vägra att verkställa det. Detta är vad alternativet Avvisa är till för. I On..-hanterarna har åtgärden redan ägt rum och vi kan inte vägra att starta programmet eller avsluta det.

Extern anslutningsmodul

Syftet med modulen liknar syftet med applikationsmodulen. Den bearbetar applikationens start- och slutpunkter. Den externa anslutningsmodulen utlöses när applikationen startas i com-anslutningsläge. Själva den yttre sammanfogningsprocessen är en icke-interaktiv process. I detta läge sker programmatiskt arbete med informationsbasen och applikationsfönstret öppnas inte, vilket medför vissa begränsningar för användningen av metoder avsedda för interaktivt arbete. I detta läge kan anrop till dialogformulär, varningsmeddelanden etc. inte användas. De kommer bara inte att fungera.

Liksom i applikationsmodulen finns avsnitt för beskrivning av variabler, metoder och ett avsnitt för huvudprogrammet tillgängliga här. Du kan också deklarera exportvariabler och -metoder. Skillnaden är att i com-connection-läge sker allt arbete med infobasen på serversidan, så den externa anslutningsmodulen kompileras uteslutande på servern. Följaktligen är exportvariabler och metoder för vanliga klientmoduler inte tillgängliga i den.

Sessionsmodul

Detta är en mycket specialiserad modul och är endast avsedd för att initiera sessionsparametrar. Varför behövde du göra din egen modul för detta? Detta beror på det faktum att initieringsprocessen kan kräva exekvering av viss kod, och dessutom kan applikationen startas under olika klienter (vilket leder till exekvering av olika applikationsmoduler eller en extern anslutningsmodul), och initiering av sessionsparametrar måste göras i valfritt startläge. Därför krävdes en extra modul som körs i valfritt programstartläge.

I sessionsmodulen finns det en enda händelse "SettingSessionParameters", som exekveras allra först, även före applikationsmodulhändelsen BeforeSystemStartOperation. Sektionen för variabeldeklaration och huvudprogramsektionen är inte tillgängliga i den. Du kan inte heller deklarera exportmetoder. Modulen kompileras på serversidan.

Du bör inte frestas av det faktum att den här modulen exekveras när applikationen startas, och du bör inte placera kod i den som inte är direkt relaterad till initieringen av sessionsparametrar. Detta beror på det faktum att SetSessionParameters-hanteraren kan anropas upprepade gånger under systemdrift. Detta händer till exempel i de fall vi kommer åt oinitierade parametrar. Och även om det är möjligt att fånga ögonblicket för den första lanseringen av denna händelse (Obligatoriska parametrar är av typen Odefinierad), bör det beaktas att denna modul är kompilerad i privilegierat läge, dvs. den styr inte åtkomsträttigheter. Och den andra punkten är att vi fortfarande inte kan vara hundra procent säkra på att systemet kommer att lanseras. Plötsligt uppstår ett fel i applikationsmodulen och vi försöker utföra några åtgärder med databasen.

Vanliga moduler

Moduler är avsedda att beskriva några vanliga algoritmer som kommer att anropas från andra konfigurationsmoduler. Den allmänna modulen innehåller inte en variabelbeskrivningsdel och en huvudprogramdel. Du kan deklarera exportmetoder i den, vars tillgänglighetskontext kommer att bestämmas av kompileringsflaggor. På grund av att variabelbeskrivningssektionen inte är tillgänglig kan inte globala variabler definieras i vanliga moduler. För att göra detta måste du använda funktionerna i vanliga moduler med cachelagring av returvärden eller en applikationsmodul. Det är värt att komma ihåg att även om den delade modulens återanvändningsegenskap är inställd på "Under sessionens varaktighet", så i detta fall överstiger inte livslängden för cachade värden 20 minuter från ögonblicket för den senaste åtkomsten till dem.
Beteendet för en gemensam modul beror på de parametrar som ställts in (global eller inte, olika kompileringsflaggor, om ett serveranrop är tillgängligt, etc.). I den här artikeln kommer vi inte att överväga alla typer av inställningar, såväl som beteendeegenskaper och fallgropar som uppstår när du sätter in egendomsflaggor på ett orimligt sätt. Detta är ett ämne för en separat artikel. Låt oss uppehålla oss vid bara några punkter som bör följas när du sätter flaggor:

En bra tumregel är att inte använda den globala flaggan överallt. Detta kommer att minska starttiden för applikationen och även förbättra kodens läsbarhet (naturligtvis om den gemensamma modulen har ett helt meningsfullt namn).
Det är inte tillrådligt att använda mer än en kompileringsflagga. Det finns inte många metoder som behöver exekveras i olika sammanhang, och om sådana metoder fortfarande krävs kan en separat gemensam modul allokeras för dem.
Flaggan "Serveranrop" är bara vettig om modulen är kompilerad "På servern". Därför bör alla andra kompileringsflaggor tas bort för att undvika olika problem.
Om modulmetoderna involverar massiv databehandling, läsning och skrivning till databasen, är det bättre att inaktivera åtkomstkontroll för att öka arbetshastigheten genom att ställa in flaggan "Privileged". Detta läge är endast tillgängligt för delade moduler kompilerade på servern.

Formulärmodul

Den är utformad för att bearbeta användaråtgärder, d.v.s. olika händelser relaterade till datainmatning och bearbetning av korrektheten av deras inmatning. En modul i vanlig form sammanställs helt på klienten. En hanterad formulärmodul är tydligt avgränsad av exekveringskontext, så alla variabler och metoder måste ha ett kompileringsdirektiv. Om direktivet inte är explicit specificerat kommer denna variabel eller metod att kompileras på serversidan. Formulärmodulen innehåller avsnitt för beskrivningar av variabler och metoder samt ett avsnitt för huvudprogrammet.

Objektmodul

Denna modul är typisk för många konfigurationsobjekt och är vanligtvis avsedd för att bearbeta objekthändelser. Till exempel händelser för att spela in och ta bort objekt, händelser för att lägga upp dokument osv.

Vissa objektmodulhändelser duplicerar formulärmodulhändelserna. Till exempel händelser kopplade till en inspelning. Men förstå att formulärmodulhändelser kommer att exekveras exklusivt på objektets specifika formulär. I allmänhet kan det finnas flera av dessa former. Och händelserna i objektmodulen kommer att anropas i alla fall, även i ögonblicket för programmatiskt arbete med objektet. Därför, om du behöver exekvera någon kod i alla fall, är det bättre att använda en objektmodulhändelse för detta.

Objektmodulen kompileras uteslutande på servern. I den kan du definiera exportvariabler och metoder som kommer att vara tillgängliga i andra konfigurationsmoduler. Med dessa egenskaper och metoder kan vi avsevärt utöka objektets funktionalitet.

Objekthanterare modul

Denna modul finns för många konfigurationsobjekt. Huvudsyftet med den här modulen är att omdefiniera standardvalshändelsen som inträffar när man går in på en rad och utöka funktionaliteten hos managern. Modulen kompileras på serversidan. Det låter dig definiera exportegenskaper och metoder. Att anropa chefens exportmetoder kräver inte att man skapar själva objektet.

Till allt ovanstående kan du lägga till en bild av några konfigurationsmoduler och sätt att ömsesidigt anropa metoder i hanterat applikationsläge. Pilen indikerar i vilken riktning du kan vända dig för att anropa motsvarande metod. Som framgår av diagrammet är serverkontexten helt stängd. Men från klientkontexten är det möjligt att komma åt servermetoder.

Symboler på diagrammet: O.M. Klient - Klients gemensamma modul; O.M. Server - Server delad modul; M.F. Klient - Klientprocedurer för formulärmodulen; M.F. Server - Serverprocedurer för formulärmodulen.

Mjukvarumoduler innehåller körbar kod på 1C-språket, vilket är nödvändigt för att kunna svara på ett visst sätt på systemets eller användarens handlingar när visuella utvecklingsverktyg inte räcker. Vi kan även beskriva våra egna metoder (procedurer och funktioner) i mjukvarumoduler.

Vanligtvis består en mjukvarumodul av tre sektioner:

variabelt deklarationsområde;
område för beskrivning av procedurer och funktioner;
huvudtexten i programmet.

Exempel struktur mjukvarumodul:

//***************** VARIABELL DEKLARATIONSOMRÅDE ***********************

Perem Efternamn Export; /
/detta är en global variabel Byt namn, patonym;
//det här är en modulvariabel Perems fullständiga namn;

//detta är också en modulvariabel och kan nås

//från alla förfaranden och funktioner i vår modul

//*************** OMRÅDEBESKRIVNING AV PROCEDURER OCH FUNKTIONER ****************
Procedur Procedur1 () Variabel Summa ; /

/Result är en lokal variabel (procedurvariabel)

Totalt = Efternamn + " "+ Förnamn + " "+ Mellannamn;

Slut på förfarandet

Funktion Funktion1()

// funktionsoperatorer

Return(Efternamn + " "+ Förnamn);

EndFunction

//******************* PROGRAMMETS HUVUDTEXT ***********************
Efternamn = "Ivanov";
Namn = "Ivan";

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

Patronymic = "Ivanovich";
I en viss mjukvarumodul kan något av områdena saknas. Variabelt deklarationsområde

placeras från början av modultexten till den första procedur- eller funktionssatsen eller någon körbar sats. Det här avsnittet kan endast innehålla variabelvariabeldeklarationer. Område för beskrivning av procedurer och funktioner

placeras från den första procedur- eller funktionssatsen till valfri körbar sats utanför huvuddelen av proceduren eller funktionsbeskrivningen. Huvudprogramtextområde

Mjukvarumoduler finns på de platser i konfigurationen som kan kräva en beskrivning av specifika driftsalgoritmer. Dessa algoritmer bör formaliseras i form av procedurer eller funktioner som kommer att anropas av systemet självt i förutbestämda situationer (till exempel när du öppnar ett katalogformulär, när du trycker på en knapp i en dialogruta, när du ändrar ett objekt, etc.) .

Varje enskild mjukvarumodul uppfattas av systemet som en helhet, så alla procedurer och funktioner i mjukvarumodulen utförs i ett enda sammanhang.

Modulexekveringskontexten är uppdelad i klient och server. Dessutom kan vissa programvarumoduler kompileras på både klientsidan och serversidan.

Applikationsmodul (hanterad eller vanlig)

Applikationsmodulen beskriver procedurerna (hanterare) för händelser som initieras i början och slutet av systemet. Till exempel, när applikationen börjar köras kan du uppdatera en del konfigurationsdata, och när du avslutar applikationen kan du fråga om det är värt att avsluta programmet överhuvudtaget. Dessutom avlyssnar den här modulen händelser från extern utrustning, till exempel handel eller fiskal. Det är värt att notera att applikationsmodulen exekveras endast när applikationen startas interaktivt, det vill säga när programfönstret startas. Detta händer inte om applikationen startas i com-anslutningsläge.
I 1C 8-plattformen finns två olika applikationsmoduler. Dessa är modulen Regular Application och Managed Application. De utlöses när olika klienter lanseras. Således utlöses modulen Managed Application när webbklienten, den tunna klienten och den tjocka klienten startas i hanterat applikationsläge. Och den vanliga applikationsmodulen utlöses när den tjocka klienten startas i normalt applikationsläge. Inställningen för programstartläge anges i konfigurationsegenskapen "Basic launch mode".

En applikationsmodul kan innehålla alla 3 sektioner - deklarationer av variabler, beskrivningar av procedurer och funktioner, samt programmets huvudtext. Applikationsmodulen är kompilerad på klientsidan, vilket i hög grad begränsar vår användning av många datatyper. Du kan utöka sammanhanget för en applikationsmodul med metoder för vanliga moduler som har egenskapen "Serveranrop". Alla applikationsmodulvariabler och metoder som är markerade som export kommer att vara tillgängliga i alla konfigurationsmoduler som körs på klientsidan. Men hur lockande det än kan vara, bör du inte placera ett stort antal procedurer och funktioner här. Ju mer kod det finns i en given modul, den längre tid kompilering och följaktligen starttiden för programmet.

Som nämnts ovan hanterar applikationsmodulen applikationsstart och avslutningshändelser. För att hantera var och en av dessa händelser i applikationsmodulen finns det ett par hanterare Före... och När... Skillnaderna mellan dem är följande: vid exekvering av kod i Före...-hanteraren har åtgärden inte ännu ägt rum och vi kan vägra att verkställa det. Detta är vad alternativet Avvisa är till för. I On..-hanterarna har åtgärden redan ägt rum och vi kan inte vägra att starta programmet eller avsluta det.

Extern anslutningsmodul

kan innehålla alla 3 områden
finns i rotsektionen av konfigurationen

Syftet med modulen liknar syftet med applikationsmodulen. Den behandlar start- och sluthändelserna för applikationen. Den externa anslutningsmodulen utlöses när applikationen startas i com-anslutningsläge. Den yttre sammanfogningsprocessen i sig är inte en interaktiv process. I detta läge sker programmatiskt arbete med informationsbasen och applikationsfönstret öppnas inte, vilket medför vissa begränsningar för användningen av metoder avsedda för interaktivt arbete. I detta läge kan anrop till dialogformulär, varningar och meddelanden till användaren etc. inte användas. De kommer helt enkelt inte att avrättas.

Liksom i applikationsmodulen finns alla tre områden tillgängliga här: variabeldeklarationer, beskrivningar av procedurer och funktioner samt programmets huvudtext. Huvudskillnaden mot applikationsmodulen är att i com-connection-läge sker allt arbete med infobasen på serversidan, så den externa anslutningsmodulen kompileras på serversidan. Följaktligen är exportvariabler och metoder för vanliga klientmoduler inte tillgängliga i den.

Sessionsmodul

körs på serversidan
finns i rotsektionen av konfigurationen

Detta är en mycket specialiserad modul som är designad exklusivt för att initiera sessionsparametrar. Varför behövde du göra din egen modul för detta? Dess användning beror på det faktum att själva applikationen kan startas i olika lägen(vilket resulterar i exekvering av antingen en hanterad applikationsmodul, en vanlig applikationsmodul eller en extern anslutningsmodul), och initiering av sessionsparametrar måste göras oavsett startläge. För att inte skriva likadant programkod i alla dessa tre moduler behövde vi ytterligare en modul som körs oavsett applikationsstartläge.

Vanliga moduler

kan innehålla ett område som beskriver procedurer och funktioner
körs på server- eller klientsidan (beroende på modulinställningarna)
finns i trädgrenen av konfigurationsobjekten "Allmänt" - "Allmänna moduler"

Gemensamma moduler är avsedda att beskriva några vanliga algoritmer som kommer att anropas från andra konfigurationsmoduler. Den allmänna modulen innehåller inte variabla deklarationsområden och huvudprogramtexten. Du kan deklarera exportmetoder i den, vars tillgänglighet kommer att bestämmas av modulinställningarna (på vilken sida det körs: på server- eller klientsidan). På grund av att variabelbeskrivningssektionen inte är tillgänglig kan inte globala variabler definieras i vanliga moduler. Du kan använda en applikationsmodul för detta.

Beteendet för en gemensam modul beror på de parametrar som ställts in (global eller inte, olika kompileringsflaggor, om ett serveranrop är tillgängligt, etc.). Här är några tips för att ställa in vanliga moduler:

Det är bra att inte använda den globala flaggan överallt. Detta kommer att minska starttiden för applikationen och även förbättra kodens läsbarhet (naturligtvis om den gemensamma modulen har ett helt meningsfullt namn);
- Det är inte tillrådligt att använda mer än en kompileringsflagga. Det finns inte så många metoder som behöver exekveras i olika sammanhang, och om sådana metoder fortfarande krävs kan en separat gemensam modul allokeras för dem;
- "Call server"-flaggan är bara meningsfull om modulen är kompilerad "På servern". Därför bör alla andra kompileringsflaggor tas bort för att undvika olika problem;
- om modulmetoderna involverar massiv databearbetning, läsning och skrivning till databasen, är det för att öka arbetshastigheten bättre att inaktivera åtkomstkontroll genom att ställa in flaggan "Privileged". Detta läge är endast tillgängligt för delade moduler kompilerade på servern.

Formulärmodul

kan innehålla alla 3 områden
exekveras på server- och klientsidan

Formulärmodulen är utformad för att bearbeta användaråtgärder med detta formulär (bearbeta en knappklickshändelse, ändra formulärattribut, etc.). Det finns också händelser som är direkt kopplade till själva formuläret (till exempel dess öppning eller stängning). Moduler av hanterade och vanliga formulär skiljer sig först och främst genom att modulen i en hanterad form är tydligt indelad i sammanhang. Varje procedur eller funktion måste ha ett kompileringsdirektiv. Om kompileringsdirektivet inte är specificerat, exekveras denna procedur eller funktion på serversidan. I sin normala form exekveras all kod på klientsidan.

Strukturen för ett hanterat formulär innehåller en sektion för deklarationer av variabler, beskrivningar av procedurer och funktioner och programmets huvudtext (exekveras vid tidpunkten för initieringen av formuläret). Vi kan komma åt standardformulärhändelser genom listan över förväntade procedurer och funktioner i formuläret (Ctrl+Alt+P), eller genom egenskapspaletten för själva formuläret.

Om ett formulär har ett huvudattribut tilldelat, blir egenskaperna och metoderna för applikationsobjektet som används som huvudattribut tillgängliga i formulärmodulen.

Objektmodul

kan innehålla alla 3 områden
körs på serversidan

Denna modul är tillgänglig för de flesta konfigurationsobjekt och är i allmänhet avsedd för att bearbeta händelser som är direkt relaterade till objektet. Till exempel händelser med inspelning och borttagning av objekt, kontroll av färdigställande av objektdetaljer, postning av ett dokument, etc.

Vissa objektmodulhändelser duplicerar formulärmodulhändelserna. Till exempel händelser kopplade till en inspelning. Det bör emellertid förstås att händelserna i formulärmodulen kommer att exekveras uteslutande i den specifika formen av objektet, det vill säga när det specifika formuläret öppnas. Och händelserna i objektmodulen kommer att anropas i alla fall, även i ögonblicket för programmatiskt arbete med objektet. Därför, om du behöver metoder associerade med ett objekt utan att vara bunden till en specifik form av objektet, är det bättre att använda objektmodulen för detta.

Objekthanterare modul

kan innehålla alla 3 områden
körs på serversidan

Objekthanterarmodulen dök upp först från version 1C 8.2. Managermodulen finns för alla applikationsobjekt och är utformad för att hantera detta objekt som ett konfigurationsobjekt. Managermodulen låter dig utöka funktionaliteten för ett objekt genom att introducera (skriv)procedurer och funktioner som inte relaterar till en specifik instans av ett databasobjekt, utan till själva konfigurationsobjektet. Objekthanterarmodulen låter dig placera allmänna procedurer och funktioner för ett givet objekt och komma åt dem utifrån, till exempel från bearbetning (naturligtvis om denna procedur eller funktion har nyckelordet Exportera). Vad för nytt ger detta oss? I allmänhet ingenting förutom att organisera procedurer efter objekt och lagra dem på separata platser - Objekthanterare-moduler. Vi kan lika framgångsrikt placera dessa procedurer och funktioner i allmänna moduler, men 1C rekommenderar att du placerar allmänna procedurer och funktioner för objekt i Object Manager-modulen. Exempel på användning av procedurerna och funktionerna i modulen Objekthanterare: initial ifyllning av individuella detaljer för en katalog eller ett dokument under vissa villkor, kontroll av att detaljerna i en katalog eller ett dokument under vissa villkor är ifyllda, etc.

Kommandomodul

kan innehålla ett avsnitt som beskriver procedurer och funktioner
exekveras på kundsidan

Kommandon är objekt som är underordnade applikationsobjekt eller konfigurationen som helhet. Varje kommando har en kommandomodul där en fördefinierad CommandProcess()-procedur kan beskrivas för att utföra det kommandot.