1c muutke vormielement nõutavaks. Hallatavate vormielementide programmiline lisamine ja muutmine

1C:Enterprise platvorm võimaldab programmiliselt lisada ja muuta hallatud vormi elemente. Vaatame, miks seda vaja võib minna.

Vormi programmiline muutmine võib olla vajalik mitmel juhul:

  • Tüüpiliste konfiguratsioonide lõpuleviimisel, et hõlbustada järgnevat värskendamisprotseduuri. Sel juhul muudetakse ainult vormimoodulit. Moodulid on palju lihtsam värskendada kui vormi.
  • Mõne üldalgoritmi rakendamisel. Näiteks allsüsteemis "Objektide detailide redigeerimise keeld" luuakse kõikidele allsüsteemiga ühendatud objektidele programmiliselt nupp, mis võimaldab detailide redigeerimise võimalust.
  • Mõne konkreetse algoritmi rakendamisel. Näiteks Nomenklatuuri otsingus luuakse väljad täiendavate üksikasjade redigeerimiseks.

Hallatud vormis saate programmiliselt lisada, muuta ja eemaldada:

  • rekvisiidid;
  • kohalikud käsud;
  • elemendid.

Kõik need toimingud on võimalikud ainult serveris.

Programmilisel ümberkujundamisel on piirangud:

  • Kustutada saab ainult programmiliselt lisatud atribuute/käske/elemente. Konfiguraatoris loodud objekte ei saa programmiliselt kustutada.
  • Atribuuti pole võimalik peamiseks määrata.

Vormi käskude muutmine

Objekti käskude koostise haldamiseks Hallatud vorm omama kollektsiooni Meeskonnad

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

    Kogus ()

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

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

Käskude kogu on saadaval nii kliendis kui ka serveris. Kogu muutmine (meetodid Lisa () ja Eemalda () ) on võimalik ainult serveris. Saate otsida ja hankida elementide arvu (meetodid Find () ja Quantity () ) nii kliendis kui ka serveris.

Vormikäskudega töötamise näitena loome uue ChangeHistory käsu pealkirjaga "Muudatuste ajalugu ...", mis kutsub välja töötleja DisplayHistory() . Loomine toimub vormi avamisel.

&Serveris
Menetlus OnCreateOnServer (tõrge, standardtöötlus)
Meeskond = Käsud. Lisama( "Muutuste ajalugu");
Meeskond . Tegevus = ;
Meeskond . Pealkiri = "Muudatuste ajalugu...";
Lõppprotseduur
&AtClient
Menetlus Connected_DisplayHistory(käsk)
// käsutoimingud
Lõppprotseduur

Käskude töötleja peab asuma vormis ja sellel peab olema kompileerimisdirektiiv &AtClient .

Vormi üksikasjade muutmine

Vormi atribuutide koostise lugemist teostab funktsioon Hankige üksikasju(< Путь >), mis tagastab FormAttributes tüüpi massiivi. Funktsiooni parameeter määrab tee emaatribuudini (stringina). Kui parameeter jäetakse välja või määratakse tühi string, tagastatakse ülataseme mandaat.

Detailide muutmine toimub meetodil Redigeeri Nõuded(<Lisatud üksikasjad>, <Eemaldatavad detailid>) objektiks Hallatud vorm. Valikud Lisatud üksikasjad ja Eemaldatavad detailid massiivid vorminõude tüüpi elementidega läbitakse.

Tähelepanu!

Detailide koostise muutmise protsess on üsna ressursimahukas. Tegelikult luuakse vorm uuesti. Sellega seoses tehakse tööd vormi üksikasjadega partiirežiimis.

Loome uue vormiatribuudi nimega Ostja:


AddedAttributes = Uus massiiv;
Lisatud üksikasjad. Lisa (uus vormi atribuut("Ostja", New TypeDescription ("DirectoryReference.Counterparties"), "Klient");

// Muutused atribuutide koostises
);

Vormi elementide muutmine

Objekti elementide koostise haldamiseks Hallatud vorm omama kollektsiooni Elemendid. Kogumisel on mitu meetodit:

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

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

    Kogus ()

    Leidma (< Имя >)

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

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

