Kohtuvaidlused

1c hallatavad vormid. Hallatud vormi elementide programmiline lisamine ja muutmine

Vormid 1C: Enterprise'is on ette nähtud andmebaasis sisalduva teabe kuvamiseks ja redigeerimiseks. Vormid võivad kuuluda kindlatesse konfiguratsiooniobjektidesse või eksisteerida neist eraldi ning neid kasutab kogu rakenduslahendus.

Näiteks kataloog Nomenklatuur võib olla mitu vormi, mida kasutatakse konkreetsetel eesmärkidel - kataloogielemendi redigeerimine, loendi kuvamine jne:

Koos sellega võivad esineda üldvormid, mis ei kuulu konkreetsete konfiguratsiooniobjektide hulka – üldvormid.

Põhivormid

Iga konfiguratsiooniobjekti saab kasutada teatud standardtoimingute tegemiseks. Näiteks võib mis tahes kataloogi puhul olla vaja kuvada selle elementide loend, kuvada kataloogi üksikud elemendid, kuvada kataloogi rühm, valida kataloogist elemente ja elementide rühmi. Iga dokumendi puhul on selliste toimingute loend palju väiksem: dokumentide loendi vaatamine, dokumentide loendist valimine ja eraldi dokumendi vaatamine.

Tagamaks selliste standardtoimingute sooritamist rakenduslahenduse objektide andmetega, on igaühe jaoks olemas põhivormide komplekt, mida vastavate toimingute tegemisel kasutatakse. Mis tahes sellele objektile alluvaid vorme saab määrata peamiseks. Näiteks kataloogis Nomenklatuur Võib esineda järgmised põhivormid:

Ja dokument Kaupade ja teenuste vastuvõtt põhivormide koostis on erinev:

Seega, kui kasutaja soovib vaadata kataloogide loendit Nomenklatuur või dokumentide loetelu Kaupade ja teenuste vastuvõtt, avab süsteem vastava vormi, mis on määratud nende objektide loendivormiks.

Automaatselt genereeritud vormid

Süsteemi 1C:Enterprise 8 oluline omadus on automaatselt genereeritud vormide mehhanism. See mehhanism vabastab arendaja vajadusest luua iga konfiguratsiooniobjekti jaoks kõik võimalikud vormid. Arendaja peab lihtsalt lisama uue konfiguratsiooniobjekti ja süsteem ise genereerib kasutaja töös õigetel hetkedel vajalikud vormid selles objektis sisalduva teabe kuvamiseks.

Seega on arendajal vaja luua oma vormid rakenduslahenduse objektidest ainult siis, kui need peavad erinema (erinev disain või konkreetne käitumine) süsteemi poolt automaatselt genereeritavatest vormidest.

Vormi sidumine andmetega

See, kas vorm kuulub konkreetsesse konfiguratsiooniobjekti, ei määra vormil kuvatavate andmete koostist. See, et vorm kuulub näiteks kataloogi Nomenklatuur, võimaldab määrata selle selle kataloogi üheks peamiseks vormiks, kuid ei määra mingil viisil, milliseid andmeid see vorm kuvab ja kuidas see käitub.

Vormi seostamiseks andmetega kasutatakse vormi detaile, mis näitavad vormi poolt kuvatavate andmete loendit. Kõik vormid ise käituvad samamoodi, olenemata sellest, milliseid andmeid nad kuvavad. Selle peamiseks atribuudiks saab aga määrata ühe vormiatribuudi (see on esile tõstetud paksus kirjas), sel juhul täiendatakse vormi standardset käitumist ja selle omadusi sõltuvalt sellest, mis tüüpi põhiatribuut on:

Näiteks kui dokument on määratud vormi põhiatribuudiks Kaupade ja teenuste vastuvõtt, siis küsib süsteem vormi sulgemisel selle dokumendi salvestamise ja postitamise kinnitust. Kui määrate vormi peamiseks nõudeks näiteks kataloogi Nomenklatuur, siis sellist kinnitustaotlust vormi sulgemisel ei kuvata.

Vormi struktuur

Vormide peamine omadus on see, et arendaja ei joonista neid üksikasjalikult, “piksli haaval”. Vorm konfiguratsioonis on vormi koostise loogiline kirjeldus. Ja elementide konkreetse paigutuse teostab süsteem vormi kuvamisel automaatselt.

Vormi kuvatavat (kasutajale nähtavat) osa kirjeldatakse vormielemente sisaldava puuna.

Elemendid võivad olla sisestusväljad, märkeruudud, raadionupud, nupud jne. Lisaks võib element olla rühm, mis sisaldab muid elemente. Gruppi saab kujutada paneelina raamiga, lehtedega (järjehoidjatega), lehe enda või käsupaneelina. Lisaks võib elemendiks olla tabel, mis sisaldab ka elemente (veerge). Elemendi struktuur kirjeldab, kuidas vorm välja näeb.

