Men vi har fortfarande ett tomt fält till vänster. Du kan mata ut undersystemkommandon till den:

För att göra detta måste du konfigurera kommandogränssnittet för undersystemet:

För att kommandona ska vara synliga på vänster sida av gränssnittet måste du markera rutorna i åtgärdspanelen:

Som du kan se, förutom kommandopanelen "Skapa", finns det också "Rapporter" och "Tjänst". För närvarande är de inte tillgängliga för oss eftersom vi inte har skapat några rapporter. Låt oss skapa dem och inkludera dem i undersystemet "Prissättning":

Efter detta kan vi lägga till dessa rapporter och bearbetning till kommandogränssnittet:

Efter detta kommer dessa kommandon att visas i kommandopanelen:

För att bearbetningskommandon ska vara tillgängliga för att läggas till i kommandopanelen, är det nödvändigt att denna rapport för det första är en del av detta delsystem, och för det andra måste rättigheterna tilldelas den:

för det tredje måste rapporten ha en layout:

För att tjänsten ska vara tillgänglig måste bearbetningen också ha rättigheter, för det andra måste även denna bearbetning ingå i motsvarande delsystem, och för det tredje måste den ha ett kommando.

Jag publicerar det andra kapitlet i min bok "Development Fundamentals in 1C: Taxi"

Kapitel 2. Vanlig och hanterad 1C-applikation

I det här kapitlet ska vi titta på vad en vanlig och hanterad applikation är och hur de skiljer sig från varandra, men innan dess ska vi titta på konceptet med ett "gränssnitt".

Vad är ett "gränssnitt" egentligen? I huvudsak är detta den gemensamma gränsen mellan två interagerande system (mycket ofta är ett system en person). Låt oss ta en bil till exempel. Har den ett gränssnitt? Ja visst. Men vad är den gemensamma gränsen mellan en bil och en person? För det första är detta en arbetsplats, d.v.s. direkt förarsätet och kontroller (ratt, gaspedal, bromspedal, etc.). För det andra är detta principerna för mänsklig interaktion med en bil, som är någon slags uppsättning regler. Till exempel, för att påskynda en bil måste du trycka på gaspedalen, sakta ner - bromspedalen, för att svänga höger måste du vrida ratten åt höger, etc. Tack vare dessa två enheter kan en person köra bil. Ta bort en sak, och köra bil blir omöjligt.

Det är inte annorlunda i mjukvaruvärlden. Ett system är en person - en operatör, en användare. Och det andra systemet är en applikation skapad för att automatisera en viss typ av mänsklig aktivitet (vi överväger applikationsprogrammering).

Till exempel måste vi självständigt upprätthålla lagerregister: utföra ankomsten av varor till lagret, skriva av dessa varor och övervaka saldon. Vad blir den gemensamma gränsen mellan applikationen, oavsett hur eller var den skrivs, och användaren? För det första är detta informationsinmatningsorgan - annars hur ska du förmedla till programmet att 5 stycken av någon produkt har anlänt till lagret. I vårt fall är detta ett datortangentbord och en datormus. För det andra är det ett system för interaktion mellan en dator och en person. Detta kan till exempel vara ett kommandoradsgränssnitt: Du kommer att använda tangentbordet för att skriva in olika textsträngar (kommandon) och använda dem för att utföra nödvändiga åtgärder (registrera mottagandet av varor, konsumtion av varor, etc.). Ett sådant gränssnitt ser ut ungefär så här: se fig. 1.2.1.

Ris. 1.2.1 Exempel på kommandorad

Den här bilden visar kommandoraden för Windows-operativsystemet med det kan du göra nästan alla operationer som du gör i Utforskaren: kopiera filer, ta bort filer, skapa kataloger, etc.

Denna typ av gränssnitt har länge varit ålderdomlig, och den ersattes av ett grafiskt användargränssnitt (eng. grafiskt användargränssnitt GUI). I detta gränssnitt sker interaktionen mellan användaren och applikationen genom olika grafiska element som ritas på displayen (knappar, ikoner, omkopplare, etc.). I det grafiska gränssnittet har operatören slumpmässig tillgång genom kontroller till eventuella grafiska element. I vårt fall, när vi automatiserar lagerbokföring, kan interaktionen se ut så här: operatören trycker på knappen "Kvitto", produktvalsformuläret öppnas, där operatören väljer önskad produkt från listan och anger dess kvantitet. Om du behöver göra en utgift trycker operatören på knappen "Förbrukning", och ett urvalsformulär öppnas också, där operatören också väljer önskad produkt och anger dess kvantitet. När du behöver kontrollera saldon klickar operatören på knappen "Återstår" och programmet visar resterande varor på lagret. Med hjälp av detta grafiska gränssnitt kan du således mycket framgångsrikt hålla reda på varor i lagret.

