Formulärdetaljer

En uppsättning formulärdetaljer beskriver sammansättningen av data som visas, redigeras eller lagras i formuläret. Samtidigt ger själva formulärinformationen inte möjlighet att visa och redigera data. Formulärelement (se avsnittet "Formulärelement" i det här kapitlet) associerade med formulärdetaljer används för visning och redigering. Uppsättningen av alla formulärdetaljer kommer att kallas formulärdata.

Viktig! Man måste komma ihåg att, till skillnad från konventionella former, alla data kontrollerad form måste beskrivas i form av detaljer. Det är inte tillåtet att använda formulärmodulvariabler som datakällor för formulärelement.

Det går att tilldela Grundläggande formulärdetaljer, d.v.s. attribut som bestämmer standardfunktionaliteten för formuläret (formulärtillägg). Man bör komma ihåg att en form bara kan ha ett huvudattribut.

Formulärförlängning– det här är ytterligare egenskaper, metoder och formulärparametrar för ManagedForm-objektet, karaktäristiska för objektet som är formulärets huvudelement.

Under formulärutvecklingsprocessen kan du uttryckligen ställa in möjligheten att visa och redigera specifika formulärdetaljer, i termer av roller, med hjälp av egenskaperna Visa och Redigera (för mer information, se avsnittet "Rollbaserade formulärinställningar" i "Redaktörer" ” kapitel). Dessutom kan tillgängligheten för ett visst attribut i själva formuläret konfigureras med hjälp av funktionella alternativ (mer information om funktionella alternativ finns i kapitlet "Konfigurationsgränssnittshantering").

Form attribut egenskap Sparad dataär en indikation på att interaktiv ändring av detaljerna kommer att resultera i ett försök att låsa formulärdata för redigering, samt automatisk installation ett tecken på modifierad form.

Datatyper tillgängliga i en hanterad form

Ett hanterat formulär skiljer sig också från ett vanligt formulär i vilken typ av data den arbetar med. Om den normala formen fungerar med de flesta av de typer som 1C:Enterprise tillhandahåller (inklusive typerna DirectoryObject, DocumentObject, etc.), kan följande kategorier av typer urskiljas i det hanterade formuläret:

• typer som används direkt i formuläret är de typer som finns på sidan av den tunna klienten och webbklienten (till exempel Number, DirectoryLink.Products, GraphicScheme, TabularDocument);

• typer som kommer att konverteras till speciella datatyper – hanterade formulärdatatyper. Sådana typer visas i listan med formulärdetaljer inom parentes, till exempel (DirectoryObject.Products);

• dynamisk lista (för mer information, se avsnittet "Dynamisk lista" i det här kapitlet).

Konvertera applikationsobjekt till formulärdata

Vissa applikationstyper (som DirectoryObject, etc.) finns inte på den tunna klientsidan och webbklienten (se kapitlet Managed Application Concept för mer information). Därför, för att representera sådana applikationstyper i formuläret, har plattformen introducerat speciella datatyper utformade för att fungera i hanterade formulär. Denna funktion i en hanterad applikation gör det nödvändigt att konvertera applikationsobjekt till formulärdata (och vice versa).

Följande datatyper används:

• Form DataStructure – innehåller en uppsättning egenskaper av en godtycklig typ. Egenskaper kan vara andra strukturer, samlingar eller strukturer med samlingar. Denna typ representeras till exempel i formen DirectoryObject.

• En FormDataCollection är en lista med inskrivna värden, liknande en array. Ett samlingselement nås med index eller identifierare. Åtkomst med ID kanske inte är tillgänglig i vissa fall. Detta beror på typen av applikationsobjekt som representeras av denna samling. Identifieraren kan vara vilket heltal som helst. Denna typ representeras till exempel i formen tabellsektion.

• Form DataStructureWithCollection är ett objekt som representeras som en struktur och en samling samtidigt. Det kan behandlas som vilken som helst av dessa enheter. Denna typ representerar till exempel en uppsättning poster i ett formulär.

• Form DataTree – ett objekt utformat för att lagra hierarkisk data.