Kõik vormi funktsioonid on kirjeldatud detailide ja käskude kujul. Üksikasjad on andmed, millega vorm töötab, ja käsud on sooritatavad toimingud. Seega peab arendaja vormiredaktoris kaasama vormile vajalikud detailid ja käsud, looma neid kuvavad vormielemendid ja vajadusel elemendid rühmadesse paigutama.

Selle loogilise kirjelduse alusel genereerib süsteem kasutajale kuvamiseks automaatselt vormi välimuse. Süsteem võtab sel juhul arvesse kuvatavate andmete erinevaid omadusi (näiteks tüüp), et vormielemendid kasutajale võimalikult mugavalt järjestada.

Arendaja saab elementide paigutust erinevate seadistustega mõjutada. See võib määrata elementide järjekorra, näidata soovitud laiust ja kõrgust. See on aga vaid lisateave, mis aitab süsteemil vormi kuvada.

Vormides saab arendaja kasutada mitte ainult vormi enda käske, vaid ka globaalseid käske, mida kasutatakse kogu konfiguratsiooni käsuliideses. Lisaks on võimalik luua parameetrilisi käske, mis avavad muid vorme, võttes arvesse praeguse vormi spetsiifilisi andmeid. Näiteks võib see olla praegu arve vormil valitud lao saldode aruande kutsumine.

Viimases tunnis vaatasime seda tava(paksu)kliendi jaoks. Platvormi versioonis 1C 8.2. Nad kasutavad uusi ekraanivorme 1C 8.2. Neid nimetatakse hallatud vormideks 1C 8.2.

Hallatavad vormid 1C 8.2 on 1C tulevik. Need erinevad tavalistest 1C 8.2 vormidest selle poolest, et süsteem genereerib need automaatselt spetsiaalsete seadete alusel (“tavalised” vormid joonistab programmeerija lihtsalt soovi korral).

Hallatavate vormide 1C 8.2 arengu erinevused tavapärastest on märkimisväärsed. Seetõttu oleme täna kogunenud, et arutada eraldi hallatavate vormide 1C 8.2 loomist ja muutmist.

Hallatavad vormid 1C 8.2

Kui olete varem 1C konfiguratsioone arendanud, on 1C 8.2 hallatava vormi redaktori avamisel kohe hämmingus tõsiasi, et 1C 8.2 vormi pole hiirega üldse võimalik mõjutada.

Te ei saa muuta vormi 1C 8.2, te ei saa elementi liigutada, te ei saa isegi vaadata välja atribuute nagu varem – topeltklõpsates vormi 1C 8.2 väljal.

Nüüd ei ole 1C 8.2 vormi väljatöötamise aluseks vormi koordinaatidega väljade sidumine, vaid spetsiaalsed sätted. Süsteem genereerib nende sätete alusel automaatselt kontrollitud vormi 1C 8.2.

Seadistused koosnevad 1C 8.2 vormielementide loendist, mis asuvad redaktoris vasakus ülanurgas. Vormi 1C 8.2 elemendid hõlmavad järgmist:

  • Rekvisiidid
  • Käsud (uus kontseptsioon versioonis 1C 8.2, võivad välja näha nagu nupud või menüüelemendid)
  • Grupid (detailide ja käskude kombineerimiseks).

Vastavalt sellele ei ole nende elementide sätted väljade atribuutides, vaid nende seadistuselementide omadustes (paremklõpsu menüü, üksus Atribuudid).

Kuidas hallatavad vormid 1C 8.2 töötavad

Hallatud vormidega 1C 8.2 töötamine on kasutaja jaoks erinev. Neil on rohkem võimalusi, kuid need on ebatavalised neile, kes on 1C-ga pikka aega töötanud.

Esiteks on tavaliste elementide paigutus vormil 1C 8.2 erinev. Käsuriba on alati ülaosas.

Käsupaneeli vasak pool on kohandatav. Tavaliselt sisaldab see selliseid standardnuppe nagu Salvesta ja Postita.

Käsupaneeli paremal pool on vormi 1C Kõik toimingud uus standardmenüü. See menüü võimaldab hallata vormi 1C 8.2 vastavalt oma soovile, sarnaselt sellele, kuidas ACS aruandes võimaldavad sätted aruande välimust oluliselt muuta.

Suvalised menüüelemendid 1C Kõik toimingud

Sõltuvalt sellest, kas see vorm 1C 8.1 kuulub ühele või teisele, on menüü täidetud üksustega, mis võimaldavad teil seda objekti hallata. Näiteks kui see on kataloogiloendi vorm, siis on käsud nagu Loo või Redigeeri.

