Radio dugmad, redovna aplikacija, upravljani obrasci. Prekidači, normalna aplikacija, upravljani obrasci 1c problemi sa upravljanim obrascima
Platforma 1C:Enterprise omogućava vam da programski dodajete i mijenjate elemente upravljanog obrasca. Hajde da vidimo zašto bi ovo moglo biti potrebno.
Programska izmjena obrasca može biti potrebna u nekoliko slučajeva:
- Prilikom finaliziranja tipičnih konfiguracija kako bi se olakšala naknadna procedura ažuriranja. U tom slučaju će se promijeniti samo modul obrasca. Module je mnogo lakše ažurirati nego obrazac.
- Prilikom implementacije nekih općih algoritama. Na primjer, u podsistemu "Zabrana uređivanja detalja objekata" za sve objekte povezane sa podsistemom programski se kreira dugme za omogućavanje mogućnosti uređivanja detalja.
- Prilikom implementacije nekih specifičnih algoritama. Na primjer, polja za uređivanje dodatnih detalja kreiraju se u priručniku Nomenklature.
U upravljanom obliku možete programski dodati, modificirati i ukloniti:
- rekviziti;
- lokalne komande;
- elementi.
Sve ove operacije moguće su samo na serveru.
Programsko preoblikovanje ima ograničenja:
- Možete izbrisati samo programski dodane atribute/naredbe/elemente. Ne možete programski izbrisati objekte kreirane u konfiguratoru.
- Nemoguće je dodijeliti atribut kao glavni.
Promjena naredbi obrasca
Za upravljanje sastavom naredbi za objekt ManagedForm imati kolekciju Timovi
Dodati (< ИмяКоманды >)
Količina ()
Nađi (< ИмяКоманды >)
Izbriši (< Команда >)
Kolekcija komandi dostupna je i na klijentu i na serveru. Izmjena kolekcije (metode Add () i Remove () ) moguća je samo na serveru. Možete pretraživati i dobiti broj elemenata (metode Find () i Quantity () ) i na klijentu i na serveru.
Kao primjer rada sa naredbama obrasca, napravimo novu naredbu ChangeHistory s naslovom "Change History...", koja će pozvati rukovalac DisplayHistory() . Kreiranje se vrši kada se obrazac otvori.
&Na serveru
Procedura OnCreateOnServer(Neuspjeh, Standardna obrada)
Tim = Komande. Dodati( "Historija promjena");
Tim . Akcija = ;
Tim . Naslov = "Istorija promjena...";
EndProcedure
&AtClient
Procedura Connected_DisplayHistory(Command)
// komandne akcije
EndProcedure
Rukovalac komandom mora biti lociran u obrascu i mora imati direktivu kompilacije &AtClient.
Promjena detalja obrasca
Čitanje sastava atributa obrasca obavlja funkcija Saznajte detalje(< Путь >) koji vraća niz tipa FormAttributes. Parametar funkcije specificira putanju do roditeljskog atributa (kao string). Ako je parametar izostavljen ili je naveden prazan niz, vraćaju se vjerodajnice najviše razine.
Promjena detalja se vrši metodom EditRequisites(<Dodati detalji>, <Uklonjivi detalji>) objekt ManagedForm. Opcije Dodati detalji I Uklonjivi detalji prosljeđuju se nizovi sa elementima tipa Form Requisite.
Pažnja!
Proces promjene sastava detalja je prilično intenzivan resursima. U stvari, forma se ponovo kreira. U tom smislu, rad sa detaljima obrasca se izvodi u paketnom režimu.
Kreirajmo novi atribut obrasca pod nazivom Kupac:
AddedAttributes = Novi niz;
Dodati detalji. Dodaj (novi atribut obrasca("Kupac", New TypeDescription ("DirectoryReference.Counterparties"), "Klijent");// Promjene u sastavu atributa
);
Promjena elemenata forme
Za upravljanje sastavom elemenata objekta ManagedForm imati kolekciju Elementi. Kolekcija ima nekoliko metoda:
Insert (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)
Dodati (< Имя>, < ТипЭлемента>, < Родитель >)
Količina ()
Nađi (< Имя >)
premjestiti(< Элемент>, < Родитель>, < МестоРасположения >)
Izbriši (< Элемент >)
Kolekcija Elements dostupna je i na klijentu i na serveru. Izmijenite kolekciju (metode umetanja () , Dodaj () , Premjesti () i Izbriši () ) dostupni su samo na serveru. Možete pretraživati i dobiti broj elemenata (metode Find () i Quantity () ) i na klijentu i na serveru. Elementi kolekcije mogu biti:
- GroupForm;
- TableForms;
- FormField;
- ButtonForms.
Elementima forme možete programski dodijeliti rukovaoce događajima. U tu svrhu, metod SetAction(< ИмяСобытия>, < Действие >) .
Pogledajmo neke od najčešćih praktičnih primjera rada s naredbama, atributima i elementima obrasca.
Dodavanje komande i povezanog dugmeta:
// Kreirajte tim
Tim = Komande. Dodati( "Historija promjena");
Tim . Akcija = "Connected_DisplayHistory"; // Obrazac mora sadržavati proceduru sa navedenim imenom
Tim . header = "Istorija promjena...";
// Kreirajte dugme i povežite ga sa komandom
Element = Stavke. Dodati( "Historija promjena", Tip("FormButton" ));
Element.CommandName = "Historija promjena";
Dodavanje atributa i pripadajućeg polja za unos:
// Opis dodanih detalja
AddedAttributes = Novi niz;
Dodati detalji. Dodati(Novi atribut obrasca ("Kupac", novi opis tipa ( "Referentna veza. Ugovorne strane"), "Klijent" ));
// Promjena sastava atributa
EditAttributes(AddedAttributes);
// Kreiranje polja za unos i povezivanje sa atributom
Element = Stavke. Add("Kupac" , Tip("FormField" ));
Element . Pogled = ViewFormFields. Polje za unos;
Element . PathToData= "Kupac" ;
Dodjeljivanje rukovaoca događaja elementu obrasca:
ItemBuyer. SetAction("Kada se promeni" , "Plug-in_BuyerOnChange");
&AtClient
Procedura Plugin_BuyerOnChange(Element )
// Akcije događaja
EndProcedure
Pažnja!
Procedure koje se instaliraju kao rukovaoci događajima iz koda koristeći metodu SetAction(), preporučuje se korištenje prefiksa Connected_.
Pažnja!
Možete preuzeti obradu s primjerima programskog pretraživanja i promjene detalja, naredbi i elemenata upravljanog obrasca.
I Data Transfer Object za strukturiranje koda, upravljani oblik u 1C 8.2 okruženju.
Uvod
Počnimo s kratkim opisom koncepta "upravljane forme" i srodnih koncepata 1C platforme. Stručnjaci za platformu mogu preskočiti ovaj odjeljak.2008. godine postala je dostupna nova verzija platforme 1C: Enterprise 8.2 (u daljem tekstu Upravljana aplikacija), koja u potpunosti mijenja cijeli sloj rada sa sučeljem. Ovo uključuje komandni interfejs, obrasce i sistem prozora. Ovo ne samo da menja model razvoja korisničkog interfejsa u konfiguraciji, već takođe predlaže novu arhitekturu za razdvajanje funkcionalnosti između klijentske aplikacije i servera.
Upravljana aplikacija podržava sljedeće tipove klijenata:
- Debeli klijent (normalan i upravljani način pokretanja)
- Tanki klijent
- Web klijent
Glavne razlike upravljanih formi za programera:
- Deklarativan, a ne "po pikselima" opis strukture. Specifično postavljanje elemenata sistem vrši automatski kada se obrazac prikaže.
- Sve funkcionalnosti obrasca su opisane u obrascu detalji I komande. Detalji su podaci sa kojima obrazac radi, a komande su radnje koje se izvode.
- Obrazac se izvršava i na serveru i na klijentu.
- U kontekstu klijenta, gotovo svi tipovi aplikacija nisu dostupni, te je shodno tome nemoguće mijenjati podatke u infobazi.
- Za svaku varijablu metode ili forme, ona mora biti specificirana direktiva o kompilaciji A koji određuje da li je lokacija izvršenja (klijent ili server) i pristup kontekstu obrasca.
- &AtClient
- &Na serveru
- &OnServerWithoutContext
- &Kod klijentaNa serveruBezkonteksta
Sve dalje diskusije će biti o desnoj strani ilustracije, o tome kako strukturirati kod modula i koji principi će vam omogućiti da implementirate efikasnu interakciju klijent-server.
Hajde da definišemo problem
Prošlo je nekoliko godina otkako se nova verzija 1C platforme aktivno koristi i mnoga rješenja (konfiguracije) su objavljena i od strane 1C i njegovih brojnih partnera.Da li su programeri razvili zajedničko razumijevanje principa klijent-server interakcije prilikom kreiranja obrazaca za to vrijeme i da li se pristup implementaciji programskih modula promijenio u novoj arhitektonskoj stvarnosti?
Razmotrite strukturu koda (modul forme) u nekoliko oblika iste tipične konfiguracije i pokušajte pronaći obrasce.
Pod strukturom podrazumijevamo sekcije koda (najčešće su to blokovi komentara) koje je programer izabrao za grupisanje metoda i direktive za kompajliranje ovih metoda.
Primjer 1:
Odjeljak za obradu događaja Metod - na klijentu Metod - na serveru Metod - na klijentu Odjeljak uslužnih procedura i funkcija Pomoćne funkcije kontrole ulaza
Primjer 2:
Servisne procedure i funkcije Dokumenti za plaćanje Vrednosti Rukovaoci događaja
Primjer 3:
Servisne procedure na serveru Servisne procedure na klijentu Servisne procedure na serveru bez konteksta Rukovaoci događaja zaglavlja Rukovaoci događaja naredbe
Primjer 4:
Procedure opće namjene Obrađivači događaja obrasca Procedure podsistema "kontaktne informacije".
Zapravo, nedostaje struktura koda, ili blago rečeno, slična je onome što je bilo u obrascima 8.1:
- Neinformativne riječi "General, Service, Auxiliary."
- Stidljiv pokušava da odvoji klijentske i serverske metode.
- Često su metode grupisane prema elementima interfejsa "Rad sa tabelarnim delom Proizvodi, Kontakt informacije".
- Proizvoljan raspored metoda i kodnih grupa. Na primjer, Događaji mogu biti na vrhu u jednom obliku, na dnu u drugom, uopće nisu istaknuti u trećem, itd.
- I ne zaboravimo da je sve ovo u istoj konfiguraciji.
- Da, postoje konfiguracije u kojima su riječi "General, Service, Auxiliary" uvijek na istim mjestima, ali ...
Zašto vam je potrebna struktura koda?
- Pojednostavljenje održavanja.
- Pojednostavite učenje.
- Učvršćivanje opštih/važnih/uspješnih principa.
- ...vaša opcija
Zašto postojeći razvojni standard iz 1C ne pomaže?
Pogledajmo principe objavljene na ITS diskovima i u raznim "Vodičima za programere...", koji se preporučuju prilikom pisanja upravljanog obrasca.- Minimizirajte broj poziva servera.
- Maksimalno računanje na serveru.
- Pozivi servera koji nisu u kontekstu su brži od kontekstnih poziva.
- Program koji ima na umu interakciju klijent-server.
- i tako dalje.
Dizajnerski obrasci ili generacijska mudrost
Interakcija klijent-server se decenijama koristi u raznim softverskim tehnologijama. Odgovor na pitanja iznesena u prethodnom odeljku odavno je poznat i sažet je u dva osnovna principa.- Remote Facade(u daljem tekstu Interfejs za daljinski pristup)
- Objekat prenosa podataka(u daljem tekstu objekt prijenosa podataka)
- … svaki objekat potencijalno namijenjen za daljinski pristup mora imati interfejs niske granularnosti, što će minimizirati broj poziva potrebnih za izvođenje određene procedure. … Umjesto zahtjeva za fakturu i sve njene tačke posebno, potrebno je pročitati i ažurirati sve tačke računa u jednom pozivu. Ovo utiče na celokupnu strukturu objekta... Zapamtite: interfejs za daljinski pristup ne sadrži logiku domene.
- ... da sam brižna majka, svom djetetu bih definitivno rekla: „Nikad ne piši objekte za prijenos podataka!“ U većini slučajeva, objekti migracije podataka nisu ništa drugo do bloated fieldset… Vrijednost ovog odvratnog čudovišta leži isključivo u mogućnosti prenijeti više informacija preko mreže u jednom pozivu- tehnika koja je od velikog značaja za distribuirane sisteme.
Primjeri predložaka u 1C platformi
API dostupan programeru prilikom razvoja upravljanog obrasca sadrži mnogo primjera ovih principa.Na primjer, OpenForm() metoda, tipično "grubo" sučelje.
OpenParameters = Nova struktura("Parametar1, Parametar2, Parametar3", Vrijednost1, Vrijednost2, Vrijednost3); Obrazac = OpenForm(Naziv forme, OpenParameters);
Uporedite sa stilom v8.1.
Forma = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();
U kontekstu upravljanog obrasca, skup "Objekata prijenosa podataka". Može se razlikovati sistemski I definisano od strane programera.
Sistemski modeliraju objekt aplikacije na klijentu, u obliku jednog ili više elemenata podataka forme. Ne možete ih kreirati izvan vezivanja za detalje obrasca.
- DataFormsStructure
- DataFormsCollection
- DataFormStructureCollection
- DataFormsTree
- ValueVDataForm()
- FormDataToValue()
- CopyFormData()
- ValueVFormProps()
- FormAttributeToValue()
Primjer 1C v8.1:
// na klijentu u kontekstu obrasca FillUsersCache(DepartmentReference)
Primjer 1C v8.2:
// na serveru u kontekstu forme ProcessingObject = FormAttributeToValue("Object"); ProcessingObject.FillCacheUsers(DepartmentReference); ValueVFormAttribute(ProcessingObject, "Object");
Objekti migracije podataka, čiju strukturu definira programer, su mali podskup tipova dostupnih i na klijentu i na serveru. Najčešće se kao parametri i rezultati metoda "grubog" sučelja koriste sljedeće:
- Primitivni tipovi (niz, broj, boolean)
- Struktura
- Prepiska
- niz
- Veze na objekte aplikacije (jedinstveni identifikator i tekstualni prikaz)
&OnServerWithoutContext Funkcija ServerChangeOrderStatus(Orders, NewStatus) Greške = New Match(); // [narudžba][opis greške] Za svaku narudžbu od petlje naloga StartTransaction(); Pokušaj DocOb = Order.GetObject(); …. druge radnje, moguće ne samo sa nalogom... Izuzetak CancelTransaction(); Errors.Insert(Red, DescriptionError()); Kraj pokušaja; EndCycle; Return Error; EndFunction // ServerChangeOrderStatus()
Strukturiranje koda
Glavni ciljevi koje modul upravljane forme treba da odražava i pristupi rješenju.- Jasno razdvajanje klijentskog i serverskog koda. Ne zaboravimo da su u trenutku izvršenja to dva procesa u interakciji, u svakom od kojih se dostupna funkcionalnost značajno razlikuje.
- Jasan izbor interfejsa za daljinski pristup, koje metode servera se mogu pozvati sa klijenta, a koje ne? Imena metoda udaljenog interfejsa počinju prefiksom "Server". Ovo vam omogućava da odmah vidite prelazak kontrole na server prilikom čitanja koda i pojednostavljuje upotrebu kontekstualnih savjeta. Imajte na umu da zvanična preporuka (ITS) predlaže imenovanje metoda sa postfiksima, kao što je ChangeOrderStatusOnServer(). Međutim, da ponovimo, ne mogu se sve serverske metode pozvati sa klijenta, pa je logička dostupnost važnija od lokacije kompilacije. Stoga, sa prefiksom “Server” označavamo samo metode dostupne klijentu, metoda primjera će se zvati ServerChangeOrderStatus().
- Čitljivost. Stvar ukusa prihvatamo narudžbu kada modul počne sa procedurama kreiranja obrasca na serveru i metodama daljinskog pristupa.
- Održavanje. Mjesto za dodavanje novog koda mora biti jasno definirano. Važna stvar je da se metodni stubovi automatski kreirani od strane konfiguratora dodaju na kraj modula. Budući da se rukovaoci događaja elementa obrasca najčešće kreiraju automatski, odgovarajući blok se postavlja zadnji kako se svaki rukovalac ne bi povukao na drugo mjesto u modulu.
- Grafička opcija - jasno prikazuje glavni tok izvršenja.
- Opcija teksta je primjer dizajna predloška za brzo umetanje strukture u novi modul obrasca.
//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Datum=""/> // <Описание> // // ////////////////////////////////////////////////// / ///////////////////////////// // VARIJABLE MODULA /////////////// / /////////////////////////////////////////////////////////////////////////// // ////////////// // NA SERVERU //******* DOGAĐAJI NA SERVERU ******* &Na serveru Procedura prilikom kreiranja na serveru( Failure, StandardProcessing) //Ubacite sadržaj obrađivača EndProcedure //******* INTERFEJS DALJINSKOG PRISTUPA ******* //******* POSLOVNA LOGIKA NA SERVERU **** *** ///////// ////////////////////////////////////// //////////// ///////////////////// // ZAJEDNIČKE METODE KLIJENTA I SERVERA ////////// ////////////// /////////////////////////////////// ////////////// //////// // O KLIJENTU //******* POSLOVNA LOGIKA NA KLIJENTU ******* // ******* NAREDBE ******* //******* DOGAĐAJI NA KLIJENTU ****** //////////////// /////////////// /////////////////////////////////// /////////////// / / GLAVNI PROGRAMSKI OPERATORI
Povezana pitanja
U zaključku, ističemo nekoliko oblasti o kojima je korisno razmišljati prilikom programiranja interakcije klijent-server.- Opcije za implementaciju interfejsa za daljinski pristup. Asinhronost, granularnost...
- keširanje. 1C je doneo nesrećnu arhitektonsku odluku, uvodeći keširanje samo na nivou pozivanja metoda uobičajenih modula i ne pružajući opcije kontrole (ažurno vreme, resetovanje na zahtev).
- Implicitni pozivi servera. Ne zaboravite na tehnološke karakteristike, mnoge "bezopasne" operacije na klijentu provociraju platformu da pristupi serveru.
Forms u 1C:Enterprise dizajnirani su za prikaz i uređivanje informacija sadržanih u bazi podataka. Obrasci mogu pripadati određenim konfiguracijskim objektima ili postojati odvojeno od njih i koristiti ih cjelokupno aplikativno rješenje u cjelini.
Na primjer, vodič Nomenklatura može imati nekoliko formi koje će se koristiti u određene svrhe - uređivanje elementa direktorija, prikazivanje liste, itd.:
Uz to mogu postojati i opći oblici koji ne pripadaju određenim konfiguracijskim objektima - opći oblici.
Osnovni oblici
Svaki konfiguracijski objekt može se koristiti za izvođenje određenih standardnih radnji. Na primjer, za bilo koji direktorij, možda ćete trebati prikazati listu njegovih elemenata, prikazati pojedinačne elemente direktorija, prikazati grupu direktorija, odabrati elemente i grupe elemenata iz direktorija. Za bilo koji dokument, lista takvih radnji će biti mnogo manja: pregled liste dokumenata, odabir sa liste dokumenata i pregled jednog dokumenta.
Da bi se osiguralo izvođenje takvih standardnih radnji s podacima objekata primijenjenog rješenja, za svaki od njih postoji skup osnovnih oblika koji će se koristiti prilikom izvođenja odgovarajućih radnji. Glavni se može dodijeliti bilo kojem od oblika koji su podređeni ovom objektu. Na primjer, imenik Nomenklatura mogu postojati sljedeći glavni oblici:
I dokument Prijem robe i usluga sastav glavnih oblika bit će drugačiji:
Dakle, ako korisnik želi vidjeti listu direktorija Nomenklatura ili spisak dokumenata Prijem robe i usluga, sistem će otvoriti odgovarajući obrazac koji je dodijeljen kao obrazac liste za ove objekte.
Automatski generisani obrasci
Važna karakteristika sistema 1C:Enterprise 8 je mehanizam automatski generisanih obrazaca. Ovaj mehanizam oslobađa programera od potrebe da kreira sve moguće forme za svaki od konfiguracionih objekata. Dovoljno je da programer doda novi objekat konfiguracije, a sistem će sam generisati potrebne forme u pravim trenucima rada korisnika za prikaz informacija sadržanih u ovom objektu.
Dakle, programer treba da kreira sopstvene forme objekata aplikativnog rešenja samo ako moraju imati razlike (drugačiji dizajn ili specifično ponašanje) od formi koje sistem automatski generiše.
Povezivanje obrasca sa podacima
Činjenica da obrazac pripada jednom ili drugom objektu konfiguracije ne određuje sastav podataka koji se prikazuju u obrascu. Da obrazac pripada, na primjer, imeniku Nomenklatura, vam omogućava da ga dodijelite jednom od glavnih obrazaca za ovaj direktorij, ali ni na koji način ne određuje kakve će podatke ovaj obrazac prikazati i kakvo će njegovo ponašanje biti.
Da bi se obrazac povezao sa podacima, koriste se atributi obrasca koji označavaju listu podataka koje obrazac prikazuje. Svi oblici, sami po sebi, imaju isto ponašanje, bez obzira koje podatke prikazuju. Međutim, jedan od atributa obrasca može se postaviti kao primarni atribut obrasca (označen je podebljanim), u kom slučaju će se standardno ponašanje obrasca i njegova svojstva dopuniti ovisno o tipu primarnog atributa obrasca:
Na primjer, ako je dokument dodijeljen kao glavni atribut obrasca Prijem robe i usluga, onda kada se obrazac zatvori, sistem će tražiti potvrdu snimanja i objavljivanja ovog dokumenta. Ako je, recimo, referentna knjiga dodijeljena kao glavni atribut obrasca Nomenklatura, tada neće biti takvog zahtjeva za potvrdu prilikom zatvaranja obrasca.
Struktura forme
Glavna karakteristika obrazaca je da ih programer ne crta detaljno, „pikselima“. Forma u konfiguraciji je logičan opis kompozicije forme. A specifično postavljanje elemenata sistem vrši automatski kada se obrazac prikaže.
Dio obrasca koji je prikazan (vidljiv korisniku) opisuje se kao stablo koje sadrži elemente obrasca.
Elementi mogu biti polja za unos, potvrdni okviri, radio dugmad, dugmad, itd. Pored toga, element može biti grupa drugih elemenata. Grupa se može predstaviti kao panel sa okvirom, panel sa stranicama (karticama), sama stranica, komandni panel. Osim toga, element može biti tabela koja također uključuje elemente (kolone). Struktura elemenata opisuje kako će obrazac izgledati.
Sve funkcionalnosti obrasca opisane su u obliku detalja i naredbi. Detalji su podaci sa kojima obrazac radi, a komande su radnje koje se izvode. Dakle, programer u uređivaču obrazaca mora uključiti potrebne detalje i komande u obrazac, kreirati elemente obrasca koji ih prikazuju i, ako je potrebno, rasporediti elemente u grupe.
Na osnovu ovog logičkog opisa, sistem automatski generiše izgled obrasca za prikaz korisniku. Istovremeno, sistem uzima u obzir različita svojstva prikazanih podataka (na primjer, tip) kako bi rasporedio elemente obrasca što je moguće pogodnije za korisnika.
Programer može uticati na raspored elemenata različitim postavkama. Može odrediti redoslijed elemenata, naznačiti željenu širinu i visinu. Međutim, ovo su samo neke dodatne informacije koje će pomoći sistemu da prikaže obrazac.
U obrascima, programer može koristiti ne samo komande samog obrasca, već i globalne komande koje se koriste u komandnom interfejsu cijele konfiguracije. Pored toga, implementirana je mogućnost kreiranja parametarskih komandi koje će otvarati druge forme, uzimajući u obzir specifične podatke trenutnog obrasca. Na primjer, to može biti poziv na izvještaj o stanju u skladištu koji je trenutno odabran u obrascu računa.
Svi znamo da je kompanija 1C imala mnogo različitih verzija 1C platforme, sada će nas zanimati jedna od najnovijih verzija u vrijeme pisanja ovog teksta, to su verzije 1C 8.2 i 1C 8.3. Ako ste morali da radite u obe ove verzije, onda ste najverovatnije uočili razlike u interfejsima ovih verzija, za korisnike se razlikuju samo spolja. U suštini, izbor redovna ili upravljana aplikacija govori sistemu koje forme da prikaže da se pokrene, redovno ili kontrolisano, kao i koji klijent aplikacije će se koristiti po defaultu, deblji ili tanki. Za više informacija o klijentima pogledajte članak "Šta je debeli i tanak klijent u 1C, kao i njihove razlike."
Redovna 1C aplikacija (obični oblici, normalno sučelje, verzija 1C 8.2)
U 1C 8.2 moguć je samo rad sa normalnim oblicima, u normalnom načinu primjene. Na slici ispod prikazana je baza u načinu rada "obična 1C aplikacija" (obične forme).
Upravljana aplikacija 1C (upravljani obrasci, upravljani interfejs, verzija 1C 8.3)
Na platformi 1C 8.3 možemo raditi i sa redovnim formama (u režimu kompatibilnosti) i sa upravljanim oblicima. I upravljani obrasci imaju dva tipa prikaza, to su standardni i taksi. U nastavku je prikazan primjer 1C 8.3 konfiguracije sa standardnim upravljanim obrascima, a nakon njega prikazano je Taxi sučelje.
Koja je razlika između obične i upravljane 1C aplikacije?
Kao što smo već saznali obična aplikacija i upravljana aplikacija su takve vrste pokretanja 1C programa. Štoviše, ovisno o vrijednosti vrste pokretanja 1C ( redovna ili upravljana aplikacija), određeni interfejs će biti učitan prema zadanim postavkama ( redovnim ili upravljanim oblicima), stoga postoji toliko mnogo sinonima za ovaj koncept. Napominjemo da su razlike u interfejsima prilično značajne, upravljani interfejs je potpuno redizajniran. U principu, to su sve razlike koje vide obični korisnici 1C programa. Što se tiče programera, upravljani interfejs zahteva pisanje modifikovanog koda, jer je razvoj već u toku u 1C 8.3, a ne u 1C 8.2, pa otuda i sve posledice. Kod se također mora podijeliti na klijenta i servera, što je naznačeno odgovarajućim direktivama u konfiguratoru.
Klyuev V.V.
http://prof1c.kklab.ru
RAD SA PREKIDAČIMA
Molim vas da uzmete u obzir sve korisnike usluge stranice - materijale postavljam u odjeljak za početnike !!!
8.2 Upravljani obrasci
Dok proučavaju ponašanje upravljanih formi, programeri ili programeri interfejsa suočavaju se sa pitanjem – gde su prekidači u upravljanim formama i kako ih dodati u formu. Sitnica, ali se na takve sitnice troši neugodno mnogo vremena, iako bi se ovo vrijeme moglo potrošiti na razvoj i optimizaciju algoritma, a ne na dizajniranje forme.
Dakle, hajde da napravimo praznu konfiguraciju da bismo razumeli problem ili izaberite bilo koju tipičnu.
Idite na grupu koja sadrži direktorije i za eksperiment dodajte novi direktorij. Želim napomenuti da konfiguracija mora imati glavni način pokretanja - Upravljana aplikacija.
Dakle, napravimo novi direktorij i dodamo rekvizite "Props1", sa tipom "Boolean"
Sada idite na karticu Obrasci i dodajte novi obrazac.
Dakle, upravljani obrazac je kreiran, sada radimo sa formom i pronađimo gdje se nalazi prekidač.
Evo našeg formulara, i na njemu vidimo naše rekvizite, ali u obliku polja za potvrdu
Pa šta smo pogrešili?
Pogledajmo svojstva rekvizita da vidimo da li postoji prelazak na prikaz kontrole.
I vidimo da polje za prebacivanje nije ovdje! (Gdje smo pogriješili?
Očigledno, izgled kontrole na obrascu zavisi od tipa podataka, vratimo se na svojstva obrasca, odnosno na karticu sa detaljima i promenimo svojstva našeg atributa – odnosno njegov tip „Boolean“, u tip „Broj“.
Vratimo se sada na svojstva kontrole i provjerimo da li je Pogled kontrole dodat u njena svojstva - - - I urra, vidimo tamo pogled - Prebaci polje.
Sada pogledajte obrazac, šta vidimo:
Vidimo - 3 zadane vrijednosti, 3 radio dugmeta, ali nam trebaju dva, idite ponovo na svojstva rekvizita i tamo pogledajte svojstva "Broj kolona"
Za 2 - postavite Broj kolona - 2.
Ovo bi moglo malo zaustaviti umornog programera)), ali sada to znamo i on i mi!
8.2 Uobičajeni oblici.
Nervoza sa prekidačima u uobičajenim oblicima.
Postoje takvi trenuci, i oni se dešavaju) kada trebate izmijeniti neki gotov obrazac, u kojem već postoje neki prekidači, a trebate dodati još jedan prekidač u ovaj obrazac. Tu nastaje neka vrsta dosadnosti koja oduzima dosta vremena, i to ne vremena za programiranje koda - već gubljenje vremena da bi se ti prekidači prikazali korisniku.
Pogledajmo primjer. Postoji takav dokument za prilagođavanje računa u 1C SCP - definitivno postoji. Jednom smo mu trebali dodati prekidače tako da su iscrtana malo drugačija knjiženja za računovodstvo. U čemu je problem, izgleda da je potrebno, onda je potrebno, uradićemo to. Ali ovaj obrazac već ima 2 radio dugmeta.
Ovako izgleda obrazac u koji trebamo pričvrstiti više prekidača
Na naprednoj kartici želimo da postavimo još dva radio dugmeta. Dakle, prva radnja je hrabro dodavanje nove kontrole na mjesto na kojem je potrebno da je ubacimo.
Čini se da je sve jednostavno. Kreiramo novi atribut, sa tipom - "Broj" i ubacujemo 2 prekidača, od kojih će jedan moći upisati podatke u atribut, a drugi neće.
Dodajte novu kontrolu - Prekidač, u tabeli sa brojem i opisom prekidača, dodajte Switch2, postavite Switch1 kao prvi u grupi i pritisnite ok. Stvorene kontrole postavljamo na obrazac. Ažurirajte konfiguraciju baze podataka (F7) i pokrenite za otklanjanje grešaka.
Kada se izvrši (prilikom kreiranja novog dokumenta u režimu 1C:Enterprise), vidimo da se ništa ne dešava, koliko god se trudili da kliknemo na Switch2. Elementi ne rade kako bi trebali. Ovdje postoji jedna karakteristika.
Vratite se u konfigurator. Odaberite stavku u meniju Obrazac -> Podešavanje redosleda obilaženja... (važno je da obrazac bude otvoren na ekranu)
Da bi naši prekidači radili, morate prekinuti automatsku narudžbu i pristati na ručnu. I stavite u obrazac tako da naši prekidači idu - jedan za drugim redom.
UREDU. Ažurirajte konfiguraciju i pokušajte pokrenuti.
Odlično. Sve je funkcionisalo.
Opciono - video (bez zvuka, tako da je sve jasno)