Låt oss avsluta med den teoretiska delen och gå direkt till ämnet för detta kapitel. Nämligen till typerna av applikationsgränssnitt för 1C-programmet, som alla är grafiska användargränssnitt. 1C: Enterprise 8-programmet har två globala typer av grafiska applikationsgränssnitt. Dessa är vanligt applikationsläge och applikationsläge för hanterade formulär (eller hanterade applikationer).

Editionsplattformarna 8.0 och 8.1. fungerade endast i normalt läge, högre versioner av plattformen (8.2, 8.3, etc.) kan fungera i både normalt applikationsläge och hanterat applikationsläge.

Normalt applikationsläge

Nästan alla moderna konfigurationer fungerar redan i hanterat läge, men det finns fortfarande organisationer som använder äldre konfigurationer som fungerar i normalt applikationsläge. Därför är det nödvändigt att känna till principerna för driften av en vanlig applikation. Detta diskuteras mycket detaljerat i min bok (kapitel 3 och 4). Här kommer vi bara att beröra de mest allmänna punkterna.

Det vanliga applikationsläget använder gränssnittet och formulären som användes i 8.0- och 8.1-plattformarna. Tidigare kallades det här läget ingenting, men nu heter det "vanligt applikationsläge", och formulären som används i det här läget kallas "vanliga formulär".

Låt oss ta en snabb titt på hur det här läget ser ut. Många kommer redan att vara bekanta med det, men vissa, särskilt de som inte har sett arbete under plattformarna 8.0 och 8.1, kommer att se det för första gången.

Efter att ha laddat programmet ser användaren ett gränssnitt med en meny överst (se fig. 1.2.2).

Fig 1.2.2 Gränssnittsvy av en vanlig applikation

Genom att klicka sig igenom menyalternativ kan användaren öppna olika formulär. Det rör sig främst om former av förteckningar över kataloger och dokument (se fig. 1.2.3), men det kan även förekomma rapporter, bearbetningar, kontoplaner m.m.

Fig.1.2.3. Dokumentlista formulär

Från listformuläret kan användaren öppna formuläret för ett dokument eller referensbok (se fig. 1.2.4).

Ris. 1.2.4. Dokumentformulär

Utvecklaren kan använda automatiskt genererade formulär, eller designa dem själv i .

Utvecklaren måste designa vanliga formulär med musen: placera de nödvändiga elementen på formuläret (knapp, fält, tabell), flytta dem till en lämplig plats och bestäm storleken (se fig. 1.2.5).

Figur 1.2.5. Designa konventionella former

Mycket ofta, när man utvecklade komplexa former, var det nödvändigt att ta hänsyn till interaktionen mellan formelement med varandra. För detta ändamål upprättades bindningar. Ibland blev de förvirrade, och formen fick ett inte helt vackert utseende. Vi kommer inte att gå in i mycket detaljer om denna mekanism och konsekvenserna av dess felaktiga användning, eftersom den i fallet med kontrollerade former har förlorat sin relevans.

Slutligen noterar jag att, till skillnad från en hanterad applikation, kan en vanlig applikation bara fungera under en "tjock klient". I stort sett är detta den huvudsakliga, mest grundläggande skillnaden mellan konventionella former och kontrollerade. Eftersom det hanterade applikationsläget utformades specifikt för att arbeta under en "tunn klient".

Hanterat applikationsläge

Så vad är egenheten och den grundläggande skillnaden mellan det hanterade applikationsläget och det vanliga? Den största skillnaden är användningen av ett hanterat kommandogränssnitt och hanterade formulär. Låt oss titta på var och en av dessa enheter separat. Vad är ett hanterat kommandogränssnitt? För att svara på denna fråga är det nödvändigt att gräva tillbaka i det förflutna.

Låt oss överväga i den enklaste formen hur konfigurationen utvecklades i en vanlig applikation. Först utformade vi affärslogiken: dokument, kataloger, rapporter, bearbetning och deras interaktion med varandra. Sedan satte vi upp roller, till exempel hade en användare med rollen "Leverantör" tillgång till dokumentet "Varumottagning", men inte till dokumentet "Varuutdata". Omvänt hade en användare med rollen "Säljare" tillgång till dokumentet "Varuutdata", men inte till dokumentet "Varukvitto". Nästa steg var att utveckla gränssnitt för varje typ av användare. De som praktiserade utveckling under en vanlig applikation minns att det fanns ett sådant konfigurationsobjekt som "Gränssnitt", där det var möjligt att konfigurera varje meny som menyn i figur 1.2.2. Och i vårt fall fick utvecklaren ta sig an att skapa två gränssnitt: ett för leverantören och det andra för säljaren. För om han hade utvecklat ett gemensamt gränssnitt där man kunde öppna både "Varumottagning"-dokumentet och "Varuutmatning"-dokumentet, så skulle det inte vara helt korrekt om leverantören, när han försöker öppna listan med "Varuutmatning" handlingar, fått ett meddelandesystem att han inte har rätt att göra det. För att undvika detta var det nödvändigt att göra två gränssnitt och specificera för varje användare vilket gränssnitt han skulle arbeta under.