Üksus Kohanda menüüloendit 1C Kõik toimingud

Kui vormil 1C 8.2 on loend, on menüüs käsk Configure list and Display list.
Kui käsk Output list on teile juba tuttav - see võimaldab teil Excelis 1C-s mis tahes loendi salvestada / välja printida, siis on teine ​​käsk uus.

Nagu olete juba märganud, pole loendi käsupaneelil enam valikunuppe. Selle asemele ilmus nupp Otsi, mille töös (nagu ka kursori parajasti keelatud positsioneerimisel nimekirjas tippimisel) on mõningaid kaebusi.

Otsi nupu funktsionaalsus ei ole loomulikult võrreldav valikutega, kuid need pole kuhugi kadunud!
Need asuvad nüüd menüüüksuses Kohanda loendit. Valimist saab nüüd teha mis tahes välja järgi ning lisaks sellele saab teha sorteerimist ja tingimuslikku vormindamist samamoodi nagu ACS aruannetes.

Üksus Muuda menüü kuju 1C Kõik toimingud

Üksus Muuda vormi võimaldab teil sarnaselt muuta mitte ainult vormi 1C 8.2 loendit, vaid ka vormi 1C 8.2 ennast.

Kasutaja saab iseseisvalt lubada või keelata vormi 1C 8.2 väljade nähtavuse, laiuse ja kõrguse, avamisel vaikevälja aktiveerimise jne.

Hallatavate vormide 1C 8.2 ja tavavormide 1C kasutamine

Vaikimisi kasutatakse paksu (tavalise) 1C kliendi konfiguratsioonides tavalisi 1C vorme ja 1C õhukeste ja veebiklientide konfiguratsioonides hallatud vorme. Siiski saab mõlemat 1C vormi kasutada mis tahes konfiguratsioonis, sealhulgas samaaegselt.

Selleks tuleb sisestada konfiguratsiooni omadused (konfiguratsiooniakna ülemine element).

1C 8.2 konfiguratsiooniatribuutides on ilmunud kaks uut märkeruutu, mis võimaldavad lubada 1C vormide mittestandardset kasutamist.

Hallatavate vormide loomine 8.2

Uue 1C 8.2 vormi lisamine toimub samamoodi nagu varem – kasutades klaviatuuril nuppu Ins või nuppu Lisa. Olemasoleva sisestamiseks topeltklõpsake sellel hiirega.