Ett applikationsobjekt representeras av antingen ett eller flera formulärdataelement. I allmän syn Hierarkin och sammansättningen av formulärdata beror på komplexiteten och sammankopplingen av applikationsobjekten i det hanterade formuläret.

Till exempel kommer ett dokument som innehåller en tabelldel att representeras av ett objekt av typen FormDataStructure (själva dokumentet), till vilket ett objekt av typen FormDataCollection (tabelldelen av dokumentet) är underordnat.

Viktig! När du utvecklar en konfiguration är det viktigt att komma ihåg att applikationsobjekt endast är tillgängliga på servern, medan formulärdataobjekt kan användas på både servern och klienten.

Skicka data mellan klient- och serverdelar av ett hanterat formulär

I själva verket kan vi säga att formulärdata är en enhetlig representation av data från olika applikationsobjekt med vilka formuläret fungerar enhetligt och som finns på både servern och klienten. Det vill säga att formuläret innehåller en viss "projektion" av applikationsobjektdata i form av sina egna datatyper och utför konvertering mellan dem vid behov. Men om konfigurationsutvecklaren implementerar sin egen databehandlingsalgoritm, måste han utföra datakonvertering (från specialiserade typer till applikationstyper och vice versa) oberoende.

När du redigerar formulärdetaljer i en specialiserad redigerare (för mer information, se avsnittet "Formulardetaljer" i kapitlet "Redaktörer") är det möjligt att påverka överföringen av data mellan klienten och servern medan formuläret körs. Informationsredigerarens kolumn används för detta. Använd alltid. Effekten av den här egenskapen skiljer sig för tre typer av attribut:

• För attribut som är underordnade en dynamisk lista (kolumn dynamisk lista):
  • egenskapen aktiverad – attributet läses alltid från databasen och inkluderas i formulärdata;
  • egenskapen är inaktiverad - attributet läses från databasen och inkluderas i formulärdata endast när det är synligt i det här ögonblicket ett formelement associerat med ett attribut eller dess underordnade attribut.

• För rekvisita som är underordnad rörelsesamlingen:
  • egenskapen är aktiverad – dokumentrörelser läses från databasen och kommer att finnas i formulärdata;
  • egenskapen är inaktiverad - dokumentrörelser kommer inte att läsas från databasen och inkluderas inte i formulärdata (om det inte finns något formulärelement som refererar till dokumentrörelser).

• Övriga formulärdetaljer:
  • egenskapen är aktiverad – attributet kommer att finnas i formulärdata, oavsett om det finns minst ett formulärelement som är associerat med attributet eller dess underordnade attribut;
  • egenskapen är inaktiverad - attributet kommer endast att finnas i formulärdata om det finns ett formulärelement kopplat till attributet eller dess underordnade attribut. Till skillnad från dynamiska listattribut spelar inte synligheten för elementet som är kopplat till attributet någon roll här.

Notera. Man bör komma ihåg att egenskapen som ställs in på det överordnade attributet påverkar alla underordnade attribut. Till exempel, om egenskapen Använd alltid rensas för den tabellformade delen av dokumentet, anser systemet att denna egenskap också rensas för alla underordnade detaljer (trots fastighetens faktiska tillstånd).

Metoder för att konvertera applikationsobjektdata till formulärdata

För att konvertera applikationsobjekt till formulärdata och tillbaka finns det en uppsättning globala metoder:

• ValueInFormData(),
• FormDataInValue(),
• CopyFormData().

Viktig! Metoder som fungerar med applikationsobjekt är endast tillgängliga i serverprocedurer. Metoden för att kopiera värden mellan formulärdata är tillgänglig på servern och på klienten, eftersom den inte kräver applikationsobjekt som parametrar.

När du konverterar formulärdata till ett applikationsobjekt måste du ta hänsyn till deras kompatibilitet.

• ValueInFormData() – konverterar ett applikationsobjekt till formulärdata;
• FormDataInValue() – konverterar formulärdata till ett objekt av applikationstyp;
• CopyFormData() – kopierar formulärdata som har en kompatibel struktur. Returnerar True om kopieringen lyckades, eller False om objektstrukturen är inkompatibel.

Notera. När du utför standardåtgärder (öppnar ett formulär, utför ett standardskrivkommando, etc.) av ett formulär med huvuddetaljerna, utförs konverteringen automatiskt.

