Men til venstre har vi et tomt felt. Delsystemkommandoer kan sendes ut til det:

for dette må du konfigurere kommandogrensesnittet til undersystemet:

For at kommandoene skal være synlige på venstre side av grensesnittet, må du merke av i boksene i handlingspanelet:

Som du kan se, er det i tillegg til kommandopanelet "Opprett" også "Rapporter" og "Tjeneste". Så langt er de ikke tilgjengelige hos oss, fordi vi ikke har laget noen rapporter. La oss lage dem og inkludere dem i prisundersystemet:

Etter det kan vi legge til disse rapportene og behandlingen i kommandogrensesnittet:

Etter det vil disse kommandoene vises i kommandopanelet:

For at behandlingskommandoene skal være tilgjengelige for å legge til i kommandopanelet, er det nødvendig at denne rapporten for det første er en del av dette undersystemet, og for det andre bør rettigheter tildeles den:

for det tredje må rapporten ha et oppsett:

For at tjenesten skal være tilgjengelig må behandlingen også ha rettigheter, for det andre må denne behandlingen også inngå i det tilsvarende delsystemet, og for det tredje må den ha en kommando.

Jeg publiserer det andre kapittelet i boken min "Grunnleggende utvikling i 1C: Taxi"

Kapittel 2: Vanlig og administrert 1C-applikasjon

I dette kapittelet skal vi se på hva en vanlig applikasjon og en administrert applikasjon er og hvordan de skiller seg fra hverandre, men før det, la oss se på konseptet med et "grensesnitt".

Hva er et "grensesnitt" egentlig? Faktisk er dette en felles grense mellom to samvirkende systemer (svært ofte er en person ett system). Ta en bil, for eksempel. Har den et grensesnitt? Sikkert. Men hva er den felles grensen mellom en bil og en person? For det første er det en arbeidsplass, dvs. direkte førersetet og kontroller (ratt, gasspedal, bremsepedal, etc.). For det andre er dette prinsippene for menneske-bil-interaksjon, som er et slags sett med regler. For eksempel, for å akselerere bilen, må du trykke på gasspedalen, for å bremse ned - bremsepedalen, for å svinge til høyre må du skru av rattet til høyre, etc. Takket være disse to enhetene kan en person kjøre bil. Ta bort én ting og du vil ikke kunne kjøre.

Det er det samme i programvareverdenen. Ett system er en person - en operatør, en bruker. Og det andre systemet er en applikasjon laget for å automatisere en viss type menneskelig aktivitet (vi vurderer anvendt programmering).

For eksempel må vi uavhengig opprettholde lagerregnskap: for å utføre ankomst av varer til lageret, avskrive dette produktet og overvåke saldoene. Hva vil være den felles grensen mellom applikasjonen, uansett hvordan og hvor den er skrevet, og brukeren? For det første er dette organene for å legge inn informasjon - ellers, hvordan kan du overføre til programmet at 5 stykker av et eller annet produkt har ankommet lageret. I vårt tilfelle er dette et datatastatur og en datamus. For det andre er det et system for interaksjon mellom en datamaskin og en person. For eksempel kan det være et kommandolinjegrensesnitt: du vil skrive inn forskjellige tekststrenger (kommandoer) ved hjelp av tastaturet og bruke dem til å utføre de nødvendige handlingene (registrere ankomsten av varer, forbruk av varer, etc.). Et slikt grensesnitt ser omtrent slik ut: se fig. 1.2.1.

Ris. 1.2.1 Kommandolinjeeksempel

Denne figuren viser kommandolinjen til Windows-operativsystemet, ved hjelp av det kan du gjøre nesten alle operasjonene du gjør i Utforsker: kopiere filer, slette filer, lage kataloger, etc.

Denne typen grensesnitt har lenge vært arkaisk, og har blitt erstattet av et grafisk brukergrensesnitt (eng. grafisk brukergrensesnitt GUI). I dette grensesnittet skjer interaksjonen mellom brukeren og applikasjonen gjennom ulike grafiske elementer tegnet på skjermen (knapper, ikoner, brytere osv.). I det grafiske grensesnittet har operatøren tilfeldig tilgang gjennom kontrollene til eventuelle grafiske elementer. I vårt tilfelle, når vi automatiserer lagerregnskap, kan interaksjonen se slik ut: operatøren klikker på "Ankomst"-knappen, produktvalgskjemaet åpnes, hvor operatøren velger ønsket produkt fra listen og legger inn antallet. Hvis du trenger å gjøre en utgift, klikker operatøren på "Forbruk"-knappen, valgskjemaet åpnes også, hvor operatøren også velger ønsket produkt og legger inn mengde. Når det er nødvendig å avstemme saldoene, klikker operatøren på "Saldo"-knappen, og programmet viser saldoene til varene på lageret. Dermed, ved hjelp av dette grafiske grensesnittet, kan du ganske vellykket holde styr på varer på lageret.