I hanterat applikationsläge är allt mycket enklare. Vi kommer att studera det hanterade kommandogränssnittet mer i detalj i nästa del. I den här delen kommer vi att analysera det i de mest allmänna termerna. När det gäller taxigränssnittet ser det hanterade kommandogränssnittet ut så här:

Ris. 1.2.6. Hanterat kommandogränssnitt

När man utvecklar en hanterad applikation måste programmeraren ta en lite annan väg. Innan vi utvecklar affärslogik måste vi definiera de delsystem som våra objekt ska ingå i (i en vanlig applikation finns de också, men de är mer deklarativa till sin natur). Till exempel kommer dokumentet "Varumottagning" att ingå i delsystemet "Leverans" och dokumentet "Varukonsumtion" kommer att ingå i delsystemet "Försäljning". Samtidigt kan vissa objekt placeras i flera delsystem samtidigt: katalogen "Produkter" kommer att ingå i undersystemet "Försäljning", och i undersystemet "Supply" och i undersystemet "Marknadsföring". I det här fallet behöver utvecklaren inte skapa ett "gränssnitt"-objekt, systemet bygger automatiskt den erforderliga typen av gränssnitt baserat på inställningarna för användarrättigheter och funktionella alternativ.

Om någon användare har en roll som inte har rättigheter att se delsystemet, till exempel "Supply", kommer han helt enkelt inte att se detta menyalternativ när han startar 1C-applikationen. Dessutom kommer han inte att se ett dokument i menylistan som han inte åtminstone har rätt att se.

I figur 1.2.6 såg du användargränssnittet med fullständiga rättigheter, och till exempel kommer säljarens gränssnitt att se ut så här:

Ris. 1.2.7. Begränsat användargränssnitt

En annan skillnad från det vanliga gränssnittet är att användaren självständigt kan bestämma typen av sitt gränssnitt med hjälp av inställningar för navigering, åtgärder, sektioner etc. Till exempel, från gränssnittet i figur 1.2.7 kan vi ta bort "Warehouse"-artiklarna från funktioner för den aktuella sektionen (toppmenyn) och "Produkt". Du kommer att få den här looken:

Ris. 1.2.8. Användargränssnitt med reducerade funktioner för den aktuella sektionen

Vi kommer att titta på anpassning av användargränssnitt mer i detalj i de följande kapitlen i denna del, och vi kommer att studera sambandet mellan roller och gränssnittets utseende i nästa del av denna kurs. För nu, låt oss notera de viktigaste skillnaderna mellan det hanterade kommandogränssnittet och det vanliga.

• Utseendet på det hanterade kommandogränssnittet konfigureras automatiskt med hjälp av plattformsmekanismer, beroende på inställningarna för användarrättigheter och funktionsalternativ.
• Användaren kan självständigt anpassa utseendet på gränssnittet efter önskemål.

Låt oss nu titta på vad hanterade formulär är.

Lär dig programmering i 1C med hjälp av min bok "Programmering i 1C i 11 steg"

1. Inga komplicerade tekniska termer.
2. Över 700 sidor praktiskt material.
3. Varje uppgift åtföljs av en ritning (skärmdump).
4. En samling problem för läxor.
5. Boken är skriven i ett tydligt och enkelt språk – för en nybörjare.
6. Boken skickas med e-post i PDF-format. Kan öppnas på vilken enhet som helst!

Om den här lektionen hjälpte dig att lösa något problem, du gillade det eller tyckte att det var användbart, så kan du stödja mitt projekt genom att donera valfritt belopp:

Du kan betala manuellt:

Yandex.Money - 410012882996301
Web Money - R955262494655

Gå med i mina grupper.

Vi vet alla att 1C-företaget hade många olika versioner av 1C-plattformen, vi kommer nu att vara intresserade av en av de senaste versionerna när vi skriver denna artikel, dessa är versionerna 1C 8.2 och 1C 8.3. Om du har varit tvungen att arbeta i båda dessa versioner, då är du troligen märkte skillnader i gränssnitten för dessa versioner, för användare skiljer de sig endast i utseende. I grund och botten ett val vanlig eller hanterad applikation talar om för systemet vilka formulär som ska visas för att köras, regelbunden eller kontrollerad, samt vilken applikationsklient som kommer att användas som standard, tjock eller tunn. För mer detaljerad information om kunder, läs artikeln "Vad är tjocka och tunna klienter i 1C, såväl som deras skillnader."

Vanlig 1C-applikation (vanliga formulär, vanligt gränssnitt, version 1C 8.2)