Låt oss ge ett exempel på hur du använder datatransformation i dina egna algoritmer.

&OnServerProcedure When CreateOnServer(Failure, StandardProcessing)

ObjectProduct = Directories.Products.FindByName("Kaffekanna").GetObject(); ValueInFormData(ObjectItem, Object);

Slut på procedur

&OnClient Procedur Write()

WriteOnServer();

Slut på procedur

&OnServer-procedur WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();

Slut på procedur

ManagedForm-objektet har också metoder tillgängliga på servern:

• ValueВFormAttribute() – konverterar ett applikationstypobjekt till det angivna formattributet.
• FormAttributeVValue() – konverterar ett formulärdataattribut till ett objekt av en applikationstyp.

Att använda dessa metoder är vanligtvis bekvämare, eftersom de har till exempel information om typen av formulärdetaljer. Dessutom ställer metoden Form AttributesValue() in överensstämmelsen mellan formulärdata och objektet, som används när meddelanden genereras. Du kan läsa mer om detta i kapitlet "Servicenavigeringsfunktioner".

Låt oss ge ett exempel på hur du använder dessa metoder.

&OnServer Procedur RecalculateOnServer()

// Konverterar objektattributet till ett applikationsobjekt. Document = Form AttributesValue("Objekt"); // Utför omräkning med den metod som definieras i dokumentmodulen. Document.Recalculate(); // Konverterar applikationsobjektet tillbaka till en prop. ValueВFormAttributes(Dokument, "Objekt");

Slut på procedur

Mjukvarugränssnitt

FormDataTree

• FindById
• GetItems

Beskrivning:

Designad för att modellera ett träd i hanterade formulärdata.

Detta objekt kan serialiseras till/från XDTO. XDTO-typ motsvarande detta objekt definieras i namnområdet. XDTO-typnamn:

GetItems

Syntax:

GetItems()

Returvärde:

Typ: Formulär DataInsamling av trädelement.

Beskrivning:

Får en samling av trädelement på toppnivå.

Tillgänglighet: klient, server, tunn klient, webbklient.

FindById

Syntax:

FindById(<Идентификатор>)

Alternativ:

<Идентификатор>(nödvändig)

Typ: Antal. Trädelementidentifierare.

Returvärde:

Typ: FormDataTreeElement.

Beskrivning:

Får ett samlingselement efter ID.

Tillgänglighet: klient, server, tunn klient, webbklient.

FormDataTreeItem

Egenskaper:

<Имя свойства> (<Имя свойства>)

• GetId (GetId)
• GetParent
• GetItems
• Fast egendom

Beskrivning:

Formulärdataträdelement.

FormDataTreeItemCollection

Samlingselement: DataFormTreeElement

För ett objekt är det möjligt att gå igenom samlingen med operatorn För varje... Från... Slinga. Genomgången väljer elementen i samlingen. Det är möjligt att komma åt ett insamlingselement med [...]-operatören. Indexet för elementet skickas som ett argument.

• Föra in
• Lägg till
• Index (IndexOf)
• Räkna
• Klar
• Skaffa sig
• Flytta
• Radera

Beskrivning:

Samling av träelement.

Tillgänglighet: klient, server, tunn klient, webbklient.

Se även:

• FormDataTreeElement, GetElements-metoden
• DataFormTree, metoden GetItems

Funktioner av att arbeta med ett värdeträd

Uppdatering av träd

Det finns ett problem faller plattformar när du uppdaterar trädet.

Om någon nod i trädet har utökats och en underordnad nod har valts, då när du uppdaterar trädet med funktionen ValueInFormData plattformen faller.

Lösning: Du måste rensa trädet innan du uppdaterar.

Till exempel:

&Om servern Procedur ClearTree(elements) För varje element från elementen Loop ClearTree(element.GetElements()); EndCycle; elements.Clear(); Slut på procedur

&På serverproceduren Fill Concept Tree() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); Slut på procedur

&OnClient Procedur OnDateOnChange(Element) Fill ConceptTree(); Slut på procedur

Användarens arbete med referensböcker och dokument i 1C består av att fylla i fält på formuläret.