Elementide kollektsioon on saadaval nii kliendis kui ka serveris. Muuda kogu (sisesta meetodid () , Lisa () , Teisalda () ja Kustuta () ) on saadaval ainult serveris. Saate otsida ja hankida elementide arvu (meetodid Find () ja Quantity () ) nii kliendis kui ka serveris. Kollektsiooni elemendid võivad olla:

  • rühmavorm;
  • Tabelivormid;
  • FormField;
  • ButtonForms.

Saate programmiliselt määrata vormielementidele sündmuste töötlejad. Sel eesmärgil meetod SetAction(< ИмяСобытия>, < Действие >) .

Vaatame mõningaid levinumaid praktilisi näiteid käskude, atribuutide ja vormielementidega töötamise kohta.

Käsu ja sellega seotud nupu lisamine:

// Looge meeskond
Meeskond = Käsud. Lisama( "Muutuste ajalugu");
Meeskond . Tegevus = "Connected_DisplayHistory"; // Vorm peab sisaldama määratud nimega protseduuri
Meeskond . päis = "Muudatuste ajalugu...";
// Looge nupp ja seostage see käsuga
Element = esemed. Lisama( "Muutuste ajalugu", Type("Vorminupp" ));
Element.CommandName = "Muutuste ajalugu";

Atribuudi ja sellega seotud sisestusvälja lisamine:

// Lisatud üksikasjade kirjeldus
AddedAttributes = Uus massiiv;
Lisatud üksikasjad. Lisama(Uue vormi atribuut ("Ostja", uue tüübi kirjeldus ( "Viitelink. Osapooled"), "Klient" ));
// Atribuutide koostise muutmine
Redigeeri atribuute (lisatud atribuudid);
// Sisestusvälja loomine ja atribuudiga linkimine
Element = esemed. Add("Klient" , Type("Vormiväli" ));
Element . Vaade = ViewFormFields. Sisestusväli;
Element . PathToData= "Ostja" ;

Sündmuste töötleja määramine vormielemendile:

Kaubaostja. SetAction("Kui see muutub", "Plug-in_BuyerOnChange");

&AtClient
Menetlus Plugin_BuyerOnChange(Element )
// Sündmuste toimingud
Lõppprotseduur

Tähelepanu!

Protseduurid, mis installitakse meetodit kasutades koodist sündmuste töötlejatena SetAction(), on soovitatav kasutada eesliidet Connected_.

Tähelepanu!

Töötlemise saate alla laadida programmilise otsingu näidetega ning hallatava vormi üksikasjade, käskude ja elementide muutmise näidetega.

Andmeedastusobjekt koodi struktureerimiseks, hallatav vorm 1C 8.2 keskkonnas.

Sissejuhatus

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

2008. aastal sai kättesaadavaks platvormi 1C: Enterprise 8.2 uus versioon (edaspidi hallatud rakendus), mis muudab täielikult kogu liidesega töötamise kihti. See hõlmab käsuliidest ja vorme ning aknasüsteemi. See mitte ainult ei muuda konfiguratsioonis kasutajaliidese arendusmudelit, vaid pakub välja ka uue arhitektuuri 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 toetatakse ka vanemaid vorme (nn tavavorme), kuid nende funktsionaalsust ei arendata ja need on saadaval ainult rikkalikus kliendikäivitusrežiimis.
Hallatavate vormide peamised erinevused arendaja jaoks:
  • Deklaratiivne, mitte "pikslite järgi" struktuuri kirjeldus. Elementide konkreetse paigutuse teeb süsteem vormi kuvamisel automaatselt.
  • Vormi kõiki funktsioone kirjeldatakse vormis üksikasjad ja käske. Üksikasjad on andmed, millega vorm töötab, ja käsud on tehtud toimingud.
  • Vorm täidetakse nii serveris kui ka kliendis.
  • Kliendi kontekstis pole peaaegu kõik rakendustüübid saadaval ja vastavalt sellele on infobaasis olevate andmete muutmine võimatu.
  • Iga meetodi või vormimuutuja puhul tuleb see täpsustada koostamise käskkiri A, mis määrab, kas täitmise asukoht (klient või server) ja juurdepääs vormi kontekstile.
Siin on juhised vormimeetodite koostamiseks:
  • &AtClient
  • &Serveris
  • &OnServerWithoutContext
  • &Kliendi juures serveris, ilma kontekstita
