1c gør formularelementet obligatorisk. Programmatisk tilføjelse og redigering af administrerede formularelementer

1C:Enterprise-platformen giver dig mulighed for programmæssigt at tilføje og ændre elementer i en administreret formular. Lad os finde ud af, hvorfor det kan være nødvendigt.

Softwareændring af formularen kan være påkrævet i flere tilfælde:

• Ved færdiggørelse af standardkonfigurationer for at lette den efterfølgende opdateringsprocedure. I dette tilfælde vil kun formularmodulet blive ændret. Moduler er meget nemmere at opdatere end formularer.
• Når du implementerer nogle almindelige algoritmer. For eksempel kan der i undersystemet "Forbud mod redigering af objektdetaljer" oprettes en knap programmæssigt for alle objekter, der er forbundet til undersystemet, for at muliggøre muligheden for at redigere detaljer.
• Når du implementerer nogle specifikke algoritmer. I nomenklaturbiblioteket oprettes f.eks. felter til redigering af yderligere detaljer.

I en administreret formular kan du programmatisk tilføje, ændre og slette:

• fornødenheder;
• lokale hold;
• elementer.

Alle disse operationer er kun mulige på serveren.

Programmatisk omformning har begrænsninger:

• Du kan kun slette programmatisk tilføjede detaljer/kommandoer/elementer. Du kan ikke programmere slette objekter, der er oprettet i konfiguratoren.
• Du kan ikke tildele en egenskab som den primære.

Ændring af formularkommandoer

At styre sammensætningen af ​​kommandoer for et objekt ManagedForm der er en samling Hold

Tilføje (< ИмяКоманды >)

Antal ()

Find (< ИмяКоманды >)

Slet (< Команда >)

Teams-samlingen er tilgængelig på både klienten og serveren. Du kan kun ændre samlingen (Add() og Delete() metoderne på serveren. Du kan søge efter og få antallet af elementer (Find () og Count () metoderne) både på klienten og på serveren.

Som et eksempel på at arbejde med formularkommandoer, lad os oprette en ny ChangeHistory-kommando med overskriften "ChangeHistory...", som vil kalde handleren Vis Historie(). Oprettelse sker, når formularen åbnes.

&På server
Procedure WhenCreatingOnServer(Failure, StandardProcessing)
Hold = Hold. Tilføje( "Forandringers historie");
Hold . Handling = ;
Hold . Titel = "Forandringers historie...";
Afslutning af procedure
&OnClient
Procedure Connectable_DisplayHistory(Kommando)
// kommando handlinger
Afslutning af procedure

Kommandobehandleren skal være placeret på en formular og have et &OnClient-kompileringsdirektiv.

Ændring af formularoplysninger

Læsning af formulardetaljernes sammensætning udføres af funktionen Få detaljer(< Путь >) returnerer en matrix af typen FormAttributes. Funktionsparameteren angiver stien til den overordnede attribut (som en streng). Hvis parameteren udelades, eller der er angivet en tom streng, returneres detaljerne på øverste niveau.

Ændring af detaljerne sker ved hjælp af metoden Skift detaljer(<Tilføjet detaljer>, <Aftagelige detaljer>) objekt ManagedForm. Til parametre Tilføjet detaljer Og Aftagelige detaljer Arrays med elementer af typen Form Attributes transmitteres.

Opmærksomhed!

Processen med at ændre sammensætningen af ​​detaljer er ret ressourcekrævende. Formen er faktisk ved at blive genskabt. I denne henseende udføres arbejde med formulardetaljer i batch-tilstand.

Lad os oprette en ny formularattribut med navnet Køber:

AddedDetails = New Array;
Tilføjet detaljer. Tilføj (Nye formularattributter("Køber", Ny Typebeskrivelse ("DirectoryLink. Modparter"), "Kunde"));

// Ændringer i sammensætningen af ​​detaljer
);

Ændring af formularelementer

At kontrollere sammensætningen af ​​elementer i et objekt ManagedForm der er en samling Elementer. Samlingen har flere metoder:

Indsæt (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

Tilføje (< Имя>, < ТипЭлемента>, < Родитель >)

Antal ()

Find (< Имя >)

Bevæge sig(< Элемент>, < Родитель>, < МестоРасположения >)

Slet (< Элемент >)

Varesamlingen er tilgængelig på både klienten og serveren. Rediger en samling (Indsæt metoder () , Tilføj () , Flyt () og Slet () ) er kun tilgængelige på serveren. Du kan søge efter og få antallet af elementer (Find () og Count () metoderne) både på klienten og på serveren. Samlingselementer kan være:

• FormGroup;
• FormTabel;
• Formfelt;
• Form knap.

Du kan programmæssigt tildele hændelseshandlere til formelementer. Metoden er beregnet til disse formål SetAction(< ИмяСобытия>, < Действие >) .

Lad os se på nogle af de mest almindelige eksempler på at arbejde med kommandoer, detaljer og formularelementer.

Tilføjelse af en kommando og dens tilhørende knap:

// Opret en kommando
Hold = Hold. Tilføje( "Forandringers historie");
Hold . Handling = "Plug-in_DisplayHistory"; // Skemaet skal indeholde en procedure med det angivne navn
Hold . Overskrift = "Forandringers historie...";
// Opret en knap og tilknyt den til en kommando
Element = genstande. Tilføje( "Forandringers historie", Type("FormButton" ));
Element.CommandName = "Forandringers historie";

Tilføjelse af en attribut og det tilhørende inputfelt:

// Beskrivelse af de tilføjede detaljer
AddedDetails = New Array;
Tilføjet detaljer. Tilføje(Ny formrekvisitter ("Køber", ny typebeskrivelse ( "DirectoryLink. Modparter"), "Kunde" ));
// Ændring af sammensætningen af ​​detaljer
ChangeDetails(Tilføjede detaljer);
// Oprettelse af et inputfelt og forbindelse med attributter
Element = genstande. Add("Køber" , Type("FormField" ));
Element . View = FormFieldView. Indtastningsfelt;
Element . PathToData= "Køber" ;

Tildeling af en hændelseshandler til et formularelement:

Varekunde. IndstilAktion("Når det ændrer sig", "Connected_BuyerOnChange");

&OnClient
Procedure Connected_BuyerOnChange(Element)
// Begivenhedshandlinger
Afslutning af procedure

Opmærksomhed!

Procedurer, der er indstillet som hændelseshandlere fra kode ved hjælp af metoden SetAction(), anbefales det at sætte præfikset Connectable_.

Opmærksomhed!

Du kan downloade behandlingen med eksempler på programmatisk søgning og ændring af detaljer, kommandoer og elementer i en administreret formular.

Og dataoverførselsobjekt til kodestrukturering, kontrolleret form i 1C 8.2-miljøet.

Introduktion

I 2008 kom en ny version af 1C platformen: Enterprise 8.2 (herefter benævnt Managed Application), som fuldstændig ændrer hele arbejdslaget med grænsefladen. Dette inkluderer kommandogrænsefladen, formularer og vinduessystemet. Samtidig ændres ikke kun modellen til udvikling af brugergrænsefladen i konfigurationen, men også en ny arkitektur til at adskille funktionalitet mellem klientapplikationen og serveren.
Den administrerede applikation understøtter følgende typer klienter:

• Tyk klient (normal og administreret starttilstand)
• Tynd klient
• Web klient

• Deklarativ, ikke "pixel for pixel" beskrivelse af strukturen. Den specifikke placering af elementer udføres automatisk af systemet, når formularen vises.
• Al funktionalitet af formularen er beskrevet som detaljer Og hold. Detaljer er de data, som formularen arbejder med, og kommandoer er de handlinger, der skal udføres.
• Formularen kører på både serveren og klienten.
• I klientsammenhæng er næsten alle applikationstyper utilgængelige, og derfor er det umuligt at ændre dataene i infobasen.
• For hver metode eller formvariabel skal den specificeres kompileringsdirektiv, der definerer udførelsesplaceringen (klient eller server) og adgang til formularkonteksten.

• &OnClient
• &På server
• &PåServerUden kontekst
• &OnClientOnServerUden kontekst

Alle yderligere diskussioner vil handle om højre side af illustrationen, om hvordan man strukturerer modulkoden og hvilke principper der vil tillade dig at implementere effektiv klient-server-interaktion.

Lad os definere problemet

Lad os se på kodestrukturen (formmodul) i flere former for den samme standardkonfiguration og prøve at finde mønstre.
Med struktur mener vi sektioner af kode (oftest er disse kommentarblokke), der er allokeret af udvikleren til at gruppere metoder og kompileringsdirektiver for disse metoder.
Eksempel 1:
Sektion af hændelseshandlere Metode - på klienten Metode - på serveren Metode - på klienten Sektion af serviceprocedurer og funktioner Hjælpeindgangskontrolfunktioner
Eksempel 2:
Serviceprocedurer og funktioner Betalingsdokumenter Værdier Hændelsesbehandlere
Eksempel 3:
Serviceprocedurer på serveren Serviceprocedurer på klienten Serviceprocedurer på serveren uden kontekst Header hændelseshandlere Kommandohændelseshandlere
Eksempel 4:
Generelle procedurer Formhændelsesbehandlere Procedurer for undersystemet "kontaktoplysninger".
I det væsentlige mangler kodestrukturen, eller for at sige det mildt, den ligner det, der var i Forms 8.1:

• Ikke-informative ord "Generelt, Service, Hjælpe".
• Forsigtige forsøg på at adskille klient- og servermetoder.
• Metoder er ofte grupperet efter grænsefladeelementer "Arbejde med tabeldelen Produkter, Kontaktoplysninger".
• Vilkårlig opstilling af metoder og kodegrupper. For eksempel kan hændelseshandlere være øverst i én form, nederst i en anden, slet ikke fremhævet i en tredje osv.
• Og lad os ikke glemme, at alt dette er inden for én konfiguration.
• Ja, der er konfigurationer, hvor ordene "General, Service, Auxiliary" altid er de samme steder, men...

Hvorfor har du brug for kodestruktur?

• Forenkling af vedligeholdelse.
• Forenkle læring.
• Registrering af generelle/vigtige/vellykkede principper.
• ...din mulighed

Hvorfor hjælper den eksisterende udviklingsstandard fra 1C ikke?

• Minimer antallet af serveropkald.
• Maksimal databehandling på serveren.
• Ikke-kontekstuelle serverkald er hurtigere end kontekstuelle.
• Program med klient-server kommunikation i tankerne.
• og så videre.

Designmønstre eller generationsvisdom

• Fjern facade(herefter benævnt Remote Access Interface)
• Dataoverførselsobjekt(i det følgende benævnt dataoverførselsobjekt)

• … Hvert objekt, der potentielt er beregnet til fjernadgang, skal have grænseflade med lav granularitet, hvilket vil minimere antallet af opkald, der kræves for at udføre en bestemt procedure. ... I stedet for at anmode om en faktura og alle dens poster separat, skal du læse og opdatere alle fakturaposter i én anmodning. Dette påvirker hele strukturen af ​​objektet...Husk: fjernadgangsgrænseflade indeholder ikke domænelogik.
• ...hvis jeg var en omsorgsfuld mor, ville jeg bestemt sige til mit barn: "Skriv aldrig dataoverførselsobjekter!" I de fleste tilfælde er dataoverførselsobjekter intet andet end oppustet feltsæt... Værdien af ​​dette modbydelige monster ligger udelukkende i muligheden overføre flere stykker information over netværket i et opkald- en teknik, der har stor betydning for distribuerede systemer.

Eksempler på skabeloner i 1C platformen

I forbindelse med en administreret formular er der mange "Data Transfer Objects". Du kan vælge systemisk Og udviklerdefineret.
System ones modellerer et applikationsobjekt på klienten i form af et eller flere formulardataelementer. Det er umuligt at oprette dem uden henvisning til formulardetaljerne.

• DataFormsStructure
• DataFormsCollection
• DataFormStructureWithCollection
• DataShapesTree

• ValueInFormData()
• FormDataValue()
• CopyFormData()
• ValueInFormAttributes()
• FormAttributesValue()

Dataoverførselsobjekter, hvis struktur bestemmes af udvikleren, er en lille delmængde af de typer, der er tilgængelige på både klienten og serveren. Oftest bruges følgende som parametre og resultater af metoder til en "grov" grænseflade:

• Primitive typer (streng, tal, boolesk)
• Struktur
• Korrespondance
• Array
• Links til applikationsobjekter (unik identifikator og tekstrepræsentation)

Strukturering af koden

• Tydelig adskillelse af klient- og serverkode. Lad os ikke glemme, at disse på udførelsestidspunktet er to interagerende processer, som hver har væsentligt forskellig tilgængelig funktionalitet.
• Tydelig identifikation af fjernadgangsgrænsefladen, hvilke servermetoder kan kaldes fra klienten, og hvilke kan ikke? Navnene på fjerngrænseflademetoder begynder med præfikset "Server". Dette giver dig mulighed for med det samme at se overførsel af kontrol til serveren, mens du læser koden, og forenkler brugen af ​​kontekstuel hjælp. Bemærk, at den officielle anbefaling (ITS) foreslår navngivningsmetoder med postfixes, for eksempel ChangeOrderStatusOnServer(). Vi gentager dog, at ikke alle servermetoder kan kaldes fra klienten, og derfor er logisk tilgængelighed vigtigere frem for kompileringsplacering. Derfor markerer vi med præfikset "Server" kun de metoder, der er tilgængelige for klienten; lad os kalde eksempelmetoden ServerChangeOrderStatus().
• Læsbarhed. En smagssag, vi accepterer ordren, når modulet begynder med procedurerne for oprettelse af en formular på serveren og fjernadgangsmetoder.
• Vedligeholdelse. Der skal være en klar placering for tilføjelse af ny kode. En vigtig pointe er, at metodeskabeloner, der automatisk oprettes af konfiguratoren, tilføjes i slutningen af ​​modulet. Da hændelseshandlere til formularelementer oftest oprettes automatisk, er den tilsvarende blok placeret sidst, for ikke at trække hver handler til et andet sted i modulet.

• Grafisk mulighed – viser tydeligt hovedforløbet af udførelse.
• Tekstindstillingen er et eksempel på et skabelondesign til hurtigt at indsætte en struktur i et nyt formularmodul.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Dato=""/> // <Описание> // // ////////////////////////////////////////////// //////////////////////////// MODULVARIABLER /////////////////// //////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////////////////////////////////////// på//////////////////////////////////////////////////////////////////////////////////// /Indsæt indholdet af handleren Afslutning af procedure //******* FJERNADGANGSinterface ******* //******* FORRETNINGSLOGIK PÅ SERVEREN ******* ///////// /////////////////////////////////////////////////////////////////////////////////// /////// //////////////////// // FÆLLES METODER FOR KLIENT OG SERVER ///////////////// /////// //////////////////////////////////////// ///// //////// // PÅ KUNDEN //******* FORRETNINGSLOGIK PÅ KUNDEN ******* //******* TEAM * ****** //******* KLIENTBEGIVENHEDER ******* ///////////////////////// ///// ////////////////////////////////////////// // / / HOVEDPROGRAMOPERATORER

Relaterede spørgsmål

• Muligheder for implementering af fjernadgangsgrænseflade. Asynkroni, detaljeringsgrad...
• Caching. 1C traf en mislykket arkitektonisk beslutning, idet han kun introducerede caching på niveau med kaldemetoder for fælles moduler og ikke leverede kontrolmuligheder (relevanstid, nulstilling efter behov).
• Implicitte serverkald. Glem ikke de teknologiske funktioner; mange "harmløse" operationer på klienten provokerer platformen til at kontakte serveren.

1. Indtastningsfelt
2. Afkrydsningsfelt
3. Skift

Indtastningsfelt

Som regel er et inputfelt knyttet til en objektattribut og afspejler dens data. Dette er måske et af de mest almindelige elementer, det har flere måder at vælge en værdi på:

Valg fra en liste (List Selection Mode)

Vælg fra en anden formular (vælg-knap)

Kontrolknapper

Implementeringen af ​​ovenstående eksempler kræver ikke væsentlig indsats fra bygherrens side. for eksempel er det for listetilstanden nødvendigt at udfylde listen over et element med værdier; for at vælge fra en anden formular er det nok blot at knytte kontrolelementet til biblioteksdataene. Men for kontrolknapperne skal du skrive mere kode for at behandle klik på hver knap, selvom den ikke vil være stor:

Procedure pvValg af nomenklaturregulering (element, retning, standardbehandling)
//Vælg data til indtastningsfeltet
// i dette tilfælde nomenklaturbiblioteket
Request = Ny anmodning;
Request.Text=
"VÆLGE
| Nomenklatur.Link som produkt
|FRA
| Directory.Nomenclature AS Nomenclature
| BESTIL AF
| Nomenclature.Code";
TZNomenclature = Request.Run().Upload();

//kig efter det aktuelle mappeelement angivet i inputfeltet
CurrentElement = TZNomenclature.Find(Element.value);

Hvis TechElement = Udefineret, så
// hvis elementet ikke findes, så sæt indeksnummeret
// uden for værditabellen, fordi det allerførste element i
// værditabel har indeks 0
TechIndex = -1;
Ellers
// hvis elementet findes, får vi dets indeks
TechIndex = TZNomenclature.Index(TechElement);
Afslut Hvis;

// udregn et nyt indeks afhængigt af tastetrykket
// minus foran variablen Retningen placeres således, at når
// ved at klikke på den øverste pil viste elementet over det
// og derfor med et mindre indeks
NewIndex = TechIndex-Direction;

// få antallet af elementer i mappen
// trække en fra, fordi alle samlinger i 8.1 starter ved 0
Number ofElements = TZNomenclature.Quantity()-1;

Hvis NovIndex< 0 Или НовИндекс >Antal elementer derefter
// hvis indekset er uden for værditabellen ved ændring
// dvs. dens tal er større end det største indeks eller mindre end 0 da
// ændre ikke værdien og informer brugeren om det
Notify("Du har nået biblioteksgrænsen");
Ellers
// tildel en ny værdi, "Produkt" er navnet på kolonnen i værditabellen
Element.value = TZNomenclature.Get(NewIndex).Product;
Afslut Hvis;

Afslutning af procedure

Afkrydsningsfelt

I de fleste programmer tjener et afkrydsningsfelt til at vise to tilstande: markeret, umarkeret. I 1c har afkrydsningsfeltet tre tilstande; i den tredje tilstand vises afkrydsningsfeltet som markeret og samtidig skraveret. De tre tilstande er kun tilgængelige, hvis afkrydsningsfeltets data er et tal, og tilstandene har følgende betydning:

Kontakt

Kontakten bruges til at vælge én værdi blandt et lille antal mulige (helst ikke mere end fem), og værdierne kan ikke kombineres. For eksempel: velegnet til at vælge en persons køn. Et andet eksempel: lad os sige, at en virksomhed giver en af ​​3 rabatter på et produkt, og rabatterne ikke stemmer overens:

I dette tilfælde kan bekvemmeligheden ved at bruge radioknapper ligge i det faktum, at hver af dem kan have en vis værdi, som er indstillet i egenskaben "Vælgbar værdi". Og så kan "5% rabat" gemme værdien 5 eller 0,05.

Det er vigtigt at huske tre ting, når du bruger kontakter:

Den første switch skal have egenskaben "FirstInGroup" (i dette eksempel er det switchen "5 % rabat").

Omskiftere, der er meningsfuldt relateret til én gruppe, bør gå i en række, når traverseringsrækkefølgen opsættes, uden afbrydelse af andre formularelementer. Gennemløbsrækkefølgen indstilles fra menuen "Formular -> Indstilling af gennemløbsrækkefølge", for dette eksempel ser det sådan ud:

1. Typen af ​​valgt værdi indstilles for switchen, der har egenskaben "FirstInGroup".

Interfaceudvikling i 1C består af to dele - udvikling af en menu eller desktop og udvikling af 1C skærmformularer. De vinduer, som brugeren arbejder med i 1C, kaldes 1C-skærmformularer eller blot 1C-formularer.

Brugere i programmet arbejder med 1C formularer. Desuden ser brugerne kun 1C-formularer. Ud fra et synspunkt om brugervenlighed i programmet er dette et af de vigtige elementer. Samtidig kan du spilde mere tid på at udvikle en 1C-form end at programmere den mest komplekse algoritme.

En almindelig fejl, programmører begår, er at prøve at tegne alt efter deres smag. Gør baggrunden blå og teksten grøn. Eller gul på sort. Eller hvordan han kan lide det i et andet yndlingsprogram.

Desværre er denne tilgang forkert, da brugere er vant til at arbejde med standard 1C-formularer, som er størstedelen i konfigurationen. At tegne din egen cykel og mærke den med Courier-indskrifter som "Copyright Vasya Pupkin" er tydeligvis i dårlig smag.

Nu skal vi igennem et kort uddannelsesprogram om tegning af 1C-skemaer.

Hvad er Forms 1C

Form 1C er en metode til præsentation for brugeren. Typisk består en formular af en række felter, der skal udfyldes, og et sæt knapper (menukommandoer) til at styre. De fleste 1C-objekter har en 1C-form.

Den 1C tykke klient bruger "almindelige" 1C-former. Det betyder, at programmøren blot tegner en 1C-formular med musen, ligesom det gøres i Visual Studio og andre rammer.

Den tynde 1C-klient og 1C-webklienten bruger 1C-administrerede formularer. Det betyder, at deres størrelse, 1C-form og placeringen af ​​felterne på dem ikke kan ændres med musen. De genereres automatisk baseret på indstillingerne. Vi vil tale om administrerede 1C-formularer i de følgende lektioner.

De fleste former for 1C-standardkonfigurationer i 1C har deres egen standardpræsentation, som er velkendt for brugeren.

Sådan fungerer 1C-formularer

Logikken (rækkefølgen) af brugerarbejde i 1C er som følger:

Således arbejder brugeren altid med 1C-formularer, startende med 1C-listeformen og flytter til 1C-elementformen. Hvis programmøren ikke har tegnet formularerne, genererer 1C formularerne som standard. De mangler naturligvis ideel skønhed og perfektion, men de giver dig mulighed for at arbejde.

En automatisk genereret 1C-listeformular indeholder normalt et minimum af felter (henholdsvis kode/navn og dato/nummer). Den automatisk genererede elementformular indeholder normalt alle de felter (detaljer), der er anført fra top til bund.

1C-formularens opgave er at åbne og vente på brugerhandlinger. Når du handler, skal du reagere. Grundlaget for 1C formularmodulet er således hændelseshandlere. Dette er funktioner, der kaldes, når brugeren udfører en handling på 1C-formularen.

Hvor er 1C-formularer placeret?

I 1C Enterprise-tilstand, når du vælger næsten ethvert 1C-objekt (mappe, dokument, rapport, behandling osv.), åbnes formen for dette objekt for dig.

I konfiguratoren, i konfigurationsvinduet, skal du vælge det objekt, du har brug for, og udvide dens gren for at se undergrenen 1C Form.

En anden mulighed er at åbne objekteditoren (to gange med musen eller placere markøren og Enter) og gå til fanen 1C Forms.

Her er en liste over 1C-formularer. En af de tilføjede 1C-formularer kan tilføjes som en standardformular (1C-listeformular, 1C-elementformular og så videre).

Oprettelse af 1C formularer

For at tilføje en ny 1C-formular skal du klikke på knappen Tilføj (Ins på tastaturet). For at indtaste en eksisterende skal du dobbeltklikke på den med musen.

Designeren vil bede dig om at vælge typen af ​​1C-formular - 1C-elementformular, liste. Her kan du tilføje eller fjerne kommandopaneler på 1C-formularen. Oftest efterlades disse indstillinger, som de er, som standard.

1C-formularen åbnes, udfyldt som standard - alle detaljer om 1C-objektet, der findes, er blevet tilføjet til den. Du kan markere den specifikke liste over obligatoriske felter på designerens anden fane.

Unødvendige detaljer kan slettes. For at gøre dette skal du vælge et eller flere felter og trykke på Del.

For at flytte andre detaljer ind i det frie rum skal du vælge dem på samme måde og trække dem med musen.

For at tilføje nye detaljer til 1C-formularen skal du klikke på knappen på Dataplacering-panelet (menuen Form/Dataplacering), markere afkrydsningsfelterne for de elementer, der skal tilføjes, samt "Indsæt etiketter" og "Placer automatisk" afkrydsningsfelter.

Alternativt kan du blot tilføje en kontrol ved at klikke på den tilsvarende knap på panelet nedenfor eller ved at vælge Form/Indsæt kontrol i menuen. Klik på kontrolelementet (feltet) to gange med venstre museknap, og dets egenskaber åbnes. Egenskaben "Data" indeholder navnet på attributten. Her kan du ændre eller tildele den.

Kontrolelementets egenskaber indeholder også afkrydsningsfelter til at kontrollere kontrolelementets udseende. Du kan bruge afkrydsningsfelter til at aktivere eller deaktivere valg, rullemenu, ryd, synlighed og tilgængelighedsknapper.

Næsten alle dokumentformularer bruger bogmærker. Tilføjelse af et bogmærke er det samme som at tilføje en anden kontrol (se ovenfor), du skal blot vælge "Panel" kontrol. For at tilføje en panelside skal du højreklikke på den og vælge Tilføj side. Andre kontrolelementer (felter) trækkes og slippes blot på panelsider.

For at ændre størrelsen på 1C-formularen skal du blot flytte markøren til kanten af ​​1C-formularen, klikke på venstre museknap og blot trække i kanten af ​​1C-formularen.

For at Form 1C virker - dvs. gjorde noget som svar på brugerhandlinger - du skal tilføje handlerfunktioner. Indtast egenskaberne for ethvert element (ved at dobbeltklikke på det med venstre museknap) eller selve 1C-formularen (på samme måde i formularoverskriften). Helt nederst i egenskabsvinduet er der en sektion kaldet "Begivenheder". Vælg en praktisk begivenhed (for alle felter er det normalt "Ved ændring", for formularen "Ved åbning") og klik på knappen med et forstørrelsesglas. Dens hændelseshandler åbnes.

For knapper er tilføjelse det samme. Ud over vilkårlige behandlere kan du dog vælge en af ​​standarderne til denne formular (for mappeformularen er disse nogle standardhandlinger, for dokumentformularen - andre). Vælg blot en af ​​standardhandlingerne i egenskaben "Action" eller klik på krydset, hvis du vil oprette din egen handler.

Sandsynligvis kan ingen algoritmer beskytte databasen mod fejl, der opstår, når brugere indtaster data. De vigtigste problemer forbundet med menneskelig uopmærksomhed kan identificeres i følgende liste:

• Forkert valg af objekt;
• Forkert antal eller tastefejl i navnet;
• Duplikering af bibliotekselementer, deres ikke-unikitet eller fejlsortering;
• Ignorerer udfyldning af felter, der er kritiske for korrekt beregning og problemfri drift af programmet.

Løsningen på det sidste problem er, for den ottende version af 1C-programmet, at kontrollere, at formularoplysningerne er udfyldt.

Kontrol af udfyldelse for en almindelig formular

Når brugeren åbner formularen, hvis starttilstanden er "Normal applikation", er de nødvendige elementer fremhævet med en rød stiplet linje (fig. 1).

Som det fremgår af eksemplet ovenfor, er de obligatoriske felter i dokumentet "Salg af varer og tjenesteydelser" "Nummer" og "Modpart". I dette tilfælde er feltet "Nummer" ikke tilgængeligt til redigering. Det betyder, at når et dokument registreres i informationsgrundlaget, vil det automatisk blive udfyldt i overensstemmelse med de nummereringsregler, der er specificeret for denne organisation.

Registrering af mappeelementer eller bogføring af dokumenter, der indeholder uudfyldte obligatoriske felter, vil medføre en undtagelse (fig. 2).

Ris. 2

Mere detaljeret information om, hvilket specifikt felt der ikke er udfyldt, kan ses i servicemeddelelsesvinduet.

Selve mærket, der informerer om, at feltet skal udfyldes, er sat i egenskaberne for formularelementet. For det:

1. Åbn formularen i konfiguratoren;
2. Højreklik på formularelementet og åbn vinduet "Egenskaber";
3. Det er nødvendigt at markere afkrydsningsfelterne AutoMark Unfilled og AutoSelect Unfilled i "Brug" undermenuen (fig. 3);

Direkte verifikation skrives som regel i objektmodulet.

For kataloger og ikke-posterede dokumenter er det tilrådeligt at kalde færdiggørelseskontrolproceduren, når du optager et element. Dokumenter, der ikke er fuldstændigt afsluttet, kan, hvis de udføres, registreres i databasen, og det er bedre at kalde verifikationsproceduren før dannelsen af ​​bevægelser, det vil sige under udførelsen. Det er tilrådeligt at udføre kontrol i behandlingen og rapporter, der indeholder obligatoriske felter, direkte i knap-klik-behandlingen.

Du kan kontrollere, om værdien, der sendes til feltet, adskiller sig fra tom (standardværdien) ved hjælp af funktionen ValueFilled ("Værdi"). Vær dog opmærksom på, at hvis feltet har en sammensat datatype, vil udførelse af denne funktion give en undtagelse.

Validering i administrerede former

Det særlige ved platformens drift i klient-server-versionen sætter også deres præg på påfyldningskontrollen.

Først skal du forstå, hvilken procedure der følger, når du indtaster et objekt i denne driftstilstand.

Så efter at have klikket på knappen "Optag", "OK", "Bestå":

1. "Før optagelse"-proceduren kaldes på klienten;
2. Dataene overføres til serveren, og de hændelser, der er angivet i formularmodulet på serveren, opstår (her kan du køre ProcessingFillingCheckOnServer proceduren);
3. Formulardataene overføres til objektmodulet på serveren (det bliver muligt at starte standardproceduren ProcessingCheckFill);
4. Data fra modulet returneres til formularmodulet på serveren, og BeforeWritingOnServer-proceduren opstår;
5. Dataene returneres til objektmodulet, og en anden BeforeWrite-procedure opstår;
6. Objektet skrives direkte til databasen.

På et hvilket som helst tidspunkt i dette diagram kan du indsætte CheckFill()-funktionen. Efter at have gennemgået detaljerne, i hvis egenskaber attributten "Fyldningstjek" har værdien "Giv en fejl" (fig. 4), vil denne funktion, hvis mindst en af ​​dem ikke er udfyldt, returnere "False" .

Forskelle mellem behandlerne ProcessingFillCheck() og ProcessingFillCheckOnServer()

På grund af det faktum, at grænsefladen i en administreret applikation kan indeholde både objektdetaljer og direkte formulardetaljer, er disse to procedurer adskilt. Samtidig er de ens i parametre, der kan videregives til handlerne:

1. Afslag (resultatet af kontrollen sendes her);
2. Afkrydsede detaljer (datatype – array, hvis ikke udfyldt, så vil alle detaljer, som "Check filling" er indstillet til i egenskaberne, blive kontrolleret, ellers vil detaljer valgt programmatisk blive behandlet).

ProcessingFillingCheckOnServer()-proceduren giver dig mulighed for at kontrollere detaljer, der ikke er direkte relateret til det objekt, der redigeres. Hver programmør bestemmer selv, hvad og i hvilket omfang han vil tjekke.

ProcessingCheckFill()-proceduren kontrollerer de grundlæggende detaljer.