1C-detaljer är katalog- och dokumentfält som visas på formuläret för användaren att fylla i.

Låt oss ta en närmare titt på ämnet detaljer i 1C.

Vad är 1C-detaljer

Varje katalog och 1C-dokument består av en uppsättning fält. Sådana fält kallas 1C-detaljer (för en 1C-programmerare).

I konfiguratorn, i 1C-konfigurationsträdet, öppna valfri katalog eller dokument och du kommer att se grenen Detaljer. Detta är en lista med katalogdetaljer (fält).

Se hur samma 1C-detaljer ser ut på 1C-katalogformuläret.

Varje 1C-attribut har egenskaper som indikerar vilken typ av värde som lagras i attributet (sträng, nummer, etc.) och hur användaren kommer att arbeta med det.

Högerklicka på valfritt 1C-attribut och klicka på Egenskaper. En lista med egenskaper för det valda attributet öppnas i fönstret till höger.

Huvudegenskaper för 1C-detaljer:

Standard 1C detaljer

Som du märkte finns det på katalogformuläret 1C-detaljer som inte är listade i konfiguratorn: grupp, namn, BIC.

Kataloglistformuläret innehåller också 1C-detaljer som inte finns i listan: raderingsmärke.

Dessa är standard 1C detaljer. Vad det är? Alla har en standarduppsättning med 1C-detaljer. För kataloger är detta till exempel kod och namn. För dokument är detta datum och nummer.

Standard 1C-detaljer kan ses enligt följande:

• Gå till redigeraren för 1C-objektet (katalog eller dokument) genom att dubbelklicka på det med musen
• Välj fliken Data i redigeraren som öppnas
• Här kan du konfigurera standarddetaljerna Kod och Namn på katalogen
• Klicka på knappen 1C Standard Details för att se hela listan.

Allmänna 1C-detaljer

Från och med version 1C 8.2.14 har ett nytt 1C-objekt dykt upp i 1C - Allmänna 1C-detaljer. Med den kan du lägga till en egenskap (fält) som kommer att finnas i många kataloger och dokument samtidigt.

Egenskaper för allmänna 1C-attribut:

• Autoanvändning – lägger till allmänna 1C-detaljer till alla kataloger och dokument på en gång
• Komposition - låter dig lägga till allmänna 1C-detaljer endast i de nödvändiga katalogerna och dokumenten (automatisk användning är då inställd på Använd inte).

Hur man lägger till 1C-detaljer

Högerklicka på grenen 1C Details i önskad katalog och välj Lägg till.

Vi måste ange namnet på 1C-attributet, till exempel "Kontorsadress" och synonymen "Kontorsadress". Lämna standardtypen som String, men markera kryssrutan Obegränsad längd.

Låt oss lägga till ytterligare ett 1C-attribut på samma sätt, bara vi väljer den booleska typen och kallar den "Arbetar på helger".

Hur man visar detaljer på ett 1C-formulär (1C tjock klient)

Låt oss utöka grenen Formulär i samma katalog. För att öppna formuläret, välj elementformuläret och dubbelklicka på det med musen.

Dra kanten på formen med musen och sträck ut den (valfritt).

Klicka på knappen "Dataplacering" i konfiguratorpanelen. Du kan också använda menyn Formulär/Dataplacering.

Du ser att våra uppgifter inte visas i formuläret. Kolla dem. Och även kryssrutorna Infoga etiketter och Placera automatiskt.

Hur man visar detaljer på 1C-formuläret (1C tunn klient)

Låt oss utöka grenen Formulär i samma katalog. Välj formen på elementet och dubbelklicka på det med musen.

Expandera objektraden på fliken Detaljer. Du kommer att se en lista med detaljer som tidigare lagts till i katalogen.

Dra nu bara det önskade attributet från det högra fönstret till det vänstra och det kommer att visas i formuläret.

Form 1C detaljer

I den tjocka klienten har formuläret sina egna detaljer. De finns på fliken Detaljer.

Dessa uppgifter sparas inte i databasen, men de kan användas på formuläret för de fält som behövs för att arbeta med formuläret.