Vaikimisi luuakse konfiguratsioonis installitud vorm (tavaline või hallatav) (vt konfiguratsiooni atribuutide atribuuti Peamine käivitusrežiim. Kui olete konfiguratsioonis lubanud kasutada mõlemat tüüpi vorme - vormikujundajas , mis kohe avaneb – saate valida tüübivormid.

Kujundaja palub teil valida vormi tüübi - elemendivorm, loendivorm. Siin saate lisada või eemaldada vormi käsupaneele. Enamasti jäetakse need sätted vaikimisi samaks.

Avaneb vaikimisi täidetud vorm - sellele on lisatud kõik olemasolevad 1C objekti üksikasjad. Konkreetse kohustuslike väljade loendi saate märgistada kujundaja teisel vahekaardil.

Vormiredaktor koosneb kolmest jaotisest.

  • Ülemises vasakus nurgas on vormielementide loend. See koosneb väljadest, käskudest ja rühmadest, mis võimaldavad elemente kombineerida. Käskude loendit saab eraldi vaadata vahekaardil Käsuliides.
  • Paremas ülanurgas on saadaolevate vormide ja objektide üksikasjade loend (avage atribuudi Object kõrval olev rist).
  • Allpool on saadud vormi eelvaade.

Saate lohistada saadaolevad üksikasjad vasakule ja sellest saab vormielement (väli vormil).

Kui teil on vaja lisada nupp või menüüelement, peate vahekaardi Käsud paremas servas looma uue käsu. See on vormimooduli funktsiooni ümbris. Lisaks sellele, et määrata, millist funktsiooni kutsutakse, saate määrata esituse - näiteks pildi, aga ka nähtavuse sõltuvuse funktsionaalsest valikust.

Ka käsklusi lohistatakse vasakule. Kui vanem on käsuriba, siis on see käsuriba nupp - muidu lihtsalt nupp.

Objekti/vormi atribuute ei saa mitte ainult lohistada vormielementide (väljade) loendisse, vaid ka lihtsalt lisada (nupp Lisa või Ins). Eelkõige saate luua uue vormiobjekti – Group.

Grupp võib olla käsupaneel (kursor peab asuma real Vorm). Seejärel lohistad sellesse käsud ja need muutuvad nuppudeks.

Rühm võib olla "tavaline". See on viis väljade rühmitamiseks nii vertikaalselt kui ka horisontaalselt. Grupi nime saab atribuutides eemaldada.

Rühm võib olla paneel (leht). Ülemine lisatud rühm on paneel ja seda tüüpi pesastatud rühmad on lehed. Väljad on juba lehtedele lohistatud.

Mittevajalikud vormielemendid eemaldatakse, kustutades loendist vormielemendid.
Välja asukoht vormil määratakse elementide loendis oleva järjekorra järgi (vertikaalne) või rühmade abil (horisontaalne). Laius ja kõrgus määratakse vormielemendi omadustes.

Vormielemendi atribuute on oluliselt laiendatud ja need sisaldavad palju kasulikku - nii välimuse juhtimist (nupud valimine ja tühjendamine) kui ka vaikeväärtuste kontrollimist.

Vormi enda omadused, sealhulgas selle mõõtmed, määratakse sama nimega vormi juurelemendis Vorm.

Sündmuste töötlejad (vastused kasutaja toimingutele) jagunevad nüüd kahte tüüpi. Vana – nagu varemgi, on need märgitud vormi ja väljade atribuutides (näiteks OnChange ja OnOpening vormi). Uutest on saanud käsud ja neid kasutatakse menüüelementide ja nuppude jaoks.

Ja andmeedastusobjekt koodi struktureerimiseks, kontrollitud kujul 1C 8.2 keskkonnas.

Sissejuhatus

Alustame 1C platvormi mõiste "hallatud vorm" ja sellega seotud mõistete lühikirjeldusega. Platvormi asjatundjad võivad selle jaotise vahele jätta.

2008. aastal sai kättesaadavaks 1C platvormi uus versioon: Enterprise 8.2 (edaspidi hallatud rakendus), mis muudab täielikult kogu liidesega töötamise kihti. See hõlmab käsuliidest, vorme ja aknasüsteemi. Samas ei muutu mitte ainult konfiguratsioonis kasutajaliidese arendamise mudel, vaid pakutakse välja ka uus arhitektuur kliendirakenduse ja serveri funktsionaalsuse eraldamiseks.
Hallatav rakendus toetab järgmist tüüpi kliente:

  • Paks klient (tavaline ja hallatud käivitusrežiim)
  • Õhuke klient
  • Veebi klient
Hallatav rakendus kasutab uuel tehnoloogial üles ehitatud vorme. Neid kutsutakse Hallatud vormid. Ülemineku hõlbustamiseks on toetatud ka varasemad vormid (nn Tavavormid), kuid nende funktsionaalsust ei arendata ja need on saadaval ainult paksu kliendi käivitamise režiimis.
Hallatavate vormide peamised erinevused arendaja jaoks:
  • Deklaratiivne, mitte "piksli haaval" struktuuri kirjeldus. Elementide konkreetse paigutuse teostab süsteem vormi kuvamisel automaatselt.
  • Vormi kõiki funktsioone kirjeldatakse kui üksikasjad Ja meeskonnad. Üksikasjad on andmed, millega vorm töötab, ja käsud on sooritatavad toimingud.
  • Vorm töötab nii serveris kui ka kliendis.
  • Kliendi kontekstis pole peaaegu kõik rakenduste tüübid saadaval ja vastavalt sellele ei saa infobaasi andmeid muuta.
  • Iga meetodi või vormimuutuja puhul tuleb see täpsustada koostamise käskkiri, määratledes täitmiskoha (klient või server) ja juurdepääsu vormi kontekstile.
Loetleme vormimeetodite koostamise juhised:
  • &OnClient
  • &Serveris
  • &Serveris ilma kontekstita
  • &OnClientOnServerIlma kontekstita
Illustreerime ülaltoodut. Ekraanipildil on näide hallatavast vormist ja selle moodulist arendusrežiimis. Otsige üles deklaratiivne kirjeldus, rekvisiidid, koostamise juhised jne.

Kõik edasised arutelud puudutavad illustratsiooni paremat külge, kuidas mooduli koodi üles ehitada ja millised põhimõtted võimaldavad teil rakendada tõhusat kliendi-serveri suhtlust.

Määratleme probleemi

1C platvormi uue versiooni aktiivsest kasutamisest on möödunud mitu aastat ja nii 1C kui ka tema paljud partnerid on välja andnud palju lahendusi (konfiguratsioone).
Kas selle aja jooksul on arendajatel kujunenud ühtne arusaam klient-serveri interaktsiooni põhimõtetest vormide loomisel ning kas lähenemine tarkvaramoodulite juurutamisel on muutunud uues arhitektuurilises reaalsuses?

Vaatame koodistruktuuri (vormimoodulit) sama standardkonfiguratsiooni mitmel kujul ja proovime leida mustreid.
Struktuuri all peame silmas koodilõike (enamasti on need kommentaariplokid), mille arendaja on eraldanud meetodite rühmitamiseks ja nende meetodite kompileerimisjuhised.
Näide 1:
Sündmuste töötlejate jaotis Meetod - kliendil Meetod - serveris Meetod - kliendil Teenindusprotseduuride ja -funktsioonide jaotis Lisasisendi juhtimisfunktsioonid
Näide 2:
Teenindusprotseduurid ja funktsioonid Maksedokumendid Väärtused Sündmuste töötlejad
Näide 3:
Teenindusprotseduurid serveris Teenindusprotseduurid kliendis Teenindusprotseduurid serveris ilma kontekstita Päise sündmuste töötlejad Käskude sündmuste töötlejad
Näide 4:
Üldotstarbelised protseduurid Vormi sündmuste käitlejad Kontaktteabe allsüsteemi protseduurid
Sisuliselt puudub koodi struktuur või on see pehmelt öeldes sarnane vormidega 8.1:

  • Mitteinformatiivsed sõnad “General, Service, Auxiliary”.
  • Arglikud katsed eraldada kliendi ja serveri meetodeid.
  • Meetodid on sageli rühmitatud liidese elementide järgi “Töö tabeliosaga Tooted, kontaktteave”.
  • Meetodite ja koodirühmade meelevaldne paigutus. Näiteks sündmuste käitlejad võivad olla ühel kujul ülaosas, teisel kujul allosas, kolmandas ei ole üldse esile tõstetud jne.
  • Ja ärgem unustagem, et see kõik on ühes konfiguratsioonis.
  • Jah, on konfiguratsioone, kus sõnad "General, Service, Auxiliary" on alati samades kohtades, kuid...
Miks on vaja koodistruktuuri?
  • Hoolduse lihtsustamine.
  • Õppimise lihtsustamine.
  • Üldiste/oluliste/edukate põhimõtete salvestamine.
  • ...teie valik
Miks 1C olemasolev arendusstandard ei aita?
Vaatame ITS-ketastel ja erinevates “Arendaja juhendites...” avaldatud põhimõtteid, mida soovitatakse hallatava vormi kirjutamisel.
  • Minimeerige serverikõnede arv.
  • Maksimaalne arvutite arv serveris.
  • Mittekontekstuaalsed serverikõned on kontekstipõhisest kiiremad.
  • Programm kliendi-serveri suhtlust silmas pidades.
  • ja nii edasi.
Need on loosungid, täiesti tõesed, aga kuidas neid ellu viia? Kuidas minimeerida kõnede arvu, mida tähendab programmeerimine klient-server režiimis?

Disainimustrid ehk põlvkonnatarkus

Kliendi-serveri suhtlust on erinevates tarkvaratehnoloogiates kasutatud aastakümneid. Vastus eelmises osas välja toodud küsimustele on ammu teada ja see on kokku võetud kahes põhiprintsiibis.
  • Kaugfassaad(edaspidi kaugjuurdepääsu liides)
  • Andmeedastusobjekt(edaspidi andmeedastusobjekt)
Sõna Martin Fowlerilt, tema kirjeldus nendest põhimõtetest:
  • Igal objektil, mis on potentsiaalselt ette nähtud kaugjuurdepääsuks, peab olema madala granulaarsusega liides, mis vähendab konkreetse protseduuri tegemiseks vajalike kõnede arvu. ... Selle asemel, et arvet ja kõiki selle kirjeid eraldi taotleda, tuleb kõik arvekirjed ühe päringuga läbi lugeda ja uuendada. See mõjutab kogu objekti struktuuri...Pidage meeles: kaugjuurdepääsu liides ei sisalda domeeniloogikat.
  • ...kui ma oleksin hooliv ema, ütleksin kindlasti oma lapsele: “Ära kunagi kirjuta andmeedastusobjekte!” Enamasti pole andmeedastusobjektid midagi muud kui ülespuhutud väli komplekt... Selle vastiku koletise väärtus seisneb ainuüksi võimaluses ühe kõnega edastada mitut teavet võrgu kaudu- tehnika, mis on hajutatud süsteemide jaoks väga oluline.
1C platvormi mallide näited
Rakenduse programmeerimisliides, mis on arendajale hallatava vormi väljatöötamisel saadaval, sisaldab nende põhimõtete kohta palju näiteid.
Näiteks OpenForm() meetod, tüüpiline "jäme" liides.
OpeningParameters = New Structure("Parameeter1, Parameeter2, Parameeter3", Väärtus1, Väärtus2, Väärtus3); Vorm = Avavorm(vorminimi, avamisparameetrid);
Võrrelge versioonis 8.1 vastu võetud stiiliga.
Vorm = GetForm(Vorminimi); Vorm.Parameeter1 = Väärtus1; Vorm.Parameeter2 = Väärtus2; Vorm.Open();

Hallatava vormi kontekstis on palju andmeedastusobjekte. Saate valida süsteemne Ja arendaja määratletud.
Süsteemsed mudelid modelleerivad kliendil rakendusobjekti ühe või mitme vormiandmeelemendi kujul. Neid on võimatu luua ilma vormi üksikasjadele viitamata.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureWithCollection
  • DataShapesTree
Süsteemi andmeedastusobjektide teisendamine rakendustüüpideks ja vastupidi toimub järgmiste meetoditega:
  • ValueInFormData()
  • FormDataValue()
  • CopyFormData()
  • ValueInFormAttributes()
  • FormAttributesValue()
Sageli kasutatakse olemasoleva lahenduse kohandamisel selgesõnalist teisendamist. Meetodid võivad eeldada (kasutada funktsioone) sisendparameetreid, näiteks ValueTable, mitte FormDataCollection, või meetod on määratletud rakenduse objekti kontekstis ja see on muutunud vormilt otsekutsumiseks kättesaamatuks.
Näide 1C v8.1:
// kliendil vormi FillUserCache(DepartmentLink) kontekstis
Näide 1C v8.2:
// serveris vormi kontekstis ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

Andmeedastusobjektid, mille struktuuri määrab arendaja, on väike alamhulk nii kliendis kui ka serveris saadaolevatest tüüpidest. Kõige sagedamini kasutatakse "jämestatud" liidese meetodite parameetrite ja tulemustena järgmist:

  • Primitiivsed tüübid (string, arv, tõeväärtus)
  • Struktuur
  • Kirjavahetus
  • Massiiv
  • Lingid rakendusobjektidele (ainulaadne identifikaator ja tekstiesitus)
Näide: meetod aktsepteerib oleku muutmise korralduste loendit ja tagastab kliendile vigade kirjelduse.
&OnServerWithoutContext Funktsioon ServerChangeOrderStatus(Orders, NewStatus) Errors = Uus vaste(); // [tellimus][vea kirjeldus] Iga tellimuse alusel tellimustest Cycle StartTransaction(); Proovi DocOb = Order.GetObject(); …. muud toimingud, mis on võimalikud mitte ainult tellimusega... Erand CancelTransaction(); Vead.Insert(Tellimus, Veakirjeldus()); EndAttempt; EndCycle; Tagastamise viga; EndFunction // ServerChangeOrderStatus()

Koodi struktureerimine

Peamised eesmärgid, mida hallatava vormi moodul peaks kajastama, ja lähenemisviisid lahendusele.
  • Kliendi ja serveri koodi selge eraldamine.Ärgem unustagem, et täitmise ajal on tegemist kahe vastastikku toimiva protsessiga, millest igaühel on märkimisväärselt erinev saadaolev funktsionaalsus.
  • Kaugjuurdepääsu liidese selge tuvastamine, milliseid serverimeetodeid saab kliendilt kutsuda ja milliseid mitte? Kaugliidese meetodite nimed algavad eesliitega "Server". See võimaldab koodi lugemise ajal kohe näha juhtimise üleandmist serverile ja lihtsustab kontekstuaalse abi kasutamist. Pange tähele, et ametlik soovitus (ITS) soovitab nimetada postfixidega meetodeid, näiteks ChangeOrderStatusOnServer(). Kordame aga, et kõiki serverimeetodeid ei saa kliendilt välja kutsuda ja seetõttu on olulisem loogiline ligipääsetavus, mitte kompileerimiskoht. Seetõttu märgime eesliitega "Server" ainult kliendile saadaolevad meetodid, kutsume näidismeetodit ServerChangeOrderStatus().
  • Loetavus. Maitse asi, tellimuse võtame vastu siis, kui moodul algab serveris vormi loomise protseduuride ja kaugjuurdepääsu meetoditega.
  • Hooldatavus. Uue koodi lisamiseks peab olema selge koht. Oluline punkt on see, et konfiguraatori poolt automaatselt loodud meetodimallid lisatakse mooduli lõppu. Kuna vormielementide sündmusekäsitlejad luuakse enamasti automaatselt, siis asub vastav plokk viimasena, et mitte iga töötlejat moodulis teise kohta lohistada.
Allpool on toodud mooduli põhistruktuur, mis rakendab loetletud eesmärke.
  • Graafiline valik – näitab selgelt peamist täitmise voogu.
  • Tekstivalik on malli kujunduse näide struktuuri kiireks lisamiseks uude vormimoodulisse.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Kuupäev=""/> // <Описание> // // /////////////////////////////////////////////////// ////////////////////////////////////////////////// MOODULI MUUTUJA //////////////////////////////////////////////////// ////////// // SERVERIS //******* SÜNDMUSED SERVERIS ******** &Serveri protseduuril serveris loomisel (tõrge, standardtöötlus) / /Sisestage töötleja sisu Protseduuri lõpp //******* KAUGJUURDE LIIDES ******* //******** ÄRILOOGIKA SERVERIS ******* /////////////////////////////////////////////////// /////// /////////////////////// KLIENDI JA SERVERI ÜHISED MEETODID //////////////// /////// //////////////////////////////////////////// ///// //////// // KLIENDIL //******* ÄRILOOGIKA KLIENDIL ****** //******** MEESKOND * ****** //******** KLIENDI SÜNDMUSED ******* /////////////////////////// ///// ////////////////////////////////////////////// // / / PÕHIPROGRAMMI OPERAATORID

Seotud küsimused
Kokkuvõtteks toome välja mitmed valdkonnad, millele on kasulik mõelda kliendi ja serveri interaktsiooni programmeerimisel.
  • Kaugjuurdepääsu liidese rakendamise valikud. Asünkroonsus, detailsus...
  • Vahemällu salvestamine. 1C tegi ebaõnnestunud arhitektuurse otsuse, võttes vahemällu kasutusele ainult tavaliste moodulite kutsumismeetodite tasemel ega pakkunud juhtimisvõimalusi (asjakohasuse aeg, lähtestamine nõudmisel).
  • Kaudsed serverikõned. Ärge unustage tehnoloogilisi funktsioone; paljud kliendi "kahjutud" toimingud provotseerivad platvormi serveriga ühendust võtma.

Klyuev V.V.

http://prof1c.kklab.ru

TÖÖ LÜLITITEGA

Palun võtke arvesse kõiki saiditeenuse kasutajaid - postitan materjalid algajate rubriiki!!!

8.2 Hallatavad vormid

Hallatavate vormide käitumist uurides seisavad programmeerijad või liidese arendajad silmitsi küsimusega, kus asuvad lülitid hallatavatel vormidel ja kuidas neid vormile lisada. See on väike asi, kuid sellistele pisiasjadele kulub ebameeldivalt palju aega, kuigi selle aja võiks kuluda pigem algoritmi väljatöötamisele ja optimeerimisele, mitte vormi kujundamisele.

Seega loome küsimuse mõistmiseks tühja konfiguratsiooni või valime mõne tüüpilise konfiguratsiooni.
Minge katalooge sisaldavasse rühma ja lisage katsetamiseks uus kataloog. Tahaksin märkida, et konfiguratsioonil peab olema peamine käivitusrežiim - hallatud rakendus.

Loome siis uue kataloogi ja lisame atribuudi "Property1" tüübiga "Boolean"

Nüüd läheme vahekaardile Vormid ja lisame uue vormi.

Niisiis, kontrollitav vorm on loodud, nüüd töötame vormiga ja otsime, kus lüliti asub.
Siin on meie vorm ja sellel näeme oma rekvisiite, kuid lipu kujul

Mida me siis valesti tegime?
Vaatame rekvisiitide omadustest, kas seal on lüliti juhtimistüübile.
Ja me näeme, et Switchi väli pole siin (Kus me valesti läksime?

Ilmselt sõltub vormi juhtelemendi tüüp andmetüübist, pöördume tagasi vormi atribuutide, nimelt detailide vahekaardi juurde ja muudame oma atribuudi atribuudid - nimelt selle tüübi "Boolean" tüübiks "Number". ”.

Nüüd läheme tagasi juhtelemendi atribuutide juurde ja kontrollime, kas selle atribuutide hulka on lisatud juhtelemendi vaade - - - Ja hurraa, näeme seal olevat vaadet - Switch Field.

Nüüd vaadake vormi, mida me näeme:

Näeme - 3 vaikeväärtust, 3 lülitit, kuid vajame neist kahte, minge uuesti atribuudi atribuutide juurde ja vaadake seal atribuute "Veerude arv"

2 jaoks - määrake veergude arv - 2.

See võib väsinud programmeerijat pisut peatada)), kuid nüüd teame seda nii tema kui ka meie!