I 1C 8.2 är det möjligt att endast arbeta med vanliga formulär, i vanligt ansökningsläge. Bilden nedan visar databasen i driftläget "vanlig 1C-applikation" (vanliga former).

Hanterad 1C-applikation (hanterade formulär, hanterat gränssnitt, version 1C 8.3)

På 1C 8.3-plattformen kan vi arbeta med både vanliga former (i kompatibilitetsläge) och hanterade. Dessutom hanterade formulär har två typer av display, detta är standard och taxi. Ett exempel på en 1C 8.3-konfiguration med standardhanterade formulär visas nedan, och efter det visas "Taxi"-gränssnittet.

Vad är skillnaden mellan en vanlig och hanterad 1C-applikation?

Som vi redan har fått reda på en vanlig applikation och en hanterad applikation är dessa typer av att starta ett 1C-program. Dessutom, beroende på värdet på 1C-starttypen ( vanlig eller hanterad applikation), kommer ett specifikt gränssnitt att laddas som standard ( vanliga eller hanterade formulär), därför finns det så många synonymer för detta koncept. Vi skulle vilja notera att skillnaderna i gränssnitten är ganska betydande. I princip är det alla skillnader som vanliga användare av 1C-programmet ser. När det gäller programmerare kräver det hanterade gränssnittet att man skriver modifierad kod, eftersom utvecklingen redan utförs i 1C 8.3, och inte i 1C 8.2, därav alla följderna. Koden måste också delas in i klient och server detta anges med hjälp av lämpliga direktiv i konfiguratorn.

Efter att ha provat guidade formulär i tre dagar blev jag kär i dem. Det finns ingen anledning att placera fält på formuläret med musen eller kämpa med bindningar. Allt är enkelt och kan göras med några få klick.

Jag tyckte till och med synd om att 1C inte helt övergav konventionella former på grund av att de används i skrivbordsläge. När allt kommer omkring skulle det vara möjligt att göra exakt pixelpositionering möjlig i UV, och vanliga former skulle dö ut med tiden. Och så måste du lägga din energi på att känna till den gamla funktionaliteten.

Och så, naturligtvis, är UV mycket snabbare än konventionella, eftersom... arbeta enligt ett schema i tre nivåer mellan klienten och servern.

Dessutom är funktionaliteten hos UV i sig mycket rikare och bredare än den för vanliga - inte överraskande, mycket tid har gått och många gränssnittsfynd har hittat in i dem.

Till exempel att visa en dynamisk tabell med grupperingar eller dra ut objektdetaljer direkt till en dynamisk lista. Eller till och med en radioknapp, inte i form av prickar, utan i form av vippknappar.

I praktiken är de inte så läskiga att använda som det verkade från början. Jag fick kläm på det snabbt. På min tid hade jag programmerat tillräckligt många vanliga moduler som bara fungerade på servern och stött på transformationer av föränderliga värden för att skicka dem till servern, så hanterade formulär var inom mitt grepp.

Modaliteter, eventivitet och gränssnittslås

Jag hörde att det i 8.3 fanns ett avslag på modala funktioner somFråga, Varning, OpenFormModal. Det var inte klart för mig varför detta gjordes.

Föreställ dig min förvåning när läraren i ett av exemplen fick formuläret att öppnas med alternativet "Blockera hela gränssnittet", d.v.s. huvudsakligen modal.

Jag var säker på att modaliteten hade övergetts.

Förståelsen kom inte direkt.

1C övergav inte modala fönster. Det finns nya funktioner för att visa en varning, ställa en fråga, öppna en modal filvalsdialog.

Nyansen är att efter att ha anropat dessa modala fönster fryser kontrollen inte, som tidigare, i väntan på att formuläret ska stänga, utan fortsätter. Formuläret ger upp en varning om att den har stängts, och du måste hantera denna varning.

De där. 1C-plattformen gjorde sig av med rudimentet med att frysa kodexekvering och bytte till helt händelsebaserad formulärhantering.

Naturligtvis har detta ingenting att göra med att webbläsare har svårt att visa modala fönster. Detta är en villfarelse och fördomar - glöm det som en ond dröm. Allt är logiskt. Faktum är att nu exekveringen är helt händelsebaserad och asynkron, vi lyckades bli av med synkron exekvering.

Minikonstruktörer dök upp i 1C - refactoring. Detta gör det lättare att skriva varningshanterare för asynkron drift utan att behöva skriva dem manuellt.

Konfigurationen har förmågan att inaktivera alla synkrona samtal (de kommer att orsaka ett fel), som ett resultat kommer den att vara helt asynkron och uppfylla de senaste kraven för att organisera händelsemodellen.

Nya gränssnittsfunktioner

Meny