La oss avslutte med den teoretiske delen og gå direkte til emnet for dette kapittelet. Nemlig til typene applikasjonsgrensesnitt til 1C-programmet, som alle er grafiske brukergrensesnitt. 1C: Enterprise 8-programmet har to globale typer grafiske applikasjonsgrensesnitt. Disse er Normal Application Mode og Application Mode under Managed Forms (eller Managed Application).

Plattformer av utgave 8.0 og 8.1. fungerte bare under normal modus, høyere versjoner av plattformen (8.2, 8.3, etc.) kan fungere både i normal applikasjonsmodus og i administrert applikasjonsmodus.

Normal applikasjonsmodus

Nesten alle moderne konfigurasjoner kjører allerede i administrert modus, men det er fortsatt organisasjoner som bruker eldre konfigurasjoner som kjører i vanlig applikasjonsmodus. Derfor må du vite hvordan en typisk applikasjon fungerer. Dette er beskrevet i stor detalj i min bok (kapittel 3 og 4). Her skal vi bare berøre de mest generelle punktene.

Normal applikasjonsmodus bruker grensesnittet og skjemaene som ble brukt i plattformene 8.0 og 8.1. Tidligere ble ikke denne modusen navngitt på noen måte, men nå heter den "normal applikasjonsmodus", og skjemaene som brukes i denne modusen kalles "normale skjemaer".

La oss ta en rask titt på hvordan denne modusen ser ut. Den vil allerede være kjent for mange, men noen, spesielt de som ikke har fått arbeid under 8.0- og 8.1-plattformene, vil se den for første gang.

Etter å ha lastet programmet, ser brukeren et grensesnitt med en meny øverst (se fig. 1.2.2).

Fig 1.2.2 Grensesnittvisning av en vanlig applikasjon

Ved å navigere gjennom menyelementene kan brukeren åpne ulike skjemaer. I utgangspunktet er dette former for lister over oppslagsverk og dokumenter (se fig. 1.2.3), men det kan også være rapporter, behandling, kontoplaner mv.

Fig. 1.2.3. Form for listen over dokumenter

Fra listeskjemaet kan brukeren åpne skjemaet til et dokument eller oppslagsbok (se fig. 1.2.4).

Ris. 1.2.4. Dokumentskjema

Utvikleren kan bruke automatisk genererte skjemaer, eller selvstendig designe dem inn.

Utvikleren må konstruere de vanlige skjemaene med musen: plasser de nødvendige elementene (knapp, felt, tabell) på skjemaet, flytt dem til et passende sted og bestem størrelsen (se fig. 1.2.5).

Fig 1.2.5. Konstruere vanlige former

Svært ofte, når man utviklet komplekse former, var det nødvendig å ta hensyn til samspillet mellom formelementer med hverandre. For dette ble det etablert bindinger. Noen ganger ble de forvirret, og formen fikk et lite vakkert utseende. Vi vil ikke gå inn på mye av denne mekanismen og konsekvensene av dens misbruk, siden den i tilfelle av kontrollerte former har mistet sin relevans.

Til slutt bemerker jeg at, i motsetning til en administrert applikasjon, kan en vanlig applikasjon bare fungere under en "tykk klient". I det store og hele er dette den viktigste, mest kardinale forskjellen mellom konvensjonelle og kontrollerte former. Fordi den administrerte applikasjonsmodusen ble designet spesielt for å kjøre under en "tynn klient".

Administrert applikasjonsmodus

Så hva er det særegne og grunnleggende forskjellen mellom den administrerte applikasjonsmodusen og den vanlige? Hovedforskjellen er bruken av et administrert kommandogrensesnitt og administrerte skjemaer. La oss analysere hver av disse enhetene separat. Hva er et administrert kommandogrensesnitt? For å svare på dette spørsmålet er det nødvendig å gå dypt inn i fortiden igjen.

La oss vurdere i sin enkleste form hvordan utviklingen av konfigurasjonen ble utført i en vanlig applikasjon. Først utformet vi forretningslogikken: dokumenter, kataloger, rapporter, behandling og deres interaksjon med hverandre. Deretter satte vi opp rollene, for eksempel hadde en bruker med rollen «Leverandør» tilgang til dokumentet «Vareankomst», men ikke til dokumentet «Vareforbruk». Og omvendt hadde en bruker med rollen «Selger» tilgang til dokumentet «Forbruk av varer», men til dokumentet «Ankomst av varer» – nei. Neste steg var å utvikle grensesnitt for hver type bruker. De som har praktisert utvikling under en vanlig applikasjon husker at det var et slikt konfigurasjonsobjekt som "Grensesnitt", der det var mulig å konfigurere hver meny som menyen i figur 1.2.2. Og i vårt tilfelle måtte utvikleren jobbe hardt for å lage to grensesnitt: ett for leverandøren og det andre for selgeren. For hvis han utviklet ett felles grensesnitt der man kan åpne både dokumentet «Varemottak» og dokumentet «Vareforbruk», ville det ikke vært helt riktig om leverandøren, når han forsøker å åpne dokumentlisten «Vareforbruk», mottatt et meldingssystem om at han ikke har rett til det. For å unngå dette var det nødvendig å lage to grensesnitt og spesifisere for hver bruker hvilket grensesnitt han skulle jobbe under.