Illustreerime ülaltoodut. Ekraanipildil on näide hallatavast vormist ja selle moodulist arendusrežiimis. Leia 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 arendajatel on selle aja jooksul vormide loomisel välja kujunenud ühine arusaam kliendi-serveri interaktsiooni põhimõtetest ja kas lähenemine programmimoodulite rakendamisele on uues arhitektuurilises reaalsuses muutunud?

Mõelge koodistruktuurile (vormimoodulile) sama tüüpilise konfiguratsiooni mitmel kujul ja proovige leida mustreid.
Struktuuri all peame silmas koodilõike (enamasti on need kommentaariplokid), mille arendaja on eraldanud meetodite rühmitamiseks ja nende meetodite koostamise juhised.
Näide 1:
Sündmuste töötleja jaotis Meetod - kliendil Meetod - serveris Meetod - kliendil Teenindusprotseduuride ja funktsioonide jaotis Sisendjuhtimise abifunktsioonid
Näide 2:
Teeninduse protseduurid ja funktsioonid Maksedokumendid Väärtesemed Sündmuste haldajad
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
Tegelikult on koodistruktuur puudu või pehmelt öeldes sarnane sellega, mis oli vormidel 8.1:

  • Mitteinformatiivsed sõnad "General, Service, Auxiliary".
  • Arglikud katsed eraldada kliendi ja serveri meetodeid.
  • Sageli on meetodid rühmitatud liidese elementide järgi "Töö tabeliosaga Tooted, Kontaktandmed".
  • Meetodite ja koodirühmade meelevaldne paigutus. Näiteks sündmuste käitlejad võivad ühel kujul olla ülaosas, teisel kujul allosas, kolmandas ei ole üldse esile tõstetud jne.
  • Ja ärgem unustagem, et see kõik on samas konfiguratsioonis.
  • Jah, on konfiguratsioone, milles sõnad "General, Service, Auxiliary" on alati samades kohtades, kuid ...
Miks on vaja koodistruktuuri?
  • Hoolduse lihtsustamine.
  • Õppimise lihtsustamine.
  • Üldiste/oluliste/edukate põhimõtete fikseerimine.
  • …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.
  • Kontekstivälised serverikõned on kiiremad kui kontekstikõned.
  • Programm, mis peab silmas kliendi ja serveri suhtlust.
  • jne.
Need on loosungid, mis on täiesti tõesed, kuid kuidas neid realiseerida? Kuidas kõnede arvu minimeerida, 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 juba ammu teada ja see on kokku võetud kahes põhiprintsiibis.
  • Kaugfassaad(edaspidi kaugjuurdepääsu liides)
  • Andmeedastusobjekt(edaspidi andmeedastusobjekt)
Sõna Martin Fowlerile, tema kirjeldus nendest põhimõtetest:
  • igal potentsiaalselt kaugjuurdepääsuks mõeldud objektil peab olema madala granulaarsusega liides, mis vähendab konkreetse protseduuri tegemiseks vajalike kõnede arvu. … Selle asemel, et arvet ja kõiki selle punkte eraldi küsida, on vaja ühe kõnega läbi lugeda ja uuendada kõik arve punktid. See mõjutab kogu objekti struktuuri...Pidage meeles: kaugjuurdepääsu liidest ei sisalda domeeniloogikat.
  • ... kui ma oleksin hooliv ema, siis kindlasti ütleksin oma lapsele: “Ära kunagi kirjuta andmeedastusobjekte!” Enamasti pole andmete migratsiooniobjektid midagi muud kui ülespuhutud välikomplekt… Selle vastiku koletise väärtus seisneb ainult võimaluses edastada ühe kõnega mitut teavet võrgu kaudu- tehnika, mis on hajutatud süsteemide jaoks väga oluline.
1C platvormi mallide näited
Arendajale hallatava vormi väljatöötamisel saadaolev API sisaldab nende põhimõtete kohta palju näiteid.
Näiteks OpenForm() meetod, tüüpiline "jäme" liides.
OpenParameters = New Structure("Parameeter1, Parameeter2, Parameeter3", Väärtus1, Väärtus2, Väärtus3); Vorm = OpenForm(Vorminimi, OpenParameters);
Võrrelge stiiliga v8.1.
Vorm = GetForm(Vorminimi); Vorm.Parameeter1 = Väärtus1; Vorm.Parameeter2 = Väärtus2; Vorm.Open();