Om hanterade formulär ser ut som en helt logisk och korrekt utvecklingsriktning, så förblir riktningen för utvecklingen av menysystemet oklart för mig.
Utan tvekan är en meny där endast en nivå visas, sedan måste du gå till nästa undernivå och så vidare tills du väljer önskad post redan moraliskt föråldrad, och den har ersatts av en menykarta, där flera menyalternativ utökas genast. Detta gjordes som standard redan före lanseringen av de nya menygränssnitten i 8.2.

Vid ett tillfälle, tillbaka i 8.1, gjorde jag ett menysystem i form av en hierarkisk katalog bifogad till vänster, där synligheten för varje objekt bestämdes av åtkomsträttigheterna för användaren för vilken menyn visades.

Som jag förstår det ansåg 1C att det var fel att applikationsobjektet Interface inte användes och beslutade att släppa ett nytt, avancerat alternativ till det.

Det blev på något sätt knepigt, enligt mig. Återigen, allt är knutet till roller konfigurerade av kryssrutor, som jag aldrig har gillat - det bästa rollsystemet skrivs på programkodnivå, bevis på detta är systemet med ytterligare användarrättigheter, vilket gör att du kan konfigurera flexibelt och utan onödiga problem åtkomsträttigheter i standardkonfigurationer.

I allmänhet har nya sätt att organisera menyer kommit enligt mig, de är inte särskilt framgångsrika, men det finns inget alternativ, och de används i standard.

Jag frågade läraren: "Jag förstår hanterade formulär, men varför var det nödvändigt att utveckla gränssnitt, varför kunde den klassiska menyn inte ändras något?"

Han svarade mig att 1C-systemet utvecklas i riktning mot att öka komforten och hastigheten i användarens arbete. Enligt min åsikt är sådana storslagna förändringar i menysystemet dock inte värda det.

Genomgångsbeställning

Förresten är ordningen för korsning viktig för användarnas produktiva arbete - många har redan automatiskt lärt sig en viss ordning för korsning av fält. Så övergångsordern övergavs i 8.2. Den följer strikt den ordning som elementen placeras i. Lyckligtvis är det möjligt att programmatiskt avlyssna exit från ett fält och överföra fokus till ett annat fält, annars skulle den angivna prestandan bli mycket dålig.

Arbetsyta och kapslade formulär

Det finns bara ett arbetsområde. Därför måste du trycka in formerna för nästan alla användare och bestämma deras synlighet genom rättigheter. Allt detta borde leda till kaos i stora konfigurationer.

Det skulle vara mycket lättare att skapa det med programkod eller använda mekanismen för kapslade formulär.

Det som aldrig implementerades i 8.2-8.3

Jag hann aldrig se de kapslade formerna. Tyvärr finns de inte där, även om de användes i antiken. Tillgång.

Det går inte att dra genom klippbordet. De där. du måste dra den med musen, du kan inte specificera den - jag drar den härifrån och placerar den här, utan att slita burken med musen, tyvärr. Även om, kanske, programvara från tredje part kan komma till undsättning här, eftersom... dra och släpp är en systemgrej i Windows.

Funktionella alternativ och elementsynlighet

På en gång RLS skapades för att endast visa användarna individuella tabellposter.

Ytterligare utveckling av synlighet inkluderade funktionella alternativ och inställningar för att visa fält efter roll. Sammantaget utgör detta en sorts mångsidig djurpark, det finns ingen övergripande harmoni och koherens.

Enligt min ödmjuka åsikt är synligheten av fält fortfarande lättare att hantera programmatiskt än deklarativt, genom att kryssa i rutor och skapa en komplex mekanism av funktionella alternativ.

En gång bevisade jag det RLS per ändring är sämre än mjukvaruskrivkontroll på objekt-/abonnemangsmodulnivå. På samma sätt misstänker jag att alla funktionella alternativ är sämre än den vanliga algoritmiska beskrivningen av att kontrollera synligheten av element - både i användarvänlighet och i mångsidigheten i tillvägagångssättet.

Användaren av konfiguratorn tvingas tänka mycket på hur man kontrollerar synlighet – genom roller eller genom funktionella alternativ. Efter att en gång ha skrivit en universell algoritm för att bestämma synligheten av fält, kunde han alltid använda den utan någon av dessa plattformskryckor.

Domen - funktionella alternativ och synlighet genom roller - är ineffektiva, men du måste känna till dem, eftersom de används i typiska konfigurationer.

Gränssnitt 8.2 och Taxi-gränssnitt

8.2-gränssnittet och taxigränssnittet är kompatibla, d.v.s. inga nya objekt dök upp. Konfigurationen kan fungera i antingen 8.2 eller Taxi, du kan tillåta användaren att växla mellan dessa gränssnitt.

Den största skillnaden är placeringen av huvudmenyobjekten. I 8.2 tog de upp mycket utrymme till vänster och överst, vilket lämnade lite utrymme för användarens arbetsområde i det nedre högra hörnet. I Taxi-gränssnittet döljs menyn automatiskt, kvar i form av en liten meny till vänster, som ett resultat är nästan hela skärmen ägnad åt arbetsområdet.