I administrert applikasjonsmodus er alt mye enklere. Vi vil utforske det administrerte kommandogrensesnittet mer detaljert i neste del. I denne delen vil vi bryte det ned i de mest generelle termene. Når det gjelder taxi-grensesnittet, ser det administrerte kommandogrensesnittet slik ut:

Ris. 1.2.6. Kontrollert kommandogrensesnitt

Når du utvikler en administrert applikasjon, må programmereren ta en litt annen vei. Før vi utvikler forretningslogikken, må vi definere subsystemene som skal inkludere objektene våre (i en vanlig applikasjon finnes de også, men de er mer av deklarativ karakter). For eksempel vil dokumentet "Ankomst av varer" inngå i delsystemet "Forsyning", og dokumentet "Forbruk av varer" vil inngå i delsystemet "Salg". Samtidig kan noen objekter lokaliseres i flere undersystemer samtidig: "Produkter"-katalogen vil bli inkludert i undersystemet "Salg", og i undersystemet "Innkjøp" og i undersystemet "Markedsføring". I dette tilfellet trenger ikke utvikleren å opprette et "grensesnitt"-objekt, systemet vil automatisk bygge ønsket grensesnitttype basert på innstillingene for brukerrettigheter og funksjonelle alternativer.

Hvis en bruker har en rolle som ikke har rettigheter til å se undersystemet, for eksempel "Supply", vil han ganske enkelt ikke se dette menyelementet når 1C-applikasjonen startes. Han vil heller ikke se et dokument i menylisten, som han i det minste ikke har rett til å se.

I figur 1.2.6 har du sett brukergrensesnittet med fulle rettigheter, og for eksempel vil selgers grensesnitt se slik ut:

Ris. 1.2.7. Begrenset brukergrensesnitt

En annen forskjell fra det vanlige grensesnittet er at brukeren uavhengig kan bestemme utseendet til grensesnittet sitt ved å bruke navigasjonsinnstillinger, handlinger, seksjoner osv. Fra grensesnittet i figur 1.2.7 kan vi for eksempel fjerne elementene "Warehouse" fra funksjonene av gjeldende seksjon (toppmeny) og "Produkt". Det vil se slik ut:

Ris. 1.2.8. Brukergrensesnitt med nedstrippede funksjoner for gjeldende seksjon

Vi vil diskutere mer detaljert tilpasningen av brukergrensesnittet i de neste kapitlene i denne delen, og vi vil studere forholdet mellom roller og utseendet til grensesnittet i neste del av dette kurset. I mellomtiden, la oss merke oss hovedforskjellene mellom det administrerte kommandogrensesnittet og det vanlige.

• Typen av det administrerte kommandogrensesnittet konfigureres automatisk ved hjelp av plattformmekanismene, avhengig av innstillingene for brukerrettigheter og funksjonelle alternativer.
• Brukeren kan selvstendig tilpasse utseendet til grensesnittet etter eget ønske.

La oss nå ta en titt på hva administrerte skjemaer er.

Lær programmering i 1C ved hjelp av boken min "Program i 1C i 11 trinn"

1. Ingen kompliserte faguttrykk.
2. Over 700 sider med praktisk materiale.
3. Hver oppgave er ledsaget av et bilde (skjermbilde).
4. Samling av oppgaver til lekser.
5. Boken er skrevet i et klart og enkelt språk – for en nybegynner.
6. Boken sendes på e-post i PDF-format. Kan åpnes på alle enheter!

Hvis denne leksjonen hjalp deg med å løse et problem, du likte det eller viste seg å være nyttig, kan du støtte prosjektet mitt ved å overføre et hvilket som helst beløp:

du kan betale manuelt:

Yandex.Money - 410012882996301
Web Money - R955262494655

Bli med i gruppene mine.

Vi vet alle at 1C hadde mange forskjellige versjoner av 1C-plattformen, vi vil nå være interessert i noen av de nyeste versjonene når dette skrives, dette er versjonene 1C 8.2 og 1C 8.3. Hvis du måtte jobbe i begge disse versjonene, vil du sannsynligvis la merke til forskjeller i grensesnittene til disse versjonene, for brukere skiller de seg bare ut eksternt. I hovedsak valget vanlig eller administrert applikasjon forteller systemet hvilke skjemaer som skal vises for å kjøre, konvensjonelle eller administrerte og hvilken klient av applikasjonen som vil bli brukt som standard, tykk eller tynn. For mer informasjon om klienter, se artikkelen "Hva er en tykk og tynn klient i 1C, samt deres forskjeller."

Normal 1C-applikasjon (normale former, normalt grensesnitt, versjon 1C 8.2)

I 1C 8.2 er bare arbeid mulig med vanlige skjemaer, i vanlig søknadsmodus... Bildet nedenfor viser basen i driftsmodusen "normal 1C-applikasjon" (normale former).

Administrert 1C-applikasjon (administrerte skjemaer, administrert grensesnitt, versjon 1C 8.3)