8.2 Tavavormid.

Igav tavaliste vormide lülititega.
Selliseid hetki on ja neid juhtub), kui peate muutma mõnda valmisvormi, millel on juba mõned lülitid, ja peate sellele vormile lisama veel ühe lüliti. Siin tekib mingi tüütus, mis võtab palju aega ja mitte aega koodi programmeerimiseks - vaid aja raiskamine, et neid lüliteid kasutajale kuvada.

Nii et vaatame näidet. Kviitungite korrigeerimiseks 1C UPP-s on selline dokument olemas - see on kindlasti olemas. Kunagi oli meil vaja sinna lisada lülitid, et joonistuksid raamatupidamise jaoks veidi teistsugused kanded. Mis on probleem, tundub, et me peame, me peame, me teeme seda. Kuid sellel vormil on juba 2 raadionuppu.

Selline näeb välja vorm, kuhu peame lisama rohkem lüliteid


Vahekaardile Täpsemalt soovime paigutada veel kaks raadionuppu. Nii et esimene samm on julgelt lisada uus juhtelement meile vajalikku kohta ja sisestada.

Näib, et kõik on lihtne. Loome uue atribuudi tüübiga “Number” ja sisestame 2 lülitit, millest üks saab atribuudile andmeid kirjutada ja teine ​​mitte.