Det är inte klart varför det var nödvändigt att ta en så förvirrande väg, om det grundläggande menysystemet i 8.1 i slutändan var ännu mer ekonomiskt att använda upp skärmutrymmet?

Även i Taxi har principerna för att visa fönster ändrats som ett resultat av att formulärkoden för 8.2 är obekväm på vissa ställen. Men i denna riktning har jag ännu inte insett skillnaden, även om läraren försökte förklara de grundläggande principerna för Taxi. Jag ska försöka ta reda på det i praktiken, även om jag anser att alla dessa gränssnittsförbättringar är överflödiga och onödiga i praktiken för användare av affärsapplikationer.

Förresten, i 8.2 kan du inte ändra paletten, det är som ett visitkort på 1C-plattformen. På samma sätt vänjer menyorganisationssystemet i form av 8.2 eller Taxi användarna vid en viss standard. Men praxis visar att användaren lär sig om det nya menysystemet nästan omedelbart. Att förändra dina färdigheter i att arbeta med dokument och rapporter är mycket svårare.

Därför är allt detta brus och kontroverser kring menysystemet inte särskilt tydligt för mig - detta är inte huvudpunkten i 1C-plattformen, låt oss lämna det på plattformsarkitekternas och chefernas samvete som visar dem utvecklingsriktningen.

Outvecklad ideologi

Läraren noterade korrekt, även om det är förståeligt, att plattformsutvecklarna inte skapade nya enheter där de behövdes.

Exempelvis används delsystem både för att dela upp konfigurationsobjekt i block och för att organisera funktionella menyer (ett nytt alternativ till den vanliga applikationsmenyn). Även om det vore logiskt att skapa ett separat applikationsobjekt som heter "Funktionell meny".

Du måste också organisera tomma roller (gränssnittsroller), som endast behövs för att indikera vilka objekt som kommer att visas i en eller annan form. Även om det vore logiskt att utveckla applikationsobjektet "Interface" i denna riktning.

Tvivlar på effektivitet

Vissa 1C närmar sig användbarhet väcka tvivel.

Till exempel låg stor vikt vid kurserna att se till att den utskrivna formen av ett dokument visades i ett separat underformulär till dokumentet och att när dokumentet ändrades så rensades det. Det är inte mycket mening med detta ibland behöver du skriva ut flera exemplar - till exempel före och efter redigering. Att gå vilse i ett par dokument och flera tryckta formulär är omöjligt med övning, så att sprida energi i denna riktning verkade tveksamt för mig.

Också, till exempel, i plattformen är det omöjligt att skapa ett inmatningsfält i en dynamisk listcell om källan inte är bastabellen. Inte för att det är tekniskt svårt, utan av skäl användbarhet.

Möjlighet att spara inställningar

Formulärinställningar sparas direkt i databasen, inte i sessionen. De går inte förlorade vid en onormal uppsägning. Följaktligen har en ny mekanism för att arbeta med dessa inställningar dykt upp, där du kan spara dina data. AlternativSaveValue/RestoreValue.

Nu kan vid behov alla sparade inställningar sorteras bort programmatiskt, vilket innebär att de kan laddas upp till en annan användare, till en fil osv.

Andra frågor

Vad är hanterade formulär?

I hanterade former körs kod på klienten och på servern.

Med klient menar vi en svag maskin, det kan till och med vara en vanlig webbläsare.

Och servern är i en direkt och snabb anslutning till databasen.

Klienten kan inte arbeta med databasen, den kan utföra små matematiska operationer och manipulera delar av dess former. Om du behöver hämta något från databasen eller skicka data dit kontaktar klienten servern.

Det är precis så här hanterade formulär fungerar. Med rätt skicklighet är det inte svårt att ständigt komma åt servern.

En sådan organisation är mer effektiv än att ansluta till en server via fjärråtkomst dessutom är arbete möjligt direkt via en webbläsare, d.v.s. på vilken plattform som helst - Windows, Linux, Android , Mac OS .

Anmärkningar om 1C i bulk

Här är anteckningarna som jag skrev för mig själv, de innehåller värdefull kunskap:

1. I 1C-startfönstret är det inte längre informationsbaser som registreras, utan ingångspunkter. De där. en databas kan finnas flera gånger, men är registrerad för olika användare och olika arbetsverktyg - webbläsare, tunn/tjock klient, administratörsinloggning.
2. En nyckel har dykt upp för administratören som inaktiverar rollkontroll. Du kan bara logga in på Enterprise på detta sätt om du har administrativa rättigheter till konfigurationen.
3. Allmänna detaljer - blanda inte ihop dem med allmänna detaljer i 1C7 i 82 används de för att separera åtkomst i gränssnittet.
4. Jag använde ofta listans minsta höjd i formuläret för att bli av med formulärets onödiga rullningslist.
5. Du bör inte lagra bilder i katalogattribut, detta leder till att katalogens prestanda minskar. Du bör använda informationsregistret.
6. I serverprocedurer, när du skickar parametrar, måste du använda ett VÄRDE så att parametern inte skickas tillbaka till servern.
7. Nya egenskaperSidan Startar Med Och PageEndsOn, eventuellt andra, från plattform 8.3.6.
8. I 1s 8.2 dök ett privilegierat läge upp, dvs. Du kan inaktivera åtkomstkontroll på rollnivå i avsnitt av koden.
9. Element i listformen, värdetabellen och värdeträdet skiljer sig åt genom att listan på servern och klienten har samma representation, och speciella objekt skapas för tabellen och trädet och de måste konverteras på servern .
10. Det gläder mig att läraren tycker om att namnge objekt i singularis och namnge moduler med ett understreck så att dessa moduler kommer först i ordningen i sammanhanget ledtråd.

Om livet och runt 1C

Läraren sa:

1. Utveckling måste göras från gränssnittet.
   Min åsikt : Påståendet är tveksamt, eftersom Kunskap och erfarenhet av att använda plattformsarkitekturen gör att du omedelbart kan börja med applikationsobjekt och bygga gränssnittet senare.
2. Chefen lägger inte in data, tittar bara på rapporter. Och den hanterar inte datainmatning i 1C, utan telefonen och via sekreteraren. Därför behöver chefen bara en webbläsare och inmatningsfälten behövs bara för datafiltrering.
   Min åsikt : Ja, det verkar vara sant.
3. Kritiserade BSP (Standard Subsystem Library). I den meningen att det är omöjligt och mycket svårt att välja de nödvändiga modulerna från den.
   Min åsikt : Därför att Inte ens BSP kunde delas in i moduler, då kan UPP inte delas in i moduler UT, ZUP, BP, Produktion. Och här är det inte plattformens fel, utan fel metodik för att skriva standard - modularitet respekteras inte. Samma Navision har länge kunnat sälja bokföring till en kund, och sedan kan han köpa handel, produktion och löner vid behov, utan att skriva om koden och byta till ett nytt program.
4. De standardiserade har blivit mycket komplexa och svåra att ändra. Återigen, inte på grund av plattformens komplexitet, utan på grund av den felaktiga organisationen av de vanliga. I det här fallet går huvudprincipen förlorad - snabbt och ekonomiskt stöd och modifiering av standardkonfigurationer vid behov.
5. En variant av att lägga en beställning demonstrerades, när det i arbetsområdet finns en artikel till vänster och en lista över beställningar till höger. Du kan lägga kvantiteten mittemot artikeln, sedan dra den till listan över beställningar och en beställning bildas. Fördelen är att ordertabellen inte blockeras för att skapa en ny order.
   Min åsikt : Fördelen är långsökt - trots allt är användare mer vana vid att se den valda produkten i tabelldelen de kan spara denna beställning som ett utkast eller kopiera beställningen från mallen. I allmänhet uppfanns inte dokumenten förgäves.
6. Förklarade skillnaden mellan avsnitten "Huvud", "Viktigt", "Gå till", "Se också".
   Min åsikt : Personligen förstod jag det vagt, vilket betyder att de flesta aldrig kommer att förstå dessa nyanser inbäddade i plattformen användbarhet i en taxi. Därför kommer gränssnitten att se ut som tidigare, vilket både användare och 1C-programmerare redan är vana vid.
7. I en tabellfältcell på ett formulär vars källa är en anpassad fråga kan du inte ange data som du skulle göra i ett inmatningsfält. Detta görs i intresse användbarhet så att användaren fokuserar på att mata in data i ett separat fönster.
   Min åsikt : Jag gav ett exempel med input till tabelldelar där ett sådant fält finns, innebörden av förbudet är inte klart för mig.
8. Skilsmässor uppstår genom att jämföra en make med andra människor. Mindre jämförelser - starkare äktenskap.
9. Det är lättare att lära sig främmande språk när du studerar flera av dem samtidigt, du är lättad från din trångsynthet och fixering vid ett modersmål.
10. Det är omöjligt att studera främmande språk om du länkar ett främmande ord till ett ord på ditt modersmål, måste du länka det till en bild. Kedjan främmande ord - bild är kortare än kedjans främmande ord - infödd ord - bild. I det senare fallet kommer det inte att vara möjligt att tänka på ett främmande språk.

Slutsats

Jag uttrycker min tacksamhet till läraren.

Att delta i den här kursen befriade mig från fördomar angående hanterade formulär, jag förstod tydligt nyanserna av modalitet, skillnaderna mellan 8.2- och Taxi-gränssnitten.

Nu skrämmer inte kontrollerade former mig, utan, tvärtom, lockar mig att känna dem.