På 1C 8.3-plattformen kan vi jobbe både med vanlige skjemaer (i kompatibilitetsmodus) og med administrerte. Dessuten administrerte skjemaer har to visningstyper, standard og taxi... Et eksempel på 1C 8.3-konfigurasjon med standard administrerte skjemaer er vist nedenfor, etterfulgt av "Taxi"-grensesnittet.

Hva er forskjellen mellom en vanlig og administrert 1C-applikasjon?

Som vi allerede har funnet ut en vanlig applikasjon og en administrert applikasjon er disse typene for å starte et 1C-program... Dessuten, avhengig av verdien av 1C lanseringstypen ( vanlig eller administrert applikasjon), som standard vil et spesifikt grensesnitt bli lastet ( vanlige eller administrerte skjemaer), derfor er det så mange synonymer for dette konseptet. Vi vil merke oss at forskjellene i grensesnittene er ganske betydelige, det administrerte grensesnittet har blitt fullstendig redesignet. I prinsippet er dette alle forskjellene som vanlige brukere av 1C-programmet ser. Når det gjelder programmerere, krever det administrerte grensesnittet å skrive modifisert kode, fordi utviklingen allerede er i gang i 1C 8.3, og ikke i 1C 8.2, derav alle de påfølgende konsekvensene. Koden bør også deles inn i klient og server, dette indikeres ved hjelp av de aktuelle direktivene i konfiguratoren.

Etter å ha praktisert guidede former i tre dager, ble jeg forelsket i dem. Det er ikke nødvendig å plassere feltene på skjemaet med musen, for å lide med bindinger. Alt er enkelt og gjort med noen få klikk.

Jeg syntes til og med synd på at 1C ikke helt forlot de vanlige skjemaene på grunn av det faktum at de brukes i skrivebordsmodus. Tross alt ville det være mulig å muliggjøre presis pikselposisjonering i UV, og normale former ville dø ut over tid. Og så må du spre krefter på kunnskapen om den gamle funksjonaliteten.

Og så, selvfølgelig, UV er mye raskere enn vanlig, fordi arbeid i henhold til et trelagsskjema mellom klienten og serveren.

I tillegg er selve UV-funksjonaliteten mye rikere og bredere enn den til vanlige - det er ikke overraskende, mye tid har gått, og mange grensesnittfunn har kommet inn i dem.

For eksempel vise en dynamisk tabell med grupperinger, eller trekke objektattributter direkte inn i en dynamisk liste. Eller til og med en radioknapp, ikke i form av prikker, men i form av vippebrytere.

I praksis er de ikke så skumle å bruke som det virket i utgangspunktet, jeg ble fort vant til det. På en gang programmerte jeg nok vanlige moduler som bare fungerte på serveren, og møtte mutable verdikonverteringer for å sende dem til serveren, så administrerte skjemaer var tilgjengelige for min forståelse.

Modaliteter, hendelser og grensesnittlåser

Jeg hørte at i 8.3 var det et fall i modale funksjoner somSpørsmål, En advarsel, OpenFormModal... Det var ikke klart for meg hvorfor dette ble gjort.

Se for deg min overraskelse da læreren i et av eksemplene fikk skjemaet til å åpnes med parameteren "Lås hele grensesnittet", dvs. i hovedsak modal.

Jeg var sikker på at modaliteten ble forlatt.

Forståelsen kom ikke umiddelbart.

Modale vinduer har ikke blitt forlatt i 1C. Det er nye funksjoner for å vise en advarsel, stille et spørsmål, åpne en modal filvalgsdialog.

Nyansen er at etter å ha kalt disse modale vinduene, fryser ikke kontrollen, som før, og venter på at skjemaet lukkes, men fortsetter. Skjemaet gir et varsel om at det er lukket, og du må håndtere dette varselet.

De. 1C-plattformen ble kvitt rudimentet med frysing av kodeutførelse og byttet til fullstendig hendelsesdrevet skjemaadministrasjon.

Dette har selvfølgelig ingenting å gjøre med at nettlesere har problemer med å vise modaler. Dette er vrangforestillinger og fordommer – glem det som en vond drøm. Alt er logisk. Faktisk, nå er kjøringen fullstendig hendelsesdrevet og asynkron, vi klarte å kvitte oss med synkron kjøring.

Minikonstruktører dukket opp i 1C - refactoring. Dette gjør det lettere å skrive varslingsbehandlere for asynkron drift i stedet for å måtte skrive dem manuelt.

Konfigurasjonen har muligheten til å deaktivere alle synkrone anrop (de vil forårsake en feil), som et resultat vil den være helt asynkron og overholde de siste kravene for organisering av hendelsesmodellen.

Nye grensesnittfunksjoner

Meny

Hvis administrerte skjemaer ser ut til å være en helt logisk og riktig utviklingsretning, så har utviklingsretningen til menysystemet forblitt uforståelig for meg.
Utvilsomt, en meny der bare ett nivå vises, så må du gå til neste undernivå, og før du velger ønsket element, er det allerede moralsk utdatert, og det ble erstattet av et menykart, der flere menyelementer er distribuert med en gang. Dette ble gjort i standard før de nye menygrensesnittene ble utgitt i 8.2.