Hallatava vormi kontekstis "Andmeedastusobjektide" komplekt. Saab eristada süsteemne ja arendaja määratletud.
Süsteemsed mudelid modelleerivad kliendil rakendusobjekti ühe või mitme vormiandmeelemendi kujul. Te ei saa neid luua väljaspool vormi üksikasjadega sidumist.

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureCollection
  • DataFormsTree
Andmeedastussüsteemi objektide teisendamine rakendustüüpideks ja vastupidi toimub järgmiste meetoditega:
  • ValueVDataForm()
  • FormDataToValue()
  • CopyFormData()
  • ValueVFormProps()
  • FormAttributeToValue()
Sageli kasutatakse olemasoleva lahenduse kohandamisel selgesõnalist teisendust. Meetodid võivad eeldada (funktsiooni) sisendparameetreid, nagu ValueTable, mitte FormDataCollection, või meetod määratleti rakenduse objekti kontekstis ja muutus vormilt otsekutsumiseks kättesaamatuks.
Näide 1C v8.1:
// kliendil vormi FillUsersCache(DepartmentReference) kontekstis
Näide 1C v8.2:
// serveris vormi ProcessingObject = FormAttributeToValue("Object") kontekstis; ProcessingObject.FillCacheUsers(osakonna viide); ValueVFormAttribute(ProcessingObject, "Object");

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

  • Primitiivsed tüübid (string, arv, tõeväärtus)
  • Struktuur
  • Vastavus
  • massiivi
  • 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 kohta tellimustest Loop StartTransaction(); Katse DocOb = Order.GetObject(); …. muud toimingud, võib-olla mitte ainult tellimusega... Erand CancelTransaction(); Errors.Insert(Order, DescriptionError()); Katse lõpp; 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 interakteeruva protsessiga, millest igaühes saadaolev funktsionaalsus on oluliselt erinev.
  • Kaugjuurdepääsu liidese selge valik, milliseid serverimeetodeid saab kliendilt välja kutsuda ja milliseid mitte? Kaugliidese meetodite nimed algavad eesliitega "Server". See võimaldab koodi lugemisel koheselt näha juhtimise üleminekut serverile ning lihtsustab kontekstipõhiste vihjete kasutamist. Pange tähele, et ametlik soovitus (ITS) soovitab nimetada postfixidega nimemeetodeid, näiteks ChangeOrderStatusOnServer(). Kordame aga, et kõiki serverimeetodeid ei saa kliendilt välja kutsuda ja seega on loogiline ligipääsetavus olulisem kui kompileerimiskoht. Seetõttu märgime prefiksiga “Server” ainult kliendile saadaolevad meetodid, näidismeetodi nimeks saab ServerChangeOrderStatus().
  • Loetavus. Maitse asi, tellimuse võtame vastu siis, kui moodul algab serveris vormi loomise protseduuride ja kaugjuurdepääsu meetoditega.
  • Hooldatavus. Uue koodi lisamise koht peab olema selgelt määratletud. Oluline punkt on see, et konfiguraatori poolt automaatselt loodud meetodi tünnid lisatakse mooduli lõppu. Kuna vormielementide sündmuste käsitlejad luuakse enamasti automaatselt, siis asetatakse vastav plokk viimaseks, et mitte tirida iga töötlejat moodulis teise kohta.
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 MUUTUJAD ///////////////// /////////////////////////////////////////////////// // ////////////// // SERVERIS //******* SÜNDMUSED SERVERIS ******** &Serveris Loomise protseduur Serveris( Tõrge, standardtöötlus) //Sisestage töötleja sisu EndProcedure //******* KAUGJUURDE LIIDES ******** //******** ÄRILOOGIKA SERVERIS **** *** //////////////////////////////////////////////// ///////////// ///////////////////// // ÜHISED KLIENDI JA SERVERI MEETODID //////////////////////////////////////////////////// //////////////// //////// // KLIENDIL //******* ÄRILOOGIKA KLIENDIL ******* //******* KÄSUD ******* //******* SÜNDMUSED KLIENDIL ****** /////////////// //////////////////////////////////////////////////// ///////////////// / / PÕHIPROGRAMMI OPERAATORID