Jag hoppas att du, när du läser den här artikeln, också kommer att uppskatta hanterade formulär.

När en användare loggar in på 1C i Enterprise-läge för att börja arbeta är det första han ser programgränssnittet.

I programmering under ordet gränssnitt kan ha flera olika betydelser. Vi menar nu "användargränssnitt".

Användargränssnittet är alla fönster, menyer, knappar etc. som användaren arbetar med direkt i programmet.

Gränssnittsdesign är typsnitt, färg, bakgrundsbild och andra dekorativa element som används. Design påverkar inte sammansättningen av gränssnittet.

1C-plattformen implementerar två olika användargränssnittsmekanismer, som används i olika . Den tjocka 1C-klienten har sitt eget gränssnitt, den tunna klienten (och webbklienten) har sitt eget.

Låt oss prata idag om 1C-användargränssnittet.

Gränssnitt 1C

Det tjocka 1C-klientgränssnittet ser ut så här.

Det inkluderar:

• Huvudmeny
• Paneler.

Skrivbordet som används i vissa konfigurationer (bokföring, lön) är inte en del av 1C-gränssnittet, detta är bearbetning som görs separat av programmeraren och som öppnas i 1C helskärm vid tidpunkten för programmet.

I konfiguratorn är 1C-gränssnittet placerat i grenen General/Interfaces.

Programmeraren skapar ett 1C-gränssnitt med ett specifikt namn och, när du skapar en användare, anger standard 1C-gränssnittet för denna användare.

I 1C-gränssnittsegenskaperna finns en kryssruta "Switchable". Om 1C-gränssnittet inte är omkopplingsbart (kryssrutan är avmarkerad) kan alla användare se det, även om de har tilldelats ett annat 1C-gränssnitt. I det här fallet ser användaren båda gränssnitten sammanslagna till ett.

När du lägger till ett 1C-gränssnitt ser du en lista med paneler. Det finns alltid en standardpanel på programmets huvudmeny.

Om du lägger till fler paneler kommer de att visas som paneler (med knappar).

När du lägger till ett nytt 1C-gränssnitt från början, öppnas en konstruktor som hjälper dig att designa en meny genom att kontrollera de objekt som krävs.

När man redigerar en befintlig meny läggs objekt till individuellt, eftersom när konstruktorn anropas igen, återskapar den menyn från början.

När du lägger till ett toppmenyalternativ kan du i egenskaperna välja en av standardmenyerna - Arkiv, Operationer, Verktyg, Windows, Hjälp.

När du har lagt till en knapp eller menypost måste du välja den åtgärd som ska utföras. Åtgärder kan vara av två typer.

Om du vill att ett 1C-objekt ska öppnas som ett resultat av att klicka - en katalog, ett dokument eller en rapport - måste du klicka på knappen med tre punkter och välja önskat objekt, samt önskad form (möjlig åtgärd av objektet).

Om du vill att ett godtyckligt kommando ska utföras när du trycker, klicka på förstoringsglaset. Funktionen kan placeras i . Efter att ha valt en modul kommer en hanterarfunktion att skapas i den, och modulen kommer att vara öppen för redigering.

Hanterat kommandogränssnitt 1C

I den nya versionen av 1C 8.2 har nya typer av klienter dykt upp - .

1C tunna klientgränssnittet ser ut så här.

1C webbklientgränssnittet ser ut så här.

Helst är de samma, och som du kan se skiljer de sig mycket från 1C tjocka klientgränssnitt.

Den består nu inte bara av menyer och paneler, utan av:
1) Lista över redovisningssektioner
2) Navigering genom det valda avsnittet
3) Kommandon att köra i det aktuella avsnittet
4) Blanketter för att utföra den aktuella operationen.

För att skapa det hanterade 1C-klientgränssnittet används inte längre "gränssnitt" det är utformat på ett komplext sätt, baserat på många inställningar som gjorts i konfigurationen.

Faktum är att nu är 1C-gränssnittet detsamma för alla användare och samtidigt dynamiskt, och fungerar beroende på uppsättningen användarrättigheter och de kommandon som är tillgängliga för honom att utföra.
Vi kan också säga att det bildas på basen, därför kallas det också 1C-kommandogränssnittet.

1C delsystem

Grunden för det 1C-hanterade kommandogränssnittet är listan över redovisningssektioner. Till exempel - pengar och varor, två sektioner av redovisning.

I konfigurationen ansvarar objektet 1C Subsystems, som finns i grenen General/1C Subsystems, för redovisningssektionerna.

Efter att ha skapat ett 1C-undersystem, i de nödvändiga referensböckerna och dokumenten, på fliken 1C Subsystems i objektdesignern, kan du inkludera dem i detta 1C-undersystem. Det betyder att de tillhör denna del av redovisningen. Objekt kan ingå i flera 1C-delsystem.