På et tidspunkt, tilbake på 8.1, laget jeg et menysystem i form av en hierarkisk katalog vedlagt til venstre, der synligheten til hvert element ble bestemt av tilgangsrettighetene til brukeren som menyen ble vist for.

Jeg forstår at 1C anså det som feil at Interface-applikasjonsobjektet ikke brukes, og bestemte meg for å gi ut et nytt, avansert alternativ til det.

Det viste seg på en eller annen måte vanskelig, etter min mening. Igjen, alt er knyttet til tilpassbare roller, som jeg aldri likte - det beste rollesystemet er skrevet på nivået av programkoden, beviset på dette er systemet med ekstra brukerrettigheter, som lar deg konfigurere fleksibelt og uten unødvendige problemer tilgangsrettigheter i typiske konfigurasjoner.

Generelt har det kommet nye måter å organisere menyen på, etter min mening er de ikke særlig vellykkede, men det er ikke noe alternativ, og de brukes i standard.

Jeg spurte læreren: "Jeg forstår administrerte skjemaer, men hvorfor trengte du å utvikle grensesnitt, hvorfor var det umulig å endre den klassiske menyen litt"?

Han svarte meg at 1C-systemet utvikler seg i retning av å øke komforten og hastigheten til brukeren. Etter min mening er imidlertid ikke en så stor endring i menysystemet verdt det.

Traverseringsrekkefølge

Forresten, rekkefølgen av kryssing er viktig for det produktive arbeidet til brukere - mange har allerede husket en viss rekkefølge av kryssende felt på maskinen. Så bare bypass-ordren i 8.2 ble forlatt. Den følger strengt rekkefølgen elementene er plassert i. Heldigvis er det mulighet for programmatisk å avskjære utgangen fra feltet og overføre fokus til et annet felt, ellers ville det vært veldig dårlig med den deklarerte ytelsen.

Arbeidsområde og nestede skjemaer

Det er bare ett arbeidsområde. Derfor må du presse skjemaer til nesten alle brukere inn i den og bestemme deres synlighet med rettigheter. Alt dette bør føre til kaos i store konfigurasjoner.

Det ville være mye enklere å lage det med programkode eller bruke mekanismen til nestede skjemaer.

Hva er fortsatt ikke implementert i 8.2-8.3

Jeg fikk aldri se de nestede formene. Akk, det er de ikke, selv om de ble brukt i oldtiden Adgang.

Det er ingen dra og slipp over utklippstavlen. De. du må dra den med musa, du kan ikke indikere - jeg drar den ut herfra og plasserer den her, uten å rive boksen med musa, dessverre. Selv om kanskje tredjepartsprogramvare kan komme til unnsetning her, tk. dra og slipp er en systemting i Windows.

Funksjonelle alternativer og elementsynlighet

På en gang RLS ble opprettet for å vise brukere kun individuelle tabellposter.

Videreutviklingen av synlighet var funksjonelle muligheter og innstillinger for visning av felt etter rolle. Alt dette til sammen utgjør en slags mangfoldig dyrehage, det er ingen generell harmoni og sammenheng.

Etter min ydmyke mening er synligheten av feltene fortsatt lettere å administrere programmatisk enn deklarativt, ved å sette kryss og lage en kompleks mekanisme med funksjonelle alternativer.

I god tid beviste jeg det RLS per endring er dårligere enn programmatisk skrivekontroll på objekt-/abonnementsmodulnivå. På samme måte mistenker jeg at ethvert funksjonelt alternativ er dårligere enn den vanlige algoritmiske beskrivelsen av kontroll av synligheten til elementer - både i brukervennlighet og i allsidigheten til tilnærmingen.

Brukeren av konfiguratoren må tenke mye på hvordan man kontrollerer synlighet – etter roller eller gjennom funksjonelle alternativer. Etter å ha skrevet en universell algoritme for å bestemme synligheten til felt en gang, kunne han alltid bruke den uten noen av disse plattformkrykkene.

Dommen – funksjonelle muligheter og synlighet gjennom roller – er ineffektive, men du må kjenne dem, fordi de brukes i typiske konfigurasjoner.

Grensesnitt 8.2 og Taxi-grensesnitt

Grensesnitt 8.2 og taxi-grensesnitt er kompatible, dvs. nye objekter dukket ikke opp. Konfigurasjonen kan fungere i enten 8.2 eller Taxi, det er mulig å la brukeren bytte mellom disse grensesnittene.

Hovedforskjellen er plasseringen av hovedmenyobjektene. I 8.2 tok de mye plass til venstre og øverst, som følge av at det ble lite plass igjen for brukeren til arbeidsområdet i nedre høyre hjørne. I Taxi-grensesnittet skjules menyen automatisk, forblir i form av en liten meny til venstre, som et resultat blir nesten hele skjermen tildelt arbeidsområdet.