Seotud küsimused
Kokkuvõtteks toome välja mõned valdkonnad, millele on kliendi-serveri suhtluse programmeerimisel kasulik mõelda.
  • Kaugjuurdepääsu liidese juurutamise võimalused. Asünkroonsus, detailsus...
  • vahemällu salvestamine. 1C tegi kahetsusväärse arhitektuurilise otsuse, võttes vahemällu kasutusele ainult tavaliste moodulite kutsumismeetodite tasemel ega pakkunud juhtimisvõimalusi (ajakohane aeg, lähtestamine nõudmisel).
  • Kaudsed serverikõned. Ärge unustage tehnoloogilisi funktsioone, paljud kliendi "kahjutud" toimingud provotseerivad platvormi serverile juurde pääsema.

1. Sisestusväli
2. Märkeruut
3. Lüliti

Sisestusväli

Reeglina on sisestusväli seotud objekti atribuudiga ja kajastab selle andmeid. See on võib-olla üks levinumaid elemente, sellel on väärtuse valimiseks mitu võimalust:

Loendist valimine (SelectFromListMode)

Valik mõnest muust vormist (nupp Vali)

Juhtnupud

Ülaltoodud näidete rakendamine ei nõua arendajalt märkimisväärseid jõupingutusi. näiteks loendirežiimi jaoks on vaja täita elemendi loend väärtustega, valida mõnelt muult vormilt, piisab lihtsalt juhtelemendi sidumisest sõnastiku andmetega. Kuid juhtnuppude jaoks peate iga nupu vajutamiseks kirjutama rohkem koodi, kuigi see pole suurepärane:

Protseduuri pv-nomenklatuuri valikumäärus (element, suund, standardtöötlus)
//Valige sisestusvälja andmed
// antud juhul viide nomenklatuurile
Taotlus = uus taotlus;
Request.Text=
"VALI
| Nomenklatuur. Viide kaubana
| ALT
| Kataloog Nomenklatuur AS Nomenklatuur
|TELLI
| Nomenklatuur.Kood";
TZNomenklatuur = Request.Execute().Upload();

//otsime sisestusväljal määratud kataloogi praegust elementi
CurrentElement = TKNomenklatuur.Leia(Element.väärtus);

Kui CurrentItem = Määratlemata Siis
// kui elementi ei leitud, määrake indeksi number
// väljaspool väärtuste tabelit, sest kõige esimene element
// väärtustabelis on indeks 0
CurrentIndex = -1;
Muidu
// kui element on leitud, hankige selle indeks
TekIndex = T3Nomenklatuur.Indeks(TekElement);
EndIf;

// arvutab uue indeksi sõltuvalt nupuvajutusest
// miinus muutuja ees Suund on selleks, et
// ülemisel noolel klõpsamine näitas ülaltoodud elementi
// ja seetõttu madalama indeksiga
NewIndex = CurrentIndex-Direction;

// hangib kataloogis olevate elementide arvu
// lahutada üks, sest kõik 8.1 kogud algavad 0-st
Artiklite arv = TK nomenklatuur Kogus () -1;

Kui NewIndex< 0 Или НовИндекс >Elementide arv Siis
// kui indeks on muutmisel väljaspool väärtuste tabelit
// st. selle arv on suurem kui suurim indeks või siis väiksem kui 0
// ära muuda väärtust ja teavita sellest kasutajat
alert("Olete jõudnud kataloogi limiidini");
Muidu
// määrake uus väärtus, "Toode" on väärtustabeli veeru nimi
Element.value = TKNomenclature.Get(NewIndex).Toode;
EndIf;

Lõppprotseduur

Märkeruut

Enamikus programmides kasutatakse märkeruutu kahe oleku kuvamiseks: märgitud, märkimata. 1s-is on märkeruudul kolm olekut, kolmandas olekus kuvatakse märkeruut - seatud ja varjutatud kujul. Need kolm olekut on saadaval ainult siis, kui lipuandmed on arv, kusjuures olekutel on järgmine tähendus:

Lüliti

Lülitit kasutatakse ühe väärtuse valimiseks väikese arvu võimalike (soovitavalt mitte rohkem kui viie) hulgast, samas kui väärtusi ei saa kombineerida, Näiteks: sobib inimese soo valimiseks. Teine näide: oletame, et ettevõte annab tootele ühe kolmest allahindlusest, samas kui allahindlused ei ole kumulatiivsed:

Sel juhul võib raadionuppude kasutamise mugavus seisneda selles, et igal neist võib olla mingi väärtus, mis on määratud atribuudis "Valitav väärtus". Ja siis saab "5% allahindlus" salvestada väärtuse 5 või 0,05.

Raadionuppude kasutamisel tuleb meeles pidada kolme olulist asja.

      Esimesel raadionupul peab olema atribuut "FirstInGroup" (selles näites on see raadionupp "5% allahindlus").

      Ühe rühmaga tähenduse järgi seotud lülitid peaksid möödaviigujärjestuse seadistuses käima järjest, ilma teiste vormielementide segamiseta. Läbimise järjekord määratakse menüüst "Vorm -> Läbimise tellimuse seaded", selle näite puhul näeb see välja järgmine:

  1. Valitud väärtuse tüübi määrab lüliti, millel on atribuut "FirstInGroup".

Liidese arendamine 1C-s koosneb kahest osast - menüü või töölaua arendamine ja 1C ekraanivormide arendamine. Aknaid, millega kasutaja 1C-s töötab, nimetatakse 1C-ekraanivormideks või lihtsalt 1C-vormideks.

Programmi kasutajad töötavad 1C vormidega. Lisaks näevad kasutajad ainult 1C vorme. Seetõttu on see programmis töötamise mugavuse seisukohalt üks olulisi elemente. Samal ajal võite 1C vormi arendamiseks kulutada rohkem aega kui kõige keerukama algoritmi programmeerimiseks.

Levinud viga, mida programmeerijad teevad, on püüda kõike oma maitse järgi joonistada. Muutke taust siniseks ja pealdised roheliseks. Või kollane mustal. Või kuidas talle mõnes teises lemmiksaates meeldib.

Kahjuks on see lähenemine ekslik, kuna kasutajad on harjunud töötama standardsete 1C vormidega, mida on konfiguratsioonis enamus. Enda ratta joonistamine ja selle Courieri pealdistega (nt "Autoriõigus Vasja Pupkin") märkimine on selgelt halvas vormis.

Nüüd läbime lühikese õppeprogrammi 1C vormide joonistamise kohta.

Mis on vormid 1C

Vorm 1C on kasutajale esitamise meetod. Tavaliselt on vorm rida välju, mis tuleb täita, ja nuppude (menüükäskude) komplekt, mida juhtida. Vorm 1C on saadaval enamiku 1C objektide jaoks.

1C paks klient kasutab "tavalisi" 1C vorme. See tähendab, et programmeerija lihtsalt joonistab hiirega vormi 1C, nagu seda tehakse Visual Studios ja muudes raamistikes.

1C õhuke klient ja 1C veebiklient kasutavad hallatud 1C vorme. See tähendab, et nende suurust, vormi 1C ja väljade asukohta neil ei saa hiirega muuta. Need genereeritakse seadete alusel automaatselt. 1C hallatavatest vormidest räägime järgmistes tundides.

Enamikul 1C tüüpiliste konfiguratsioonide vormidel on 1C-s oma tüüpiline esitus, mis on kasutajale tuttav.

Kuidas vormid 1C töötavad

Kasutaja töö loogika (järjekord) 1C-s on järgmine:

Seega töötab kasutaja alati 1C vormidega, alustades 1C loendivormist ja liikudes edasi 1C elemendivormiga. Kui programmeerija vorme ei joonistanud, genereerib 1C vormid vaikimisi. Neil puudub loomulikult ideaalne ilu ja täiuslikkus, kuid nad võimaldavad neil töötada.

Automaatselt genereeritud 1C loendi vorm sisaldab tavaliselt minimaalselt välju (vastavalt kood / nimi ja kuupäev / number). Automaatselt loodud elemendivorm sisaldab tavaliselt kõiki ülalt alla loetletud välju (rekvisiite).

Vormi 1C ülesanne on avada ja oodata kasutaja toiminguid. Tegevuses reageerige. Seega moodustavad sündmuste käitlejad 1C vormimooduli aluse. Need on funktsioonid, mida kutsutakse välja, kui kasutaja sooritab vormil 1C mõne toimingu.

Kus on vormid 1C

1C Enterprise režiimis, kui valite peaaegu iga 1C objekti (teateraamat, dokument, aruanne, töötlemine jne), näete selle objekti vormi.

Valige konfiguraatoris konfiguratsiooniaknas vajalik objekt, laiendage selle haru, et näha vormi 1C alamharu.

Teine võimalus on avada objektiredaktor (kaks korda hiirega või panna kursor ja Enter) ja minna vahekaardile Vorm 1C.

Siin on vormide 1C loend. Ühe lisatud 1C vormi saab lisada vaikevormina (1C loendi vorm, 1C elemendi vorm ja nii edasi).

1C vormide loomine

Uue 1C vormi lisamiseks peate klõpsama nuppu Lisa (klaviatuuril Ins). Olemasoleva sisestamiseks topeltklõpsake sellel hiirega.

Konstruktor palub teil valida vormi 1C tüübi - elemendi 1C vorm, loend. Siin saate lisada või eemaldada ka 1C vormi käsupaneele. Enamasti jäetakse need sätted vaikimisi samaks.

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

Mittevajalikud detailid saab eemaldada. Selleks valige üks või mitu välja ja vajutage Del.

Teiste atribuutide vabastatud ruumi teisaldamiseks valige need samal viisil ja lohistage neid hiirega.

Vormile 1C uute üksikasjade lisamiseks klõpsake nuppu Andmete paigutus paneelil (menüü Vorm / Andmete paigutus), märkige lisatavate elementide ruudud, samuti märkeruudud "Sisesta sildid" ja "Paiguta automaatselt". .

Teise võimalusena saate lihtsalt lisada juhtelemendi, klõpsates alloleval paneelil vastavat nuppu või valides menüüst Vormi/Insert Control. Topeltklõps hiire vasaku nupuga juhtelemendil (väljal) ja selle omadused avanevad. Atribuut "Andmed" sisaldab atribuudi nime. Siin saab seda muuta või määrata.

Juhtelemendi atribuudid sisaldavad ka märkeruutusid juhtelemendi välimuse reguleerimiseks. Märkeruutude abil saate lubada ja keelata valiku-, rippmenüü-, tühjendus-, nähtavuse- ja juurdepääsetavuse nuppe.

Peaaegu kõik dokumendivormid kasutavad järjehoidjaid. Järjehoidja lisatakse samamoodi nagu teine ​​juhtelement (vt ülalt), tuleb valida ainult paneeli juhtelement. Paneeli lehe lisamiseks paremklõpsake sellel ja valige Lisa leht. Muud juhtelemendid (väljad) paneelilehtedel lihtsalt lohistatakse.

Vormi 1C suuruse muutmiseks liigutage kursor lihtsalt vormi 1C servale, vajutage hiire vasakut nuppu ja lohistage lihtsalt vormi 1C serva.

Selleks, et vorm 1C töötaks - st. tegi midagi vastuseks kasutaja tegevusele - peate lisama käitleja funktsioonid. Sisestage suvalise elemendi omadused (klõpsates sellel hiire vasaku nupuga topeltklõpsuga) või vormi 1C enda (sarnaselt vormi päises). Atribuutide akna allservas on jaotis "Sündmused". Valige mugav sündmus (kõigi väljade jaoks on tavaliselt "OnChange", vormi jaoks "OnOpen") ja klõpsake suurendusklaasi nuppu. Selle sündmuste töötleja avaneb.

Nuppude puhul on lisamine sama. Kuid lisaks suvalistele töötlejatele saate selle vormi jaoks valida ühe standardsetest (viitevormi puhul on need ühed standardtoimingud, dokumendivormi puhul teised). Valige lihtsalt üks standardtoimingutest atribuudis "Toiming" või klõpsake ristil, kui soovite luua oma töötleja.

Tõenäoliselt ei suuda ükski algoritm kaitsta andmebaasi vigade eest, mis ilmnevad kasutajate andmete sisestamisel. Inimese tähelepanematusega seotud peamised probleemid on toodud järgmises loendis:

  • Vale objekti valik;
  • Vale kogus või kirjaviga nimes;
  • Kataloogide topeltelemendid, nende ebaunikaalsus või ümberpaigutamine;
  • Programmi korrektseks arvutamiseks ja tõrgeteta toimimiseks oluliste väljade täitmise ignoreerimine.

Viimase probleemi lahenduseks on 1C programmi kaheksanda versiooni puhul vormi üksikasjade täitmise kontrollimine.

Tavavormi täitmise kontroll

Vormi avamisel kasutaja poolt, kui käivitamisrežiimiks on "Tavaline rakendus", on elemendid, mis tuleb täita, esile tõstetud punase punktiirjoonega (joonis 1).

Nagu ülaltoodud näitest näha, on dokumendi "Kaubade ja teenuste müük" kohustuslikud väljad "Number" ja "Töövõtja". Sel juhul pole väli "Arv" redigeerimiseks saadaval. See tähendab, et kui dokument kirjutatakse infobaasi, täidetakse see automaatselt vastavalt antud organisatsioonile seatud nummerdamisreeglitele.

Kataloogielementide salvestamine või täitmata kohustuslikke välju sisaldavate dokumentide postitamine põhjustab erandi (joonis 2).

Riis. 2

Täpsemat teavet selle kohta, milline väli on täitmata, näete teenindusteate aknas.

Märk ise, mis teavitab välja kohustuslikust täitmisest, on seatud vormielemendi atribuutides. Selle jaoks:

  1. Ava vorm konfiguraatoris;
  2. Paremklõpsame vormi elemendil ja kutsume akna "Atribuudid";
  3. Vajalik on märkida "Kasutus" alammenüüs ruudud AutoMarkUnfilled ja AutoSelectUnfilled (joon. 3);

Otsene kontroll registreerib reeglina objekti moodulis.

Kataloogide ja mitteülekantavate dokumentide puhul on elemendi salvestamisel soovitav kutsuda välja täitmise kontrollimise protseduur. Mittetäielikult täidetud dokumendid, kui need on tehtud, saab salvestada andmebaasi ja on parem kutsuda kontrollimenetlus enne liikumiste teket, see tähendab läbiviimise ajal. Kohustuslikke välju sisaldavate töötluste ja aruannete kontroll on otstarbekas läbi viia otse nupuvajutuse töötluses.

Funktsiooni ValueFilled("Value") abil saate kontrollida, kas väljale edastatud väärtus erineb tühjast (vaikeväärtusest). Pidage aga meeles, et kui väli on liitandmetüübiga, loob selle funktsiooni täitmine erandi.

Valideerimine hallatavates vormides

Platvormi omadused klient-server versioonis jätavad täitekontrollile oma jälje.

Kõigepealt peate mõistma, milline protseduur mida järgib objekti sisestamisel selles töörežiimis.

Niisiis, pärast nupu "Salvesta", "OK", "Esita" vajutamist:

  1. Kutsutakse välja protseduur "Enne kirjutamist" kliendile;
  2. Andmed edastatakse serverisse ja toimuvad serveris vormimoodulis registreeritud sündmused (siin saab käivitada protseduuri ProcessingFillCheckOnServer);
  3. Vormi andmed edastatakse serveris asuvasse objektimoodulisse (on võimalus käivitada standardprotseduur ProcessingCheckFilling);
  4. Andmed moodulist tagastatakse serveri vormimoodulisse ja toimub protseduur BeforeWriteOnServer;
  5. Andmed tagastatakse objektimoodulisse ja toimub veel üks BeforeWrite protseduur;
  6. Objekt kirjutatakse otse andmebaasi.

Selle skeemi mis tahes punkti saate sisestada funktsiooni CheckFill(). Pärast detailide läbimist, mille atribuutide atribuudis “Täitke kontroll” on väärtus “Anna viga” (joonis 4), tagastab see funktsioon juhul, kui vähemalt üks neist pole täidetud, “False”.

Erinevused töötlejate HandleFillCheck() ja ProcessFillCheckOnServer() vahel

Arvestades asjaolu, et hallatava rakenduse liides võib sisaldada nii objektiatribuute kui ka otse vormiatribuute, on need kaks protseduuri eraldatud. Samal ajal on need töötlejatele edastatavate parameetrite poolest sarnased:

  1. Keeldumine (siin edastatakse pärast kontrolli selle tulemus);
  2. CheckedAttributes (andmetüüp on massiiv, kui seda ei täideta, siis kontrollitakse kõiki detaile, mille atribuudid on seatud "Kontrolli täitmist", vastasel juhul töödeldakse programmiliselt valitud detaile).

Protseduur ProcessingFillingCheckOnServer() võimaldab kontrollida atribuute, mis ei ole redigeeritava objektiga otseselt seotud. Iga programmeerija otsustab ise, mida ja millises mahus ta kontrollida soovib.

Protseduur ProcessingFillingCheck() kontrollib põhilisi üksikasju.