Du har till exempel lagt till en bock i formuläret. När du klickar på det händer något på formuläret. Innebörden av kryssrutan spelar ingen roll för dig (du behöver inte skriva ner den) - den används bara för att byta form när du arbetar med den. I det här fallet använder du inte katalogattributet som data, utan formattributet.

Periodiska uppgifter 1C

I 1C version 7.7 fanns det periodiska detaljer. Deras betydelse är denna: betydelsen av rekvisita är olika vid olika datum. Till exempel är värdet den 1 september ett och den 1 oktober ett annat. Samma rekvisita.

I 1C 8 finns inga periodiska detaljer. Detta implementeras enligt följande:

Formuppgifterna säkerställer dess koppling till data. I detta fall kan en (och endast en) av detaljerna betecknas som den huvudsakliga; det kanske inte nödvändigtvis är den datatyp som vi ritar formuläret till. Men formulärets beteende kommer att bero på datatypen för huvudattributet. Förutom att formulärets beteende ändras ändras formulärmodulens sammanhang. Tillsammans med formulärets metoder och egenskaper blir objektets metoder och egenskaper, som är värdet på huvudattributet, tillgängliga i det. Det är viktigt att blanketter av typen Free Form inte har grundläggande detaljer. I det här fallet bestäms formulärets beteende endast av användarens inställningar. Låt oss överväga frågor om de grundläggande detaljerna.

Fråga 10.05 i tentamen 1C: Plattform Professional. Vad används huvudformattributet för?

1. Definierar datakällan för formuläret som helhet
2. Definierar plattformens standardmöjligheter för att arbeta med formuläret med data av den typ som anges i huvudattributet
3. För att ge möjligheten att programmatiskt komma åt objektdetaljer från det lokala formulärkontexten
4. Ger visualisering av objektdetaljer i formulärdialogrutan
5. 2 och 3 är korrekta
6. 1 och 2 är korrekta

Rätt svar är nummer sex, se ovan.

Fråga 10.06 i tentamen 1C: Platform Professional. Vad behövs formuläruppgifterna för?

1. För att beskriva innehållet i data som visas, redigeras eller lagras i ett formulär
2. För att visa och redigera data i ett formulär
3. 1 och 2 är korrekta

Rätt svar är det tredje - båda.

Fråga 10.07 i tentamen 1C: Platform Professional. Att tilldela grundläggande attribut till en godtyckligt kontrollerad form...

1. Du måste markera kryssrutan "Grundläggande detaljer" i egenskaperna för formulärattributen
2. du måste fylla i "Data"-egenskapen för formuläret genom att välja önskat formulärattribut

Rätt svar är andra:

Fråga 10.08 i tentamen 1C: Platform Professional. Vad som än är godtyckligt vanlig form tilldela grundläggande detaljer...

1. formuläret måste göras till det huvudsakliga, huvuddetaljerna bestäms automatiskt
2. Du måste markera kryssrutan "Grundläggande detaljer" i egenskaperna för formulärattributen
3. du måste gå till menyn "Redigera", "Grundläggande detaljer" och välja önskat värde
4. du måste fylla i "Data"-egenskapen för formuläret genom att välja önskat formulärattribut

Det fjärde rätta svaret är:

Huvuddetaljerna är markerade i fetstil:

Fråga 10.09 av tentamen 1C: Plattform Professional. Om det finns ett huvudformattribut, är det möjligt att lägga till ett annat huvudattribut?

1. Detta är omöjligt
2. Det är möjligt genom att tilldela lämpligt värde till egenskapen formattribut
3. Det är endast möjligt programmatiskt när du kommer åt "Form"-objektet
4. Detta är möjligt genom att lägga till ytterligare ett värde till motsvarande formegenskap

Det korrekta svaret är det första, det finns strikt ett huvudkrav, eftersom sambandet med föremålet måste vara entydigt.

Fråga 10.113 av examen 1C: Plattform Professional. Vilken av detaljerna i formuläret som presenteras i figuren är den huvudsakliga?

1. Lista över valutakurser
2. DirectoryObject
3. Katalogformulär har inga grundläggande detaljer
4. Katalogformulär har alla grundläggande detaljer

Det andra rätta svaret är det i fetstil.