Det er ikke klart hvorfor det var nødvendig å gå en så forvirrende vei, hvis det grunnleggende menysystemet i 8.1 til slutt var enda mer økonomisk i å bruke skjermplassen?

Prinsippene for å vise vinduer har også endret seg i Taxi, som et resultat er skjemakoden for 8.2 upraktisk noen steder. Men i denne retningen har jeg ennå ikke innsett forskjellen, selv om læreren prøvde å fortelle de grunnleggende prinsippene for Taxi. Jeg skal prøve å finne ut av det i praksis, selv om jeg anser alle disse grensesnittforbedringene som overflødige og unødvendige i praksis for brukere av forretningsapplikasjoner.

Forresten, i 8.2 kan du ikke endre paletten, det er som et visittkort på 1C-plattformen. Likeledes lærer menyorganiseringssystemet i form av 8.2 eller Taxi brukerne til en viss standard. Praksis viser imidlertid at brukeren blir omskolert til det nye menysystemet nesten umiddelbart. Det er mye vanskeligere å endre ferdighetene til å jobbe med dokumenter og rapporter.

Derfor er all denne støyen og kontroversen rundt menysystemet ikke veldig tydelig for meg - dette er ikke hovedpoenget i 1C-plattformen, la oss overlate det til samvittigheten til plattformarkitektene og lederne som angir utviklingsretningen til dem .

Uutviklet ideologi

Læreren bemerket riktig, selv om det er forståelig og så, at plattformutviklerne ikke opprettet nye enheter der det var nødvendig.

For eksempel brukes delsystemer både for å dele opp konfigurasjonsobjekter i blokker og for å organisere funksjonelle menyer (et nytt alternativ til den vanlige applikasjonsmenyen). Selv om det ville være logisk å lage et eget applikasjonsobjekt, som vil bli kalt "Funksjonsmeny".

Du må også organisere tomme roller (grensesnittroller), som kun trengs for å spesifisere hvilke objekter som skal vises i en eller annen form. Selv om det ville være logisk å utvikle "Interface"-applikasjonsobjektet i denne retningen.

Tviler på effektivitet

Noen 1C tilnærminger til brukervennlighet er i tvil.

For eksempel ble det i kursene lagt stor vekt på at den trykte formen på dokumentet skal vises i et eget underskjema til dokumentet og når dokumentet endres, slik at det ryddes. Det er ikke mye mening i dette, noen ganger må du skrive ut flere eksemplarer - for eksempel før og etter redigering. Det er umulig å bli forvirret i et par dokumenter og flere trykte skjemaer med øvelse, så spredningen av energi i denne retningen virket tvilsom for meg.

Også, for eksempel, i plattformen er det umulig å lage et inndatafelt i en celle i en dynamisk liste hvis kilden ikke er basistabellen. Ikke fordi det er teknisk vanskelig, men av grunner brukervennlighet.

Alternativer for å lagre innstillinger

Skjemainnstillinger lagres direkte til basen, og ikke i økten. De går ikke tapt ved unormal oppsigelse. Følgelig har en ny mekanisme for å jobbe med disse innstillingene dukket opp, hvor du også kan lagre dataene dine. AlternativLagreverdi/Gjenopprett verdi.

Nå kan alle de lagrede innstillingene, om nødvendig, registreres programmatisk, noe som betyr at de kan lastes ut til en annen bruker, til en fil, etc.

Andre spørsmål

Hva er administrerte skjemaer?

I administrerte skjemaer kjører kode på klienten og på serveren.

En klient betyr en svak maskin, det kan til og med være en vanlig nettleser.

Og serveren er i en direkte og rask forbindelse til databasen.

Klienten kan ikke jobbe med databasen, han kan utføre mindre matematiske operasjoner og manipulere elementene i skjemaene hans. Hvis du trenger å hente noe fra databasen eller sende data dit, henvender klienten seg til serveren.

Slik fungerer administrerte skjemaer. Med riktig ferdighet er konstant tilgang til serveren ikke vanskelig.

En slik organisasjon er mer effektiv enn å koble til en server via fjerntilgang; i tillegg er arbeid mulig direkte gjennom en nettleser, dvs. på hvilken som helst plattform - Windows, Linux, Android, Mac OS.

Merknader om 1C i bulk

Her er notatene jeg skrev for meg selv, de inneholder verdifull kunnskap:

1. I 1C-startvinduet registreres ikke infobaser, men inngangspunkter. De. én base kan være tilstede flere ganger, men den er registrert for ulike brukere og ulike arbeidsverktøy – nettleser, tynn/tykk klient, administratorinnlogging.
2. En nøkkel har dukket opp for administratoren som deaktiverer rollekontroll. Du kan kun logge på Enterprise på denne måten hvis administrative rettigheter til konfigurasjonen er tilgjengelige.
3. Vanlige detaljer - ikke forveksle dem med vanlige detaljer i 1C7, i 82 brukes de til å dele tilgang i grensesnittet.
4. Jeg brukte ofte minimumslistehøyden på skjemaet for å bli kvitt skjemaets unødvendige rullefelt.
5. Det er ikke nødvendig å lagre bilder i et oppslagsbokattributt, dette fører til et fall i ytelsen til oppslagsbøker, det er nødvendig å bruke informasjonsregisteret.
6. I serverprosedyrer, når du sender parametere, må du bruke VALUE slik at parameteren ikke sendes tilbake til serveren.
7. Nye funksjonerSiden starter med og Siden slutter med, muligens andre, fra plattform 8.3.6.
8. I 1c 8.2 dukket det opp en privilegert modus, dvs. du kan deaktivere tilgangskontroll på rollenivå i kodeseksjoner.
9. Elementene i skjemalisten, verditabellen og verditreet er forskjellige ved at listen på serveren og på klienten har samme presentasjon, og spesielle objekter opprettes for tabellen og treet og må transformeres på serveren.
10. Jeg var glad for at læreren liker å navngi objekter i entall og å navngi moduler med understrek, slik at disse modulene kommer først i rekkefølgen i det kontekstuelle hintet.

Om livet og rundt 1C

Læreren sa:

1. Utvikling må gjøres fra grensesnittet.
   Min mening : Utsagnet er tvilsomt, fordi kunnskap og erfaring med bruk av plattformarkitekturen gjør at du kan gå rett fra applikasjonsobjektene, og bygge grensesnittet senere.
2. Lederen legger ikke inn data, ser kun på rapportene. Og den administrerer ikke inndata til 1C, men telefonen og gjennom sekretæren. Derfor trenger lederen en nettleser, og inndatafeltene er kun nødvendige for å filtrere data.
   Min mening : Ja, det ser ut til å være sant.
3. Kritisert BSP (Library of Standard Subsystems). I den forstand at det er umulig og veldig vanskelig å velge de nødvendige modulene fra den.
   Min mening : Fordi selv BSP kunne ikke deles inn i moduler, da kan ikke UPP deles inn i UT, ZUP, BP, Produksjonsmoduler. Og her har ikke plattformen skylden, men feil metodikk for å skrive standard - modularitet respekteres ikke. Det samme Navision i lang tid har han mulighet til først å selge regnskapsavdelingen til kunden, og deretter kan han kjøpe ekstra handel, produksjon og lønn om nødvendig, uten å skrive om koden og bytte til et nytt program.
4. Typiske egenskaper har blitt svært komplekse og vanskelige å endre. Igjen, ikke på grunn av kompleksiteten til plattformen, men på grunn av feil organisering av standardene. Samtidig går hovedprinsippet tapt - raskt og økonomisk vedlikehold og revisjon av typiske konfigurasjoner, om nødvendig.
5. Muligheten for å legge inn en bestilling ble demonstrert når varen er til venstre i arbeidsområdet, og listen over bestillinger er til høyre. På motsatt side av varen kan du legge antallet, deretter dra det til listen over bestillinger og danne en bestilling. Fordel - bestillingstabellen er ikke blokkert for å opprette en ny bestilling.
   Min mening : Fordelen er konstruert - likevel er brukere mer vant til å se det valgte produktet i tabelldelen, du kan lagre denne bestillingen som et utkast eller kopiere bestillingen fra malen. Generelt ble ikke dokumentene oppfunnet forgjeves.
6. Forklarte forskjellen mellom seksjonene "Hoved", "Viktig", "Gå til", "Se også".
   Min mening : Personlig forsto jeg vagt, noe som betyr at de fleste aldri vil forstå disse nyansene som ligger i plattformen brukervennlighet i en taxi. Derfor vil grensesnittene se like ut som før, slik både brukere og programmerere i 1C allerede er vant til.
7. I en celle i et tabellfelt på et skjema, hvis kilde er en vilkårlig spørring, kan du ikke legge inn data, som i et inndatafelt. Dette er i interessen til brukervennlighetå fokusere brukeren på å legge inn data i et eget vindu.
   Min mening : Jeg ga et eksempel med innspill til tabelldelene, hvor et slikt felt er tilgjengelig, er betydningen av forbudet ikke klart for meg.
8. Skilsmisser oppstår ved å sammenligne en ektefelle med andre mennesker. Færre sammenligninger betyr sterkere ekteskap.
9. Det er lettere å lære fremmedspråk når du studerer flere av dem samtidig, trangsyntheten og besettelse med ett morsmål er fjernet.
10. Fremmedspråk kan ikke læres, hvis du binder et fremmedord til et ord på morsmålet ditt, må du binde til et bilde. Kjeden til et fremmedord - et bilde er kortere enn en kjede av et fremmedord - et innfødt ord - et bilde. I sistnevnte tilfelle vil det ikke fungere å tenke på et fremmedspråk.

Konklusjon

Jeg uttrykker min takknemlighet til læreren.

Å delta på dette kurset løste meg fra mine fordommer om administrerte skjemaer, jeg forsto tydelig nyansene i modalitet, forskjellene mellom 8.2- og Taxi-grensesnittene.

Nå skremmer ikke kontrollerte former meg, men tvert imot, tiltrekker meg til å kjenne dem.

Jeg håper du som leser denne artikkelen også vil sette pris på administrerte skjemaer.

Når en bruker går inn i 1C i Enterprise-modus for å begynne å jobbe, ser han først og fremst programgrensesnittet.

I programmering, under ordet grensesnitt kan bety flere forskjellige betydninger. Vi mener nå "brukergrensesnitt".

Brukergrensesnittet er alle vinduer, menyer, knapper og så videre, som brukeren jobber med direkte i programmet.

Grensesnittdesignen er den brukte fonten, fargen, bakgrunnsbildet og andre dekorative elementer. Designet påvirker ikke sammensetningen av grensesnittet.

I 1C-plattformen er to forskjellige brukergrensesnittmekanismer implementert, som brukes i forskjellige. Den tykke 1C-klienten har sitt eget grensesnitt, den tynne (og webklienten) har sitt eget.

La oss snakke i dag om 1C-brukergrensesnittet.

1C grensesnitt

Det tykke 1C-klientgrensesnittet ser slik ut.

Det inkluderer:

• Hovedmeny
• Paneler.

Skrivebordet som brukes i enkelte konfigurasjoner (regnskap, lønn) er ikke en del av 1C-grensesnittet, det er prosessering som gjøres av programmereren separat og som åpnes i 1C i fullskjerm når man går inn i programmet.

I konfiguratoren er 1C-grensesnittet plassert i grenen Generelt / Grensesnitt.

Programmereren oppretter et 1C-grensesnitt med et spesifikt navn og spesifiserer standard 1C-grensesnitt for denne brukeren når han oppretter en bruker.

I egenskapene til 1C-grensesnittet er det en avmerkingsboks "Switchable". Hvis 1C-grensesnittet ikke kan byttes (avmerkingsboksen er umerket), kan alle brukere se det, selv om et annet 1C-grensesnitt er tilordnet dem. I dette tilfellet ser brukeren begge grensesnittene slått sammen til ett.

Når du legger til et 1C-grensesnitt, ser du en liste over paneler. Det er alltid et panel som standard, det inneholder hovedmenyen til programmet.

Hvis du legger til flere paneler, vil de vises som paneler (med knapper).

Når du legger til et nytt 1C-grensesnitt fra bunnen av, åpnes en konstruktør som hjelper deg med å designe en meny ved å krysse av i boksene på de nødvendige objektene.

Når du redigerer en eksisterende meny, legges elementer til én etter én, siden når konstruktøren kalles opp igjen, gjenskaper den menyen fra bunnen av.

Når du legger til det øverste menyelementet, kan du i egenskapene velge en av de typiske menyene - Fil, Operasjoner, Tjeneste, Windows, Hjelp.

Etter å ha lagt til en knapp eller menyelement, må du velge handlingen som skal utføres. Handlingen kan være av to typer.

Hvis du vil at 1C-objektet skal åpnes som et resultat av å klikke - en katalog, dokument eller rapport - må du klikke på knappen med tre prikker og velge ønsket objekt, samt ønsket form (mulig handling av objektet).

Hvis du vil at en vilkårlig kommando skal utføres som et resultat av å trykke, trykk på forstørrelsesglasset. Funksjonen kan lokaliseres i. Etter å ha valgt en modul vil det opprettes en behandlerfunksjon i den, modulen åpnes for redigering.

Kontrollert kommandogrensesnitt 1C

I den nye versjonen av 1C 8.2 har nye typer klienter dukket opp -.

1C tynnklientgrensesnittet ser slik ut.

1C webklientgrensesnittet ser slik ut.

Ideelt sett er de de samme, og som du kan se er de veldig forskjellige fra 1C-grensesnittet til den tykke klienten.

Den består nå ikke bare av menyer og paneler, men av:
1) Liste over regnskapsseksjoner
2) Navigering i den valgte delen
3) Kommandoer for utførelse i gjeldende seksjon
4) Skjemaer for å utføre den aktuelle operasjonen.

"Grensesnitt" brukes ikke lenger for å danne 1C-grensesnittet til en administrert klient;

Faktum er at nå er 1C-grensesnittet det samme for alle brukere og samtidig dynamisk, avhengig av settet med brukerrettigheter og kommandoer som er tilgjengelige for ham å utføre.
Du kan også si at det er dannet på grunnlag, derfor kalles det også 1C-kommandogrensesnittet.

Delsystemer 1C

Grunnlaget for det 1C administrerte kommandogrensesnittet er listen over regnskapsseksjoner. For eksempel - penger og varer, to deler av regnskap.

I konfigurasjonen er 1C Subsystem-objektet ansvarlig for regnskapsseksjonene, som er plassert i General / 1C Subsystems-grenen.

Etter å ha opprettet et 1C-undersystem, i de nødvendige referansebøkene og dokumentene, på fanen 1C-undersystemer i objektkonstruktøren, kan du inkludere dem i dette 1C-undersystemet. Dette betyr at de tilhører denne delen av regnskapet. Objekter kan inkluderes i flere 1C-delsystemer.