Radiopogas, regulāra aplikācija, pārvaldītas formas. Slēdži, parasta lietojumprogramma, pārvaldītas veidlapas 1c problēmas ar pārvaldītajām formām
Platforma 1C:Enterprise ļauj programmatiski pievienot un modificēt pārvaldītās veidlapas elementus. Apskatīsim, kāpēc tas varētu būt vajadzīgs.
Veidlapas programmatiska modifikācija var būt nepieciešama vairākos gadījumos:
- Pabeidzot tipiskās konfigurācijas, lai atvieglotu turpmāko atjaunināšanas procedūru. Šajā gadījumā tiks mainīts tikai veidlapas modulis. Moduļus ir daudz vieglāk atjaunināt nekā veidlapu.
- Īstenojot dažus vispārīgus algoritmus. Piemēram, apakšsistēmā "Objektu detaļu rediģēšanas aizliegums" visiem ar apakšsistēmu saistītiem objektiem programmatiski tiek izveidota poga, lai iespējotu detaļu rediģēšanas iespēju.
- Īstenojot dažus konkrētus algoritmus. Piemēram, nomenklatūras uzziņu grāmatā tiek izveidoti lauki papildu informācijas rediģēšanai.
Pārvaldītā formā varat programmatiski pievienot, modificēt un noņemt:
- rekvizīti;
- vietējās komandas;
- elementi.
Visas šīs darbības ir iespējamas tikai serverī.
Programmatiskajai pārveidošanai ir ierobežojumi:
- Varat dzēst tikai programmatiski pievienotos atribūtus/komandas/elementus. Konfiguratorā izveidotos objektus nevar programmatiski izdzēst.
- Atribūtu nav iespējams piešķirt kā galveno.
Veidlapu komandu maiņa
Lai pārvaldītu objekta komandu sastāvu ManagedForm ir kolekcija Komandas
Pievienot (< ИмяКоманды >)
Daudzums ()
Atrast (< ИмяКоманды >)
Dzēst (< Команда >)
Komandu kolekcija ir pieejama gan klientā, gan serverī. Modificēt kolekciju (metodes Add () un Remove () ) ir iespējama tikai serverī. Jūs varat meklēt un iegūt elementu skaitu (metodes Find () un Quantity () ) gan klientā, gan serverī.
Kā piemēru darbam ar formu komandām izveidosim jaunu komandu ChangeHistory ar nosaukumu "Izmaiņu vēsture ...", kas izsauks apstrādātāju DisplayHistory() . Izveidošana tiek veikta, atverot veidlapu.
&Serverī
Procedūra OnCreateOnServer (kļūme, standarta apstrāde)
Komanda = Komandas. Pievienot( "Izmaiņu vēsture");
Komanda . Darbība = ;
Komanda . Nosaukums = "Izmaiņu vēsture...";
Procedūras beigas
&AtClient
Procedūra Connected_DisplayHistory(komanda)
// komandu darbības
Procedūras beigas
Komandu apstrādātājam ir jāatrodas veidlapā, un tam ir jābūt kompilācijas direktīvai &AtClient .
Veidlapas informācijas maiņa
Formas atribūtu sastāva nolasīšanu veic funkcija Iegūstiet informāciju(< Путь >), kas atgriež FormAttributes tipa masīvu. Funkcijas parametrs norāda ceļu uz vecāku atribūtu (kā virkni). Ja parametrs ir izlaists vai ir norādīta tukša virkne, tiek atgriezti augstākā līmeņa akreditācijas dati.
Detaļu maiņa tiek veikta ar metodi RediģētRekvizīti(<Pievienotas detaļas>, <Noņemamas detaļas>) objektu ManagedForm. Iespējas Pievienotas detaļas Un Noņemamas detaļas tiek nodoti masīvi ar Form Requisite tipa elementiem.
Uzmanību!
Detaļu kompozīcijas maiņas process ir diezgan resursietilpīgs. Faktiski veidlapa tiek veidota no jauna. Šajā sakarā darbs ar veidlapas detaļām tiek veikts pakešu režīmā.
Izveidosim jaunu formas atribūtu ar nosaukumu Pircējs:
AddedAttributes = jauns masīvs;
Pievienotas detaļas. Pievienot(jauns formas atribūts("Pircējs", New TypeDescription ("DirectoryReference.Counterparties"), "Klients");// Izmaiņas atribūtu sastāvā
);
Veidlapas elementu maiņa
Pārvaldīt objekta elementu kompozīciju ManagedForm ir kolekcija Elementi. Kolekcijai ir vairākas metodes:
Ievietot (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)
Pievienot (< Имя>, < ТипЭлемента>, < Родитель >)
Daudzums ()
Atrast (< Имя >)
Kustēties(< Элемент>, < Родитель>, < МестоРасположения >)
Dzēst (< Элемент >)
Elementu kolekcija ir pieejama gan klientā, gan serverī. Modificēt kolekciju (Ievietot metodes () , Pievienot () , Pārvietot () un Dzēst () ) ir pieejami tikai serverī. Jūs varat meklēt un iegūt elementu skaitu (metodes Find () un Quantity () ) gan klientā, gan serverī. Kolekcijas elementi var būt:
- Grupas forma;
- tabulas veidlapas;
- FormField;
- ButtonForms.
Veidlapas elementiem varat programmatiski piešķirt notikumu apdarinātājus. Šim nolūkam metode SetAction(< ИмяСобытия>, < Действие >) .
Apskatīsim dažus no visbiežāk sastopamajiem praktiskiem piemēriem darbam ar komandām, atribūtiem un veidlapas elementiem.
Komandas un ar to saistītās pogas pievienošana:
// Izveidojiet komandu
Komanda = Komandas. Pievienot( "Izmaiņu vēsture");
Komanda . Darbība = "Connected_DisplayHistory"; // Veidlapā jābūt procedūrai ar norādīto nosaukumu
Komanda . galvene = "Izmaiņu vēsture...";
// Izveidojiet pogu un saistiet to ar komandu
Elements = Preces. Pievienot( "Izmaiņu vēsture", Tips("FormButton" ));
Element.CommandName = "Izmaiņu vēsture";
Atribūta un ar to saistītā ievades lauka pievienošana:
// Pievienotās informācijas apraksts
AddedAttributes = jauns masīvs;
Pievienotas detaļas. Pievienot(Jauns veidlapas atribūts ("Pircējs", jauna veida apraksts ( "Atsauces saite. Darījuma partneri"), "Klients" ));
// Atribūtu sastāva maiņa
RediģētAtribūtus (Pievienoti atribūti);
// Ievades lauka izveide un saistīšana ar atribūtu
Elements = Preces. Add("Klients" , Tips("FormField" ));
Elements . Skats = ViewFormFields. Ieejas lauks;
Elements . PathToData= "Pircējs" ;
Notikumu apstrādātāja piešķiršana veidlapas elementam:
Preču pircējs. SetAction("Kad tas mainās", "Plug-in_BuyerOnChange");
&AtClient
Procedūra Plugin_BuyerOnChange(Elements )
// Pasākumu darbības
Procedūras beigas
Uzmanību!
Procedūras, kas tiek instalētas kā notikumu apstrādātāji no koda, izmantojot metodi SetAction(), ieteicams izmantot prefiksu Connected_.
Uzmanību!
Varat lejupielādēt apstrādi ar programmatiskās meklēšanas piemēriem un pārvaldītās formas detaļu, komandu un elementu maiņu.
Un datu pārsūtīšanas objekts koda strukturēšanai, pārvaldīta forma 1C 8.2 vidē.
Ievads
Sāksim ar īsu jēdziena "pārvaldītā forma" un saistīto 1C platformas jēdzienu aprakstu. Platformas eksperti var izlaist šo sadaļu.2008. gadā kļuva pieejama jauna platformas 1C: Enterprise 8.2 versija (turpmāk tekstā — pārvaldītā lietojumprogramma), kas pilnībā maina visu saskarnes darba līmeni. Tas ietver komandu saskarni un veidlapas, kā arī logu sistēmu. Tas ne tikai maina lietotāja interfeisa izstrādes modeli konfigurācijā, bet arī piedāvā jaunu arhitektūru funkcionalitātes nodalīšanai starp klienta lietojumprogrammu un serveri.
Pārvaldīta lietojumprogramma atbalsta šādus klientu veidus:
- Biezais klients (parastais un pārvaldītais palaišanas režīms)
- Plāns klients
- Web klients
Galvenās pārvaldīto formu atšķirības izstrādātājam:
- Deklaratīva, nevis "pēc pikseļu" struktūras apraksts. Konkrēto elementu izvietojumu sistēma veic automātiski, kad tiek parādīta forma.
- Visa veidlapas funkcionalitāte ir aprakstīta veidlapā detaļas Un komandas. Detaļas ir dati, ar kuriem darbojas veidlapa, un komandas ir veiktās darbības.
- Veidlapa tiek izpildīta gan serverī, gan klientā.
- Klienta kontekstā gandrīz visi aplikāciju veidi nav pieejami, un attiecīgi nav iespējams mainīt datus infobāzē.
- Katrai metodei vai formas mainīgajam tas ir jānorāda apkopošanas direktīva A, kas norāda, vai izpildes vieta (klients vai serveris) un piekļuve veidlapas kontekstam.
- &AtClient
- &Serverī
- &OnServerWithoutContext
- &Pie klientaServeraBezkonteksta
Visas turpmākās diskusijas būs par ilustrācijas labo pusi, par to, kā strukturēt moduļa kodu un kādi principi ļaus īstenot efektīvu klienta-servera mijiedarbību.
Definēsim problēmu
Ir pagājuši vairāki gadi, kopš aktīvi tiek izmantota jaunā 1C platformas versija, un gan 1C, gan tā daudzie partneri ir izlaiduši daudzus risinājumus (konfigurācijas).Vai šajā laikā izstrādātājiem ir izveidojusies vienota izpratne par klienta un servera mijiedarbības principiem, veidojot formas, un vai jaunajās arhitektūras realitātēs ir mainījusies pieeja programmu moduļu ieviešanai?
Apsveriet koda struktūru (veidlapas moduli) vairākās vienas tipiskās konfigurācijas formās un mēģiniet atrast modeļus.
Saskaņā ar struktūru mēs domājam koda sadaļas (visbiežāk tie ir komentāru bloki), ko izstrādātājs ir piešķīris grupēšanas metodēm un direktīvām šo metožu kompilēšanai.
1. piemērs:
Notikumu apstrādātāja sadaļa Metode - uz klienta Metode - uz servera Metode - uz klienta Servisa procedūru un funkciju sadaļa Ievades kontroles palīgfunkcijas
2. piemērs:
Servisa procedūras un funkcijas Maksājumu dokumenti Vērtslietas Pasākumu rīkotāji
3. piemērs:
Servisa procedūras serverī Servisa procedūras klientam Servisa procedūras serverī bez konteksta Galvenes notikumu apstrādātāji komandu notikumu apstrādātāji
4. piemērs:
Vispārējas nozīmes procedūras Veidlapu notikumu apstrādātāji "Kontaktinformācijas" apakšsistēmas procedūras
Faktiski trūkst koda struktūras, vai, maigi izsakoties, tā ir līdzīga tai, kas bija 8.1 formās:
- Neinformatīvi vārdi "General, Service, Auxiliary."
- Kautrīgi mēģinājumi nodalīt klienta un servera metodes.
- Bieži metodes tiek grupētas pēc saskarnes elementiem "Darbs ar tabulas daļu Produkti, Kontaktinformācija".
- Patvaļīga metožu un kodu grupu sakārtošana. Piemēram, notikumu apdarinātāji var būt augšā vienā formā, apakšā citā, bet trešajā vispār nav izcelti un tā tālāk.
- Un neaizmirsīsim, ka tas viss ir vienā konfigurācijā.
- Jā, ir konfigurācijas, kurās vārdi “General, Service, Auxiliary” vienmēr atrodas tajās pašās vietās, bet ...
Kāpēc jums ir nepieciešama koda struktūra?
- Apkopes vienkāršošana.
- Vienkāršojiet mācīšanos.
- Vispārīgo/svarīgo/veiksmīgo principu nostiprināšana.
- …jūsu variants
Kāpēc esošais izstrādes standarts no 1C nepalīdz?
Apskatīsim principus, kas publicēti ITS diskos un dažādos "Izstrādātāju ceļvežos ...", kas ieteicami, rakstot pārvaldītu veidlapu.- Samaziniet servera zvanu skaitu.
- Maksimālais skaitļošanas apjoms serverī.
- Ar kontekstu nesaistīti servera izsaukumi ir ātrāki nekā konteksta izsaukumi.
- Programma, ņemot vērā klienta un servera mijiedarbību.
- un tā tālāk.
Dizaina modeļi vai paaudžu gudrība
Klienta un servera mijiedarbība dažādās programmatūras tehnoloģijās ir izmantota gadu desmitiem. Atbilde uz iepriekšējā sadaļā izklāstītajiem jautājumiem ir zināma jau sen un ir apkopota divos pamatprincipos.- Tālvadības fasāde(turpmāk attālās piekļuves interfeiss)
- Datu pārsūtīšanas objekts(turpmāk Datu pārsūtīšanas objekts)
- … jābūt katram objektam, kas potenciāli paredzēts attālinātai piekļuvei zemas precizitātes interfeiss, kas samazinās konkrētas procedūras veikšanai nepieciešamo zvanu skaitu. … Tā vietā, lai pieprasītu rēķinu un visus tā punktus atsevišķi, ir nepieciešams izlasīt un atjaunināt visus rēķina punktus vienā zvanā. Tas ietekmē visu objekta struktūru...Atcerieties: attālās piekļuves interfeiss nesatur domēna loģiku.
- ... ja es būtu gādīga mamma, noteikti savam bērnam teiktu: "Nekad nerakstiet datu pārraides objektus!" Vairumā gadījumu datu migrācijas objekti ir nekas vairāk kā uzpūsts lauks… Šī pretīgā briesmona vērtība slēpjas tikai iespējamībā pārsūtiet vairākus informācijas vienumus tīklā vienā zvanā- metode, kas ir ļoti svarīga izplatītajām sistēmām.
1C platformas veidņu piemēri
API, kas izstrādātājam pieejama, izstrādājot pārvaldītu veidlapu, satur daudzus šo principu piemērus.Piemēram, OpenForm() metode, tipiska "rupja" saskarne.
OpenParameters = New Structure("Parametrs1, Parametrs2, Parametrs3", Vērtība1, Vērtība2, Vērtība3); Form = OpenForm(FormName, OpenParameters);
Salīdziniet ar v8.1 stilu.
Form = GetForm(FormName); Form.Parameter1 = Vērtība1; Form.Parameter2 = Vērtība2; Form.Open();
Pārvaldītās formas kontekstā "Datu pārsūtīšanas objektu" kopa. Var atšķirt sistēmisks Un izstrādātāja definēts.
Sistēmas modelē lietojumprogrammas objektu klientam viena vai vairāku formas datu elementu veidā. Tos nevar izveidot, ja tie nav saistīti ar veidlapas informāciju.
- DataFormsStructure
- DataFormsCollection
- DataFormStructureCollection
- DataFormsTree
- ValueVDataForm()
- FormDataToValue()
- CopyFormData()
- ValueVFormProps()
- FormAttributeToValue()
1C v8.1 piemērs:
// klientam veidlapas FillUsersCache(DepartmentReference) kontekstā
1C v8.2 piemērs:
// serverī veidlapas ProcessingObject = FormAttributeToValue("Object") kontekstā; ProcessingObject.FillCacheUsers(DepartmentReference); ValueVFormAttribute(ProcessingObject, "Object");
Datu migrācijas objekti, kuru struktūru nosaka izstrādātājs, ir neliela to veidu apakškopa, kas ir pieejami gan klientā, gan serverī. Visbiežāk kā "rupjas" saskarnes metožu parametri un rezultāti tiek izmantoti:
- Primitīvie veidi (virkne, skaitlis, Būla)
- Struktūra
- Sarakste
- masīvs
- Saites uz lietojumprogrammu objektiem (unikāls identifikators un teksta attēlojums)
&OnServerWithoutContext Funkcija ServerChangeOrderStatus(Pasūtījumi, JaunsStatuss) Errors = New Match(); // [pasūtījums][kļūdas apraksts] Katram pasūtījumam no pasūtījumiem Loop StartTransaction(); Mēģināt DocOb = Order.GetObject(); …. citas darbības, iespējams, ne tikai ar pasūtījumu... Izņēmums CancelTransaction(); Errors.Insert(Pasūtījums, AprakstsKļūda()); Mēģinājuma beigas; EndCycle; Atgriešanas kļūda; EndFunction // ServerChangeOrderStatus()
Koda strukturēšana
Galvenie mērķi, kas jāatspoguļo pārvaldītās formas modulī, un pieejas risinājumam.- Skaidra klienta un servera koda atdalīšana. Neaizmirsīsim, ka izpildes brīdī tie ir divi savstarpēji mijiedarbīgi procesi, kuros katrā pieejamā funkcionalitāte būtiski atšķiras.
- Skaidra attālās piekļuves saskarnes izvēle, kuras servera metodes var izsaukt no klienta un kuras nevar? Attālās saskarnes metožu nosaukumi sākas ar prefiksu "Serveris". Tas ļauj uzreiz redzēt vadības pāreju uz serveri, lasot kodu, un vienkāršo kontekstuālo mājienu izmantošanu. Ņemiet vērā, ka oficiālais ieteikums (ITS) iesaka nosaukšanas metodes ar postfixes, piemēram, ChangeOrderStatusOnServer(). Tomēr jāatkārto, ka ne visas servera metodes var izsaukt no klienta, tāpēc loģiskā pieejamība ir svarīgāka nekā kompilācijas vieta. Tāpēc ar prefiksu “Server” mēs atzīmējam tikai klientam pieejamās metodes, piemēra metode tiks saukta ServerChangeOrderStatus().
- Lasāmība. Gaumes lieta, mēs pieņemam pasūtījumu, kad modulis sākas ar veidlapas izveides procedūrām serverī un attālās piekļuves metodēm.
- Uzturamība. Jauna koda pievienošanas vietai jābūt skaidri noteiktai. Svarīgs moments ir tas, ka moduļa beigās tiek pievienoti konfiguratora automātiski izveidotie metožu elementi. Tā kā veidlapas elementu notikumu apstrādātāji visbiežāk tiek izveidoti automātiski, attiecīgais bloks tiek novietots pēdējais, lai nevilktu katru apdarinātāju uz citu vietu modulī.
- Grafiskā iespēja - skaidri parāda galveno izpildes plūsmu.
- Teksta opcija ir veidnes dizaina piemērs struktūras ātrai ievietošanai jaunā veidlapas modulī.
//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Datums=""/> // <Описание> // // /////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////. /////////////////////////////////////////////////// ////////////// // SERVERĀ //******* NOTIKUMI SERVERĀ ******* &Par servera izveides procedūra serverī (kļūme, StandardProcessing) //Ievietot apdarinātāja saturu EndProcedure //******* TĀLĀS PIEKĻUVES INTERFESS ****** //******** UZŅĒMĒJDARBĪBAS LOĢIKA SERVERĀ ****** * /////////////////////////////////////////////////// /////////////////////////////// // VISPĀRĒJĀS KLIENTA UN SERVERA METODES ///////////// /////////////////////////////////////////////////// //////////// //////// // PAR KLIENTU //******* BIZNESA LOĢIKA UZ KLIENTA ******* //** ***** KOMANDAS ******* //******* NOTIKUMI KLIENTAJĀ ****** /////////////////// /////////////////////////////////////////////////// //////////// / / GALVENIE PROGRAMMU OPERATORI
Saistīti jautājumi
Noslēgumā mēs ieskicējam dažas jomas, par kurām ir lietderīgi padomāt, programmējot klienta un servera mijiedarbību.- Attālās piekļuves saskarnes ieviešanas iespējas. Asinhronija, precizitāte...
- kešatmiņa. 1C pieņēma neveiksmīgu arhitektūras lēmumu, ieviešot kešatmiņu tikai parasto moduļu izsaukšanas metožu līmenī un nesniedzot vadības iespējas (jaunais laiks, atiestatīšana pēc pieprasījuma).
- Netieši servera izsaukumi. Neaizmirstiet par tehnoloģiskajām iezīmēm, daudzas klienta "nekaitīgas" darbības provocē platformu piekļūt serverim.
Veidlapas 1C:Enterprise ir paredzēti, lai parādītu un rediģētu datubāzē esošo informāciju. Veidlapas var piederēt konkrētiem konfigurācijas objektiem vai pastāvēt atsevišķi no tiem, un tās var izmantot viss lietojumprogrammas risinājums kopumā.
Piemēram, ceļvedis Nomenklatūra var būt vairākas formas, kas tiks izmantotas konkrētiem mērķiem - direktorija elementa rediģēšanai, saraksta parādīšanai utt.:
Līdzās tam var būt vispārīgas formas, kas nepieder pie konkrētiem konfigurācijas objektiem – vispārīgās formas.
Pamatformas
Katru konfigurācijas objektu var izmantot noteiktu standarta darbību veikšanai. Piemēram, jebkuram direktorijam var būt nepieciešams parādīt tā elementu sarakstu, parādīt atsevišķus direktorija elementus, parādīt direktorijas grupu, atlasīt elementus un elementu grupas no direktorija. Jebkuram dokumentam šādu darbību saraksts būs daudz mazāks: dokumentu saraksta skatīšana, atlase no dokumentu saraksta un viena dokumenta apskate.
Lai nodrošinātu šādu standarta darbību veikšanu ar pielietotā risinājuma objektu datiem, katram no tiem ir noteikta pamatformu kopa, kas tiks izmantota, veicot atbilstošās darbības. Galveno var piešķirt jebkurai no šim objektam pakārtotajām formām. Piemēram, direktorijs Nomenklatūra var pastāvēt šādas galvenās formas:
Un dokuments Preču un pakalpojumu saņemšana galveno formu sastāvs būs atšķirīgs:
Tādējādi, ja lietotājs vēlas redzēt direktoriju sarakstu Nomenklatūra vai dokumentu sarakstu Preču un pakalpojumu saņemšana, sistēma atvērs atbilstošo veidlapu, kas šiem objektiem piešķirta kā saraksta forma.
Automātiski ģenerētas veidlapas
Svarīga 1C:Enterprise 8 sistēmas iezīme ir automātiski ģenerētu veidlapu mehānisms. Šis mehānisms atbrīvo izstrādātāju no nepieciešamības izveidot visas iespējamās veidlapas katram konfigurācijas objektam. Pietiek, ja izstrādātājs pievieno jaunu konfigurācijas objektu, un sistēma pati ģenerēs nepieciešamās formas lietotāja īstajos darba brīžos, lai parādītu šajā objektā ietverto informāciju.
Tādējādi izstrādātājam ir jāizveido savas lietojumprogrammu risinājumu objektu formas tikai tad, ja tām ir jāatšķiras (atšķirīgs dizains vai īpaša uzvedība) no sistēmas automātiski ģenerētajām formām.
Veidlapas saistīšana ar datiem
Tas, ka forma pieder vienam vai otram konfigurācijas objektam, nenosaka formā attēlojamo datu sastāvu. Ka forma pieder, piemēram, direktorijai Nomenklatūra, ļauj to piešķirt vienai no galvenajām šī direktorija formām, taču nekādā veidā nenosaka, kāda veida datus šī forma parādīs un kāda būs tās darbība.
Lai veidlapu sasaistītu ar datiem, tiek izmantoti formas atribūti, kas norāda veidlapas attēloto datu sarakstu. Visām veidlapām ir vienāda darbība neatkarīgi no tā, kādi dati tiek parādīti. Taču vienu no formas atribūtiem var iestatīt kā primāro formas atribūtu (tas ir izcelts treknrakstā), tādā gadījumā formas standarta uzvedība un tās īpašības tiks papildinātas atkarībā no primārās formas atribūta veida:
Piemēram, ja dokuments ir piešķirts kā galvenais formas atribūts Preču un pakalpojumu saņemšana, tad, kad veidlapa tiks aizvērta, sistēma prasīs apstiprinājumu šī dokumenta ierakstīšanai un ievietošanai. Ja, teiksim, uzziņu grāmata ir piešķirta kā galvenais formas atribūts Nomenklatūra, tad, aizverot veidlapu, šāda apstiprinājuma pieprasījuma nebūs.
Veidlapas struktūra
Veidlapu galvenā iezīme ir tā, ka izstrādātājs tās nav zīmējis detalizēti, “pa pikseļiem”. Veidlapa konfigurācijā ir formas sastāva loģisks apraksts. Un konkrēto elementu izvietojumu sistēma veic automātiski, kad tiek parādīta forma.
Veidlapas daļa, kas tiek parādīta (redzama lietotājam), ir aprakstīta kā koks, kas satur formas elementus.
Elementi var būt ievades lauki, izvēles rūtiņas, radio pogas, pogas utt. Turklāt elements var būt citu elementu grupa. Grupu var attēlot kā paneli ar rāmi, paneli ar lapām (cilnēm), pašu lapu, komandu paneli. Turklāt elements var būt tabula, kas ietver arī elementus (kolonnas). Elementu struktūra apraksta, kā izskatīsies veidlapa.
Visa veidlapas funkcionalitāte ir aprakstīta detaļu un komandu veidā. Detaļas ir dati, ar kuriem darbojas veidlapa, un komandas ir veiktās darbības. Tādējādi izstrādātājam veidlapu redaktorā ir jāiekļauj veidlapā nepieciešamās detaļas un komandas, jāizveido veidlapas elementi, kas tos parāda, un, ja nepieciešams, elementi jāsakārto grupās.
Pamatojoties uz šo loģisko aprakstu, sistēma automātiski ģenerē veidlapas izskatu, ko parādīt lietotājam. Tajā pašā laikā sistēma ņem vērā dažādas attēloto datu īpašības (piemēram, tipu), lai veidlapas elementus sakārtotu pēc iespējas ērtāk lietotājam.
Izstrādātājs var ietekmēt elementu izvietojumu ar dažādiem iestatījumiem. Tas var noteikt elementu secību, norādīt vēlamo platumu un augstumu. Tomēr šī ir tikai papildu informācija, kas palīdz sistēmai parādīt veidlapu.
Veidlapās izstrādātājs var izmantot ne tikai pašas formas komandas, bet arī globālās komandas, kas tiek izmantotas visas konfigurācijas komandu saskarnē. Papildus ir ieviesta iespēja izveidot parametrējamas komandas, kas atvērs citas formas, ņemot vērā aktuālās formas konkrētos datus. Piemēram, tas var būt izsaukums uz atskaiti par atlikumiem noliktavā, kas pašlaik ir atlasīta rēķina formā.
Mēs visi zinām, ka uzņēmumam 1C bija daudz dažādu 1C platformas versiju, tagad mūs interesēs viena no jaunākajām versijām šī rakstīšanas laikā, tās ir versijas 1C 8.2 un 1C 8.3. Ja jums ir nācies strādāt abās šajās versijās, tad visticamāk pamanīja atšķirības šo versiju saskarnēs, lietotājiem tie atšķiras tikai ārēji. Būtībā izvēle parastā vai pārvaldītā lietotne norāda sistēmai, kuras veidlapas jāparāda, lai tās palaistu, regulāri vai kontrolēti, kā arī kurš lietojumprogrammu klients tiks izmantots pēc noklusējuma, biezs vai plāns. Plašāku informāciju par klientiem skatiet rakstā "Kas ir biezs un plāns klients 1C, kā arī to atšķirības."
Parasta 1C lietojumprogramma (parastās veidlapas, parasta saskarne, versija 1C 8.2)
1C 8.2 versijā ir iespējams tikai darbs ar parastajām formām, parastā pielietojuma režīmā. Zemāk esošajā attēlā ir redzama bāze darbības režīmā "parastā 1C lietojumprogramma" (parastās formas).
Pārvaldīta lietojumprogramma 1C (pārvaldītās veidlapas, pārvaldītais interfeiss, versija 1C 8.3)
1C 8.3 platformā mēs varam strādāt gan ar parastajām formām (saderības režīmā), gan ar pārvaldītajām formām. Un pārvaldītajām formām ir divu veidu displejs: standarta un taksometra. Tālāk ir parādīts 1C 8.3 konfigurācijas piemērs ar standarta pārvaldītajām formām, un pēc tam tiek parādīts Taxi interfeiss.
Kāda ir atšķirība starp parasto un pārvaldīto 1C lietojumprogrammu?
Kā jau esam noskaidrojuši parasta lietojumprogramma un pārvaldīta lietojumprogramma ir šādi 1C programmas palaišanas veidi. Turklāt atkarībā no palaišanas veida vērtības 1C ( regulāra vai pārvaldīta lietojumprogramma), konkrētais interfeiss tiks ielādēts pēc noklusējuma ( parastās vai pārvaldītās veidlapas), tāpēc šim jēdzienam ir tik daudz sinonīmu. Vēlamies atzīmēt, ka saskarņu atšķirības ir diezgan būtiskas, pārvaldītais interfeiss ir pilnībā pārveidots. Principā šīs ir visas atšķirības, ko redz parastie 1C programmas lietotāji. Kas attiecas uz programmētājiem, pārvaldītajam interfeisam ir nepieciešams rakstīt modificētu kodu, jo izstrāde jau notiek 1C 8.3, nevis 1C 8.2, līdz ar to visas no tā izrietošās sekas. Kods ir jāsadala arī klientā un serverī, tas tiek norādīts, izmantojot atbilstošās direktīvas konfiguratorā.
Kļujevs V.V.
http://prof1c.kklab.ru
DARBS AR SLĒDŽIEM
Aicinu ņemt vērā visus vietnes servisa lietotājus - materiālus ievietoju sadaļā Iesācēji !!!
8.2. Pārvaldītās veidlapas
Pētot pārvaldīto formu uzvedību, programmētāji vai interfeisa izstrādātāji saskaras ar jautājumu – kur ir slēdži pārvaldītajās formās un kā tos pievienot formai. Sīkums, bet nepatīkami daudz laika tiek veltīts šādiem niekiem, lai gan šo laiku varētu veltīt algoritma izstrādei un optimizēšanai, nevis formas noformēšanai.
Tātad, izveidosim tukšu konfigurāciju, lai izprastu problēmu, vai izvēlieties jebkuru tipisku konfigurāciju.
Dodieties uz grupu, kurā ir direktoriji, un eksperimentam pievienojiet jaunu direktoriju. Es gribu atzīmēt, ka konfigurācijā ir jābūt galvenajam palaišanas režīmam - Pārvaldītajai lietojumprogrammai.
Tātad, izveidosim jaunu direktoriju un pievienosim rekvizītus "Props1" ar veidu "Boolean"
Tagad dodieties uz cilni Veidlapas un pievienojiet jaunu veidlapu.
Tātad, pārvaldītā forma ir izveidota, tagad strādāsim ar veidlapu un atradīsim visu to pašu, kur atrodas slēdzis.
Šeit ir mūsu veidlapa, un uz tās mēs redzam mūsu rekvizītus, bet izvēles rūtiņas veidā
Tātad, ko mēs izdarījām nepareizi?
Apskatīsim rekvizītus, lai redzētu, vai ir pārslēgts uz vadības ierīces skatu.
Un mēs redzam, ka Switch Field šeit nav! (Kur mēs kļūdījāmies?
Acīmredzot formas vadīklas izskats ir atkarīgs no datu veida, atgriezīsimies pie formas rekvizītiem, proti, cilnes Details un mainīsim sava atribūta rekvizītus - proti, tā veidu "Boolean", uz tipu "Number".
Tagad atgriezīsimies pie vadīklas rekvizītiem un pārbaudīsim, vai tā rekvizītos nav pievienots vadīklas skats - - - Un urra, mēs tur redzam skatu - Switch lauks.
Tagad apskatiet formu, ko mēs redzam:
Mēs redzam - 3 noklusējuma vērtības, 3 radio pogas, bet mums ir vajadzīgas divas no tām, dodieties vēlreiz uz rekvizītu rekvizītiem un apskatiet tur rekvizītus "Sleju skaits"
2 — iestatīt Kolonnu skaits — 2.
Tas varētu nedaudz apturēt nogurušu programmētāju)), bet tagad gan viņš, gan mēs to zinām!
8.2. Kopējās veidlapas.
Nervozitāte ar slēdžiem parastajās formās.
Ir tādi brīži, un tie notiek), kad jums ir jāmaina kāda gatava forma, kurā jau ir daži slēdži, un jums ir jāpievieno vēl viens slēdzis šai formai. Šeit rodas sava veida garlaicība, kas aizņem daudz laika, un laiks nav paredzēts koda programmēšanai, bet gan laika izšķiešana, lai parādītu lietotājam šos slēdžus.
Tātad, aplūkosim piemēru. Ir šāds dokuments kvīšu koriģēšanai 1C SCP - tas noteikti pastāv. Kādreiz mums vajadzēja tai pievienot slēdžus, lai tiktu uzzīmēti nedaudz atšķirīgi grāmatojumi. Kas par problēmu, tas liktos vajadzīgs, tad vajag, darīsim. Bet šai formai jau ir 2 radio pogas.
Šādi izskatās forma, kurā mums jāpievieno vairāk slēdžu
Cilnē Papildu mēs vēlamies ievietot vēl divas radio pogas. Tāpēc pirmā darbība ir drosmīgi pievienot jaunu vadīklu vietai, kur tā jāievieto.
Šķiet, ka viss ir vienkārši. Izveidojam jaunu atribūtu, ar tipu - "Numurs" un ievietojam 2 slēdžus, no kuriem viens varēs ierakstīt datus atribūtā, bet otrs nevarēs.
Pievienojiet jaunu vadīklu - Switch, tabulā ar slēdžu skaitu un aprakstu pievienojiet Switch2, iestatiet Switch1 kā pirmo grupā un nospiediet ok. Izveidotās vadīklas ievietojam veidlapā. Atjauniniet datu bāzes konfigurāciju (F7) un palaidiet atkļūdošanai.
Kad tas tiek izpildīts (veidojot jaunu dokumentu režīmā 1C:Enterprise), mēs redzam, ka neatkarīgi no tā, kā mēs cenšamies noklikšķināt uz Switch2, nekas nenotiek. Elementi nedarbojas tā, kā vajadzētu. Šeit ir viena iezīme.
Atgriezieties konfiguratorā. Izvēlieties vienumu izvēlnē Forma -> Pārbraukšanas secības iestatīšana... (svarīgi, lai forma būtu atvērta ekrānā)
Lai mūsu slēdži darbotos, jums ir jāpārtrauc automātiskais pasūtījums un jāpiekrīt manuālajam. Un ielieciet formu, lai mūsu slēdži iet - viens pēc otra kārtībā.
LABI. Atjauniniet konfigurāciju un mēģiniet palaist.
Lieliski. Viss strādāja.
Pēc izvēles — video (nav skaņas, tāpēc viss ir skaidrs)