Lisa uus juhtelement - Switch, lisa tabelisse Lüliti2 koos lülitite arvu ja kirjeldusega, määra Switch1 grupis esimeseks ja vajuta OK. Asetage loodud juhtelemendid vormile. Värskendame andmebaasi konfiguratsiooni (F7) ja käivitame selle silumiseks.

Täites (uue dokumendi loomisel režiimis 1C:Enterprise) näeme, et hoolimata sellest, kui palju me proovime nuppu Switch2 klõpsata, ei juhtu midagi. Elemendid ei tööta nii nagu peaksid. Siin on üks nipp.
Naaske konfiguraatorisse. Vali menüükäsk Vorm -> Set traversal order... (oluline, et vorm oleks ekraanil avatud)


Selleks, et meie lülitid töötaksid, peate katkestama automaatse tellimuse ja nõustuma käsitsi tellimisega. Ja pange see vormi nii, et meie lülitid läheksid üksteise järel järjekorras.

OKEI. Värskendage konfiguratsiooni ja proovige seda käivitada.
Suurepärane. Kõik toimis.

Lisaks - video (ilma helita, nii et kõik on selge)


Selles artiklis tutvume hallatava vormiga töötamise peamiste aspektidega 1C 8.3. Mis on vorm ja milleks see on? Vorm on peamine objekt, mille kaudu kasutaja programmiga suhtleb. See tähendab, et vormi kasutades sisestab kasutaja infot programmi ning vormile kuvatakse ka kasutajale vajalik info.

Mis tahes vormi (hallatud või tavalise) arendaja põhiülesanne on pakkuda kasutajale programmiga suhtlemiseks mugavat mehhanismi.

1C platvormil on võimalus genereerida mis tahes vormis objekti, kuid tavaliselt konfigureerivad programmeerijad vormid ise rakenduslahenduste väljatöötamisel.

Eelkõige hallatavate vormidega ja üldiselt hallatud rakendusega töötamise küsimusi käsitletakse üksikasjalikult raamatus “1C: Takso arendamise alused. Hallatud rakenduste arendus 12 sammuga". See raamat on tõeliseks abiks neile, kes alles hakkavad hallatud rakenduste arendamisega tutvust tegema.

Raamat “1C: Takso arendamise alused” sobib suurepäraselt neile, kes on programmeerimisega juba alustanud ja kellel on selle teemaga teatud raskusi, ning neile, kes on programmeerimisega tegelenud pikka aega, kuid pole kunagi 1C hallatavate vormidega töötanud.

  1. Ilma keeruliste tehniliste terminiteta;
  2. Rohkem kui 600 lehekülge praktilist materjali;
  3. Iga näitega on kaasas joonis (ekraanipilt);

Sooduskood 15% allahindluseks - 48PVXHeYu

Mõnikord tundub, et programmeerimiskeele õppimine 1C-s on keeruline ja raske. Tegelikult on 1C programmeerimine lihtne. Minu raamatud aitavad teil kiiresti ja lihtsalt omandada programmeerimine 1C: ja "1C arendamise põhitõed: takso"

Õppige programmeerimist 1C-s minu raamatu "Programmeerimine 1C-s 11 sammuga" abil.

  1. Ei mingeid keerulisi tehnilisi termineid.
  2. Üle 700 lehekülje praktilist materjali.
  3. Iga ülesandega on kaasas joonis (ekraanipilt).
  4. Kodutööde ülesannete kogu.
  5. Raamat on kirjutatud selges ja lihtsas keeles – algajale.
  6. Raamat saadetakse e-postiga PDF-vormingus. Saab avada igas seadmes!


Kui see õppetund aitas teil mõnda probleemi lahendada, teile meeldis või leidsite, et see oli kasulik, saate minu projekti toetada, annetades mis tahes summa:

Saate maksta käsitsi:

Yandex.Money - 410012882996301
Veebiraha - R955262494655

Liituge minu rühmadega.