Naudojant 1C platformos 8.2 versiją, pradėti naudoti nauji sąsajos kūrimo ir vartotojo sąveikos su duomenų baze principai. Naujoji technologija vadinama „Valdoma programa“. Labiausiai apdoroti formų kūrimo mechanizmai ir sąveikos diagrama tarp 1C serverio vartotojo ir duomenų bazės. Platforma vis dar palaiko įprastą režimą, tačiau laikui bėgant visi 1C vartotojai pereis prie valdomų formų.

Paprastiems vartotojams tvarkoma 1C dokumento forma nuo įprastos skiriasi tik išvaizda. Kūrėjui tai naujas mechanizmas su savo taisyklėmis, įstatymais ir sąlygomis. Daugelis sričių pasikeitė, tačiau šios naujovės laikomos pagrindinėmis tarp patyrusių 1C kūrėjų:

  • Nepriklausomas formos struktūros formavimas ir laukų išdėstymas prie platformos. Jei anksčiau kūrėjai lauko padėtį apibūdindavo nurodydami pikselius, tai dabar galima nurodyti tik grupavimo tipą;
  • Formą sudaro detalės, reprezentuojančios formos duomenis, ir komandos – atliekamos procedūros ir funkcijos;
  • Formos kodas vykdomas tiek serverio, tiek kliento pusėse. Juk pati forma yra konfigūracijos objektas, sukurtas serveryje ir rodomas kliente. Tai reiškia, kad jis sujungia kliento ir serverio dalis;
  • Kliento pusėje daugelio tipų duomenys tapo nepasiekiami ir nebeįmanoma keisti duomenų informacinėje bazėje;
  • Kiekvienai procedūrai ar funkcijai turi būti nurodytas specialus nustatymas – kompiliavimo direktyva. Jis yra atsakingas už tai, kur vykdomas kodas, ir gali turėti šias reikšmes:
    • Naklientas;
    • Serveryje;
    • OnServerWithoutContext;
    • OnClientOnServer;
    • Kliente serveryje be konteksto.

Paskutinis punktas ypač aktualus valdomų formų režimu. Jei kūrėjas mažai supranta direktyvas ar kliento ir serverio sąveiką, jam bus labai sunku sukurti valdomą formą. Visus naujus valdomų formų kūrimo principus 1C:Enterprise 8.3 vienija bendra trijų pakopų architektūros koncepcija. Tai apima klientų kompiuterius, 1C serverį ir DBVS, kurioje saugomi duomenys.

Valdomos formos redagavimas konfigūravimo priemonėje taip pat tapo kitoks. Pasikeitė daug aspektų ir 7.7 versijos, kuri neturėjo valdomų formų, kūrėjai gali nustebti. Pasikeitė net formų dizainerio išvaizda, kurią galima pamatyti atidarius bet kurią konfigūracijos objekto formą. Atidarydami objektą matome langą, suskirstytą į kelias dalis:

  1. Formos sąsajos elementai. Viršuje kairėje yra langas, kuriame surašyti visi pasirinktoje formoje rodomi laukai, užtikrinantys programos sąveiką su vartotoju;
  2. Išsami informacija apie formą. Viršuje dešinėje yra visi duomenys, su kuriais veikia forma. Juose informacija saugoma kliento pusėje;
  3. Rodyti valdomą formą. Žemiau matome preliminarų vaizdą, pagrįstą sąsajos elementais;
  4. Formos modulis. Skyrius, kuriame yra šios formos naudojamos procedūros ir funkcijos. Čia galite rasti programos sąveikos su vartotoju ir duomenų baze algoritmų kodą.

1C kūrėjai skatina klientus pereiti prie valdomų formų, todėl išmokti valdomų formų kūrimo principų yra laiko klausimas. Pradėję dirbti su tokio tipo formomis suprasite, kad tai žingsnis standartizuojant kūrimą ir laikantis vienodų taisyklių. Todėl galimybė dirbti su valdomomis formomis 1C 8.3 padidina jūsų, kaip 1C kūrėjo, lygį.

Tvarkomų formų projektavimo principai

Visų pirma, norėdami suprasti 1C valdomo režimo mechanizmą, turėtumėte atsiminti, kad forma egzistuoja ir serveryje, ir kliente. Be to, kliente šis objektas yra tik vartotojo sąveikos su programa sąsajos vaizdas. Visi skaičiavimai, algoritmai, skaičiavimai ir apdorojimas turi būti atliekami tik serverio pusėje. Tai lemia ne tik nesugebėjimas naudoti daugelio klientų funkcijų ir parametrų, bet ir našumo reikalavimai.

Galite išsiaiškinti, kur procedūra vykdoma pagal direktyvos pavadinimą, kuris turi būti parašytas prieš kiekvieną procedūrą ir funkciją formos modulyje. Formuluotė „No Context“ rodo, kad valdomos formos duomenys nebus perduoti šiai procedūrai serveryje. Taigi atliekant tokias procedūras nebus galima rašyti algoritmų pagal vartotojo įvestas reikšmes. Jei ši formuluotė nenurodyta, forma perduodama visa su visa informacija, ir jūs galėsite jas pasiekti.

1C kūrėjai primygtinai rekomenduoja naudoti ne kontekstinius serverio skambučius, kiek įmanoma sumažinti jų skaičių ir stengtis neatlikti kliento skaičiavimų. Pradedantiesiems kūrėjams, neturintiems teorinio išsilavinimo, sunku laikytis visų šių taisyklių ir teisingai pakeisti kodą. Prieš pradedant dirbti savarankiškai, bus naudinga atidaryti valdomos konfigūracijos formą ir peržiūrėti sintaksę bei kliento ir serverio sąveiką.

&Tarnybinėje procedūroje gauti mokėjimo atsiskaitymo dokumentus iš saugyklos (naujas adresas saugykloje) &Serveryje be konteksto funkcija yra skaičiavimai su klientu (dokumento pagrindu) &Serveryje be konteksto procedūros Užpildykite kontrolinio taško pasirinkimo sąrašą (pasirinkimo sąrašas, sandorio šalis, Informacijos data) & Apie kliento procedūrą Užpildykite pagrindinį sandorio šalies užbaigimą (pasirinkta vertė, papildomi parametrai) &dėl serverio procedūros Mokėjimo ir atsiskaitymo dokumentų teksto rinkinio() &dėl serverio funkcijos IsFilledInitialDocuments()

Naujos 1C formų kūrimo taisyklės bus labai naudingos, jei jų laikysis visi kūrėjai. Be to, pokyčius į gerąją pusę pajus visi – programuotojai, 1C dirbančios įmonės, franšizės gavėjai ir 1C kūrėjai. Pagrindinės tinkamo valdomų formų naudojimo 1C pasekmės:

  1. Lengva konfigūracijos priežiūra ir geresnis kodo skaitomumas. Iš to galime daryti išvadą, kad vieno kūrėjo parašytas algoritmas visada gali būti pataisytas kito darbuotojo nesugaišdamas daug laiko;
  2. Kliente ir serveryje veikiančio kodo atskyrimas. Atsižvelgiant į tai, kiek skirtingos funkcijos yra kiekvienoje iš šių pusių, būtų teisingas jų atskyrimas;
  3. Kūrėjai geriau supras platformos logiką, kliento ir serverio sąveiką bei jų rašomus algoritmus. 8.0 ir ankstesnėse versijose buvo labai įprasta rasti dokumentų ar žinynų formų, sukurtų nesuvokiant kliento-serverio dalies;
  4. Konfigūracijų našumo didinimas ir klientų kompiuterių apkrovos mažinimas;
  5. Sumažėjusios išlaidos kompiuteriams darbo vietoms įsigyti, nes nereikia pirkti galingų kompiuterių.

Pasirinkus valdomą formą kaip pagrindinį 1C paleidimo režimą, gali būti daug netikėtumų. Tačiau laikantis teisingo požiūrio šis žingsnis atneš didelių dividendų, todėl vis daugiau 1C vartotojų visoje Rusijoje ryžtasi jo imtis. Atsižvelgiant į tai, kad 1C įmonė tikisi ateityje plėtoti valdomas formas, rizikinga likti prie pasenusių įprastų.

Gera diena.

Čia yra sąrašas, ką galite gauti čia:

  1. Lentelinę dokumento dalį rodo kaip medį ir konvertuoja atgal į lentelės dalį.
  2. Darbas su sąlyginiu formatavimu ir jo programinis naudojimas.
  3. Dinamiškas formos detalių kompozicijos pokytis
  4. Patogi sąsaja medžiui redaguoti

O dabar štai pirminiai sprendžiamos problemos duomenys:

Kalbėsime apie kažko statybos sąmatas. Yra darbų rūšių (toliau – tiesiog darbai) ir medžiagų katalogas. Yra medžiagų sunaudojimo norma vienam darbo vienetui. Būtina parengti dokumentą, kuriame vartotojas kiekvienam darbui galėtų nurodyti medžiagų sąrašą tiek, kiek reikia atlikti tam tikram šio darbo kiekiui kiekviename pastato aukšte (iš tikrųjų kartais tai nėra aukštas). , bet patalpa, sekcija,... ko tik nori, kad galima išardyti statomą objektą).

Tie. Turime tokią lentelinės dokumento dalies struktūrą:

grindų – dar neaišku, kas tai yra

darbų apimtis - numeris 15.3

medžiagų kiekis - numeris 15.3

Atrodo paprasta, bet praktiškai gauname daug pasikartojančios informacijos. Pavyzdžiui, turime du darbus, kiekviename iš 10 medžiagų ir 9 aukštus. Tai bus 180 eilučių dokumente, kuriame stulpelis „darbas“ beveik visur yra vienodas, kiekviena medžiaga kartojama 9 kartus.

Žemiau pateikiami du tos pačios informacijos atvaizdai. 1 – tiesiškai, 2 – medžio pavidalu su dinaminių kiekių stulpeliais. Aiškumo dėlei skirtingus duomenis paryškinau spalvomis: raudona - darbas, mėlyna - medžiaga, grindys - alyvinė, žalia - darbų apimtis, oranžinė - kaina, juoda - medžiagų kiekis.

Antrasis variantas aiškiai taupo vietą ekrane. Pirmajame turime 150 celių su informacija, antrame – 52. Be to, kuo daugiau grindų ir medžiagų, tuo daugiau sutaupoma.

Tai antras variantas, kurį įgyvendinsime šioje pamokoje.

Taigi atidarykite konfigūratorių. Manau, kad jūs pats galite nubrėžti duomenų struktūrą iš dviejų katalogų, dokumento ir informacijos registro. Todėl pasakojimą pradėsiu nuo to momento, kai jau turėsime kažką panašaus:

  • Katalogas "Darbai"
  • Katalogas "Medžiagos" (arba nomenklatūra - nesvarbu)
  • Dokumentas "..." (galite jį pavadinti "Sąmata" ar kaip kitaip)
  • Informacijos registras, periodinis, kuriame matavimai: darbas, medžiaga; išteklius: išlaidų sąskaita (galite sukurti jai registratorių, galite palikti tiesioginį redagavimą)

Pirmiausia turite nuspręsti dėl lentelės dalies konvertavimo į medį metodo. Pirmasis (paprasčiausias) yra naudoti užklausą darbo lauko sumoms sudaryti. Neigiama yra tai, kad prie lentelės dalies negalime pridėti dviejų identiškų kūrinių su skirtingomis medžiagų kompozicijomis, nes darbas bus pagrindinė sritis. Mūsų darbas bus sujungtas į vieną medžio mazgą, o jame esančios medžiagos bus sujungtos. Antrasis būdas yra pridėti rakto lauką, kuris nustatys, ar eilutės priklauso tam pačiam mazgui.

Man labiau erzina antrasis metodas, jis prideda prie dokumento papildomų detalių, tačiau kodas tampa skaidrus, suprantamas ir patikimas. Mes naudosime numerį kaip raktą. Pridėkime darbo numerio ir medžiagos numerio laukus.

Čia mums trūksta trečios analitikos – grindų. Mūsų atveju tai bus teigiamas sveikasis skaičius. Patogumui antraštėje pridėsime lauką „Aukštų skaičius“. Ši sritis labai supaprastins mūsų gyvenimą. Manome, kad atvejis, kai lentelės dalyje yra aukštas Nr. 9, o maksimalus aukštų skaičius yra 8, šių eilučių nebus.

Kitas žingsnis – pašalinti laukelį „Darbo kiekis“ ir palikti tik kiekį. Eilutėse, kur MaterialNumberInWork = 0, kiekį laikysime darbo apimtimi.

Štai viskas su struktūra, eikime į formą. Sukurkime numatytąją formą, kurioje patalpinsime viską, ką turime.

Pirma, mes padarysime numerį ir datą vienoje eilutėje, šis veiksmas visada turėtų būti atliekamas automatiškai, tai tarsi kopėčios kode.

Tada nubrėžkite formos atributą „Darbo medis“ su vertės tipu „Verčių medis“. Pridėkime prie jo stulpelius: Number, WorkMaterial, Expense, This isWork. Tarp elementų sukursime du puslapius: paslaugų puslapį, kuriame atsiųsime tikrąją lentelės dalį ir medį, į kurį atsiųsime medį. Rodysime visus medžio stulpelius, išskyrus žymimąjį laukelį „Tai darbas“.

Dabar pereikime prie kodo. Mums reikės procedūros, kuri nubrėžtų stulpelius su kiekiais pagal aukštų skaičių. Pavadinkime tai „UpdateColumnComposition ()“. Jame dinamiškai kursime/ištrinsime formos detales ir formos elementus. Ši procedūra bus iškviesta sukūrus formą ir pasikeitus aukštų skaičiui. Tie. Kai iškviečiame procedūrą, kai kuriuos stulpelius jau galime turėti ir turime juos palikti, kad neprarastume duomenų.

Štai jo sintaksė:

&Serveryje
Procedūros atnaujinimasStulpelio sudėtis()
//1. Formos peržiūros redagavimas, stulpelių įtraukimas į medį
medis = FormAttributesValue("Darbo medis");
mCUremove = naujas masyvas;
MaxColumnNumber = 0;
Kiekvienam stulpeliui iš medžio
Jei Lev(Stulpelio pavadinimas, 3) = "Skaičiavimas", tada
KiekisSkaičius = skaičius(vid.(Stulpelio.Pavadinimas,4));
Jei QuantityNumber>Object.NumberofFloors Tada
mCUpašalinti.Pridėti(Stulpelis);
endIf;
Jei QuantityNumber>MaxColumnNumber Tada
MaxColumnNumber = KiekisNumber;
endIf;
endIf;
EndCycle;
//2.
Išsami trynimo informacija = naujas masyvas;
Kiekvienam elementuiMKUremove iš MKUremove ciklo
Išsami informacija trynimui.Add("Darbo medis." + elementas MK, skirtas ištrinti.Vardas);
//formos elementas turi būti sugadintas prieš rekvizitus
Elements.Delete(Elements["Darbo medis" + MKUdelete element.Name])
EndCycle;
//3.
DetailsToAdd = naujas masyvas;


NewFormAttributes = NewFormAttributes("Skaičius"+Naujas skaičius, NewTypeDescription("Skaičius", NaujasSkaičiusKvalifikatoriai(15,3)), "Darbų medis", "į "+Naujas skaičius);
Išsami informacijaPridėti.Pridėti(NewFormAttributes);
EndCycle;
//4.
ChangeDetails(DetailsToAdd,DetailsToDelete);
//5. Nubraižome naujus formos elementus, juos reikia pridėti sukūrus atributus
Jei w = 1 pagal objektą, aukštų skaičius – maksimalus stulpelių skaičius
NaujasSkaičius = MaxColumnNumber + w;
NewColumn = Elements.Add("Darbo medžioSkaičius"+NaujasSkaičius, Tipas("Formos laukas"), Elements.WorkTree);
NewColumn.View = FormFieldView.InputField;
NewColumn.DataPath = "TreeWork.Number"+Naujas skaičius;
Naujas stulpelis. Plotis = 7;
NewColumn.SetAction("OnChange", "QuantityOnChange");
NewColumn.Header = "į" + w;
EndCycle;
Procedūros pabaiga

Papasakokime apie jo darbo etapus:

1. Einame per visus medžio stulpelius, kad sužinotume, kiek jų jau turime. Čia mes nustatome jo numerį pagal stulpelio pavadinimą ir, jei jis didesnis nei reikiamas kiekis, įtraukiame į sąrašą, kad būtų pašalintas. Taip pat randame maksimalų esamo stulpelio skaičių. (dirbame su formos detalėmis!!!)

2. Konvertuokite stulpelių, kuriuos norite ištrinti, sąrašą į eilučių su duomenų pavadinimais sąrašą. Viena vertus, iš karto sunaikiname formos elementus, nes... Negalite ištrinti formoje rodomų atributų.

3. Sukurkite stulpelių, kuriuos reikia sukurti, sąrašą.

4. Iškvieskite įmontuotą procedūrą Change Details, po kurios nebeturime papildomų stulpelių ir atsirado trūkstami.

Tiesą sakant, šioje procedūroje matėme, kaip teisingai dinamiškai nupiešti formos detales ir formos elementus. Iš svarbių niuansų:

-negalite ištrinti informacijos, kuri nebuvo sukurta programiškai

-negalite ištrinti informacijos, naudojamos formos elementuose

Išsaugoję ir paleidę įmonę pamatysime, kad atidarius esamą dokumentą iš karto nubraižomas reikiamas stulpelių skaičius, o pasikeitus aukštų skaičiui – viskas iš karto dinamiškai perbraižoma.

Dabar parašykime lentelės konvertavimo į medį procedūrą. Norėdami atlikti testą, dokumente užpildykite lentelės dalį, kaip parodyta paveikslėlyje:

Šiuo tikslu formoje palikome tikrą skirtuko dalį, kad galėtume derinti ir patikrinti rezultatą.

&Serveryje
Procedūra TabPartInTree()
Medis = FormAttributesValue("Darbo medis");
Medis.Eilutės.Išvalyti();
lineWork = "";
Darbo numeris = "";
Medžiagos numeris = "";
Object.TabularPart1.Sort("Darbo numeris,MaterialNumberInDarba");
Kiekvienam Select From Object.TabularPart1 Loop
//Kontroliuokite aukštų skaičių
Floor = Select.Floor;
Jei Aukštas > Objektas.Aukštų skaičius Tada
Tęsti;
endIf;
Jei Aukštas = 0 Tada
Tęsti;
endIf;
Jei darbo numeris<>Tada pasirinkite darbo numerį
rowWorks = Medis.Lines.Add();
lineDarbas.Number = SelectDarbasNumber;
lineWork.WorkMaterial = Select.Work;
stringJob.ThisJob = Tiesa;
//sekantis darbas prasidėjo, pradėsime skaičiuoti medžiagas nuo pradžių
Medžiagos numeris = "";
JobNumber = Pasirinkite DarboNumber;
endIf;
Jei SelectedMaterialNumberInJob = 0, tai//tai yra darbo eilutė
lineWork["Kiekis"+Grindys] = Pasirinkite.Kiekis;
Kitu atveju // tai eilutė su medžiaga
Jei medžiagos numeris<>Tada darbe pasirinkite medžiagos numerį
stringMaterial = stringWork.Strings.Add();
stringMaterial.Number = Select.MaterialNumberInDarbas;
stringMaterial.WorkMaterial = Select.Material;
lineMaterial.KConsumption = Select.KConsumption;
stringMaterial.ThisWork = False;
MaterialNumber=PasirinktaMaterialNumberInJob;
endIf;
lineMaterial["Kiekis"+Grindys] = Pasirinkite.Kiekis;
endIf;
EndCycle;
ValueВFormProps(Medis,"Darbo medis");
Procedūros pabaiga

Nėra čia ką daug komentuoti. Naudodamas laukus „Darbo numeris“ ir „Material NumberInDarbas“ nustatau, kad turime eilutę su darbu arba medžiaga, atitinkamai, pridedu eilutę prie šaknies arba prie darbo. Jei pasikeitė tik grindys, imame tik kiekį. Papildomos grindys nupjaunamos, trūkstamos grindys nesugadins medžio struktūros.

Šią procedūrą vadiname kurdami ją serveryje po „UpdateColumnComposition()“.

Dabar galite tai išbandyti paleisdami įmonę ir atidarę anksčiau sukurtą dokumentą.

Dabar prieš rašydami dokumentą turime padaryti priešingai, išsaugodami medį lentelės skyriuje. Mes rašome procedūrą:

&OnClient
Procedūra PlaceTreeВTabPart()
Objektas.Medžiagos.Išvalyti();
Kiekvienam puslapio darbui iš TreeWork.GetElements() Loop


p.Grindys = w;
str.Kiekis = strWork["Kiekis"+w];
EndCycle;
Kiekvienam puslapio medžiagai iš PageWork.GetElements() ciklo
Jei w = 1 pagal objektą, ciklas
str = Objektas.Medžiagos.Pridėti();
p.Darbo numeris = p.Darbo numeris;
p.MaterialNumberInWork = p.Material.Number;
p.Darbas = str.Darbas.Darbinė medžiaga;
str.Medžiaga = strMaterial.WorkMaterial;
str.KConsumption = str.Medžiaga.KVartojimas;
p.Grindys = w;
str.Kiekis = strMedžiaga["Kiekis"+f];
EndCycle;
EndCycle;
EndCycle;
Procedūros pabaiga

Sąlyginis formos dizainas 1C 8 naudojamas valdomos formos lentelės elementų matomumui, pasiekiamumui ir spalvoms valdyti (taip pat naudojamas ACS ir dinaminiuose sąrašuose). Naudojimosi patogumas slypi tame, kad vieną kartą nustatėte sąlygą, pagal kurią jūsų formos dizainas turėtų pasikeisti. Po to, kai vartotojas dirba su forma, suaktyvinus sąlygą, dizainas pasikeis automatiškai. Nereikia naudoti formos įvykių ir rašyti nereikalingo kodo.

Reikėtų pakeisti, kad sąlyginės formos dizainas veiktų tik konfigūracijose, kuriose naudojama valdoma programa (Accounting 3.0, ZUP 3.0/3.1, Trade Management 11 ir kt.)

Sąlyginis dizainas 1s. Interaktyvi sąranka

Kitas sąlyginio stiliaus privalumas yra tai, kad galite jį tinkinti neįrašydami nė vienos kodo eilutės. Norėdami tai padaryti, formoje reikia:

  • Atidaryti formos ypatybes -> išvaizda skirtuką -> Sąlyginė išvaizda Atidaryti;
  • Atsidarys stalas ;
  • Pirmame stulpelyje turite pasirinkti dizainą (arba kelis iš karto);
  • Antrame stulpelyje nustatykite sąlygą, kuriai esant pasirinktas dizainas bus suaktyvintas;
  • Trečiame stulpelyje turite pasirinkti formos elementus, kuriuos paveiks pasirinktas dizainas.

Atminkite, kad sąlyginis stilius veikia tik formos lentelės stulpelius. Stulpelyje taip pat galite pasirinkti kitus formos elementus Suformatuoti laukai, bet tai neduos jokio rezultato.

Sąlyginės formos dizainas. Interaktyvios sąrankos pavyzdys

Kaip pavyzdį parašiau paprastą apdorojimą, kurio formose buvo pridėtas atributas su tipu Vertybių lentelė, su trimis stulpeliais. Taip pat trys detalės su tipu loginis. Galite atsisiųsti apdorojimą.

Apdorojimo forma atrodo taip:

Nustatykime tokį šios formos sąlyginį dizainą: nustatydami detales Slėpti 1 stulpelį prasme Tiesa, paslėpti išsamią informaciją formos lentelėje 1 stulpelis.

  • Atidarykite sąlyginės formos parametrų nustatymus;
  • Pridėkime prie lentelės naują eilutę;
  • Stulpelyje Dekoras Spustelėkite mygtuką su trimis taškais ir pasirinkite parinktį Matomumas, prasmė Nr;

  • Stulpelyje Būklė Spustelėkite mygtuką su trimis taškais ir atsidariusiame lange pridėkite naują pasirinkimą. Įveskime ten šias reikšmes: Kairioji reikšmė – Slėpti stulpelį1, Palyginimo tipas – Lygus, Dešinė reikšmė – Taip;

  • Stulpelyje Suformatuoti laukai spustelėkite mygtuką su trimis taškais, atsidariusiame lange pridėkite naują elementą ir pasirinkite reikšmę TableShapesColumn1;
  • Dėl to turėtume turėti sąlyginį išvaizdos nustatymą, panašų į esantį toliau pateiktame paveikslėlyje;

  • Paspauskite mygtuką Gerai, išsaugokite apdorojimą ir paleiskite jį režimu 1C įmonė;
  • Pažymėdami langelį Slėpti 1 stulpelį, formos dizaine įvyks šie pakeitimai.


Sąlyginė registracija 8.3. Programinės įrangos konfigūracijos pavyzdys

Naudodami tą patį išorinį apdorojimą, kaip ir ankstesnėje pastraipoje, pateiksime programinio sąlyginės išvaizdos nustatymo pavyzdį. Turite atlikti šiuos veiksmus: montuodami rekvizitus Keisti spalvasStulpelius2 prasme Tiesa, lentelės formoje nuspalvinkite foną 2 stulpeliai, nustatant rekvizitus Padaryti 3 stulpelį nepasiekiamą prasme Tiesa, padaryti nepasiekiamą formų lentelėje rekvizitai 3 stulpelis.

Formos modulyje sukurkime serverio procedūrą ir ją iškvieskime Nustatyti sąlyginę išvaizdą ir nedelsdami pridėkite savo kvietimą prie procedūros Kai CreatedOnServer.

&OnServerProcedureCreatingOnServer(gedimas, standartinis apdorojimas) SetConditionalDesign(); Procedūros pabaiga &Serveryje procedūrų rinkinio sąlyginė išvaizda() Procedūros pabaiga

Mes parašysime visą šį kodą procedūros metu Nustatyti sąlyginę išvaizdą. Turime pridėti naują sąlyginės formos elementą, tam naudojame standartinę formų rinkinį Sąlyginis formavimas.

Element = Sąlyginis dizainas.Elementai.Pridėti();

Kaip ir interaktyvioje versijoje, sukurtame elemente turime užpildyti dizainą, sąlygas ir laukus. Norėdami nurodyti lauką, turime sukurti duomenų sudėties lauką su stulpelio, kuriam bus pritaikytas dizainas, pavadinimu. Jei yra keli laukai, pridėkite reikiamą duomenų sudėties laukų skaičių. Pasirinkimams sukuriame duomenų sudėties atrankos elementus ir užpildome jiems kairiąją reikšmę, dešinę reikšmę ir palyginimo tipą. Norėdami nustatyti reikiamus dizainus, užpildykite turimų dizainų parametrus. Mūsų pavyzdys sukuria šį kodą:

Element = Sąlyginis dizainas.Elementai.Pridėti(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NaujiDuomenų sudėtieslaukas(Elementai.Formos lentelėstulpelis2.Pavadinimas); Element Selection = Element.Selection.Elements.Add(Type("DataComposition Selection Element")); Elemento pasirinkimas.LeftValue = NewDataCompositionField("ChangeColumnColor2"); Elemento pasirinkimas.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = True; Element.Design.SetParameterValue("BackgroundColor", NewColor(255, 0, 0));

Taigi sukūrėme antrojo lentelės stulpelio dizainą. Trečiojo stulpelio atveju tai daroma panašiai, todėl mes apie tai nesigilinsime. Galutinis procedūros kodas Nustatyti sąlyginę išvaizdą atrodys taip:

&Serverio procedūroje SetConditionalAppearance() Element = ConditionalAppearance.Elements.Add(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NaujiDuomenų sudėtieslaukas(Elementai.Formos lentelėstulpelis2.Pavadinimas); Element Selection = Element.Selection.Elements.Add(Type("DataComposition Selection Element")); Elemento pasirinkimas.LeftValue = NewDataCompositionField("ChangeColumnColor2"); Elemento pasirinkimas.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = True; Element.Design.SetParameterValue("BackgroundColor", NewColor(255, 0, 0)); Element = Sąlyginis dizainas.Elementai.Pridėti(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn3.Name); Element Selection = Element.Selection.Elements.Add(Type("DataComposition Selection Element")); ElementSelection.LeftValue = New DataCompositionField("Padaryti 3 stulpelį nepasiekiamą"); Elemento pasirinkimas.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = True; Element.Design.SetParameterValue("Prieinamumas", False); Procedūros pabaiga

Leiskite jums priminti, kad galite atsisiųsti apdorojimą, parašytą remiantis analizuotais pavyzdžiais.

Formos 1C: Enterprise yra skirtos duomenų bazėje esančiai informacijai rodyti ir redaguoti. Formos gali priklausyti konkretiems konfigūracijos objektams arba egzistuoti atskirai nuo jų ir jas naudoja visas programos sprendimas.

Pavyzdžiui, katalogas Nomenklatūra gali turėti keletą formų, kurios bus naudojamos konkretiems tikslams – redaguoti katalogo elementą, rodyti sąrašą ir pan.:

Kartu su tuo gali būti bendrųjų formų, kurios nepriklauso konkretiems konfigūracijos objektams – bendrosios formos.

Pagrindinės formos

Kiekvienas konfigūracijos objektas gali būti naudojamas kai kuriems standartiniams veiksmams atlikti. Pavyzdžiui, bet kuriame kataloge gali tekti rodyti jo elementų sąrašą, atskirus katalogo elementus, rodyti katalogo grupę, pasirinkti elementus ir elementų grupes iš katalogo. Bet kuriam dokumentui tokių veiksmų sąrašas bus daug mažesnis: dokumentų sąrašo peržiūra, pasirinkimas iš dokumentų sąrašo ir atskiro dokumento peržiūra.

Siekiant užtikrinti, kad tokie standartiniai veiksmai būtų atliekami su taikomųjų programų sprendimų objektų duomenimis, kiekvienam iš jų yra aibė pagrindinių formų, kurios bus naudojamos atliekant atitinkamus veiksmus. Bet kuri iš šiam objektui pavaldžių formų gali būti priskirta kaip pagrindinė. Pavyzdžiui, kataloge Nomenklatūra Gali būti šios pagrindinės formos:

Ir dokumentas Prekių ir paslaugų gavimas pagrindinių formų sudėtis skirsis:

Taigi, jei vartotojas nori peržiūrėti katalogų sąrašą Nomenklatūra arba dokumentų sąrašas Prekių ir paslaugų gavimas, sistema atidarys atitinkamą formą, nurodytą kaip šių objektų sąrašo forma.

Automatiškai generuojamos formos

Svarbi 1C:Enterprise 8 sistemos savybė yra automatiškai generuojamų formų mechanizmas. Šis mechanizmas atleidžia kūrėją nuo būtinybės kurti visas įmanomas kiekvieno konfigūracijos objekto formas. Kūrėjui tereikia pridėti naują konfigūracijos objektą, o pati sistema tinkamais vartotojo darbo momentais sugeneruos reikiamas formas, kad būtų rodoma šiame objekte esanti informacija.

Taigi kūrėjas turi kurti savo taikomųjų programų sprendimo objektų formas tik tuo atveju, jei jie turi skirtis (skirtingo dizaino ar specifinės elgsenos) nuo automatiškai generuojamų sistemos formų.

Formos susiejimas su duomenimis

Tai, ar forma priklauso tam tikram konfigūracijos objektui, nenustato formoje rodomų duomenų sudėties. Tai, kad forma priklauso, pavyzdžiui, katalogui Nomenklatūra, leidžia priskirti ją kaip vieną iš pagrindinių šio katalogo formų, tačiau jokiu būdu nenustato, kokius duomenis ši forma rodys ir koks jos elgesys.

Norint susieti formą su duomenimis, naudojami formos duomenys, kurie nurodo formoje rodomų duomenų sąrašą. Visos formos elgiasi taip pat, neatsižvelgiant į tai, kokius duomenis jos rodo. Tačiau vieną iš formos atributų jam galima priskirti kaip pagrindinį atributą (jis paryškintas pusjuodžiu šriftu), tokiu atveju standartinė formos elgsena ir jos savybės bus papildytos priklausomai nuo to, kokio tipo yra pagrindinis formos atributas:

Pavyzdžiui, jei dokumentas priskirtas kaip pagrindinis formos atributas Prekių ir paslaugų gavimas, tada uždarant formą sistema paprašys patvirtinti šio dokumento įrašymą ir paskelbimą. Jei priskirsite, tarkime, katalogą kaip pagrindinį formos reikalavimą Nomenklatūra, tada toks patvirtinimo prašymas nepasirodys uždarant formą.

Formos struktūra

Pagrindinis formų bruožas yra tai, kad kūrėjas jas nubraižo ne detaliai, „pikselis po pikselio“. Konfigūracijos forma yra logiškas formos sudėties aprašymas. O konkretų elementų išdėstymą sistema atlieka automatiškai, kai rodoma forma.

Rodoma formos dalis (matoma vartotojui) apibūdinama kaip medis su formos elementais.

Elementai gali būti įvesties laukai, žymės langeliai, radijo mygtukai, mygtukai ir kt. Be to, elementas gali būti grupė, apimanti kitus elementus. Grupė gali būti pavaizduota kaip skydelis su rėmeliu, skydelis su puslapiais (žymėmis), pats puslapis arba komandų skydelis. Be to, elementas gali būti lentelė, kurioje taip pat yra elementai (stulpeliai). Elementų struktūra apibūdina, kaip forma atrodys.

Visos formos funkcijos aprašytos detalių ir komandų pavidalu. Išsami informacija yra duomenys, su kuriais veikia forma, o komandos yra veiksmai, kuriuos reikia atlikti. Taigi kūrėjas formų rengyklėje turi įtraukti į formą reikiamas detales ir komandas, sukurti juos rodančius formos elementus ir, jei reikia, suskirstyti elementus į grupes.

Remdamasi šiuo loginiu aprašymu, sistema automatiškai sugeneruoja vartotojui rodomos formos išvaizdą. Tokiu atveju sistema atsižvelgia į įvairias rodomų duomenų savybes (pavyzdžiui, tipą), kad vartotojui būtų kuo patogiau išdėstyti formos elementus.

Kūrėjas gali paveikti elementų išdėstymą įvairiais parametrais. Jis gali nustatyti elementų tvarką, nurodyti norimą plotį ir aukštį. Tačiau tai tik papildoma informacija, padedanti sistemai rodyti formą.

Formose kūrėjas gali naudoti ne tik pačios formos komandas, bet ir globalias komandas, naudojamas visos konfigūracijos komandų sąsajoje. Be to, galima sukurti parametrizuojamas komandas, kurios atidarys kitas formas, atsižvelgiant į konkrečius esamos formos duomenis. Pavyzdžiui, tai gali būti ataskaitos apie likučius sandėlyje, kuris šiuo metu pasirinktas sąskaitos faktūros formoje, iškvietimas.

Pagrindinė problema yra ta, kad per 10–15 metų įprastoms formoms jau buvo sukurta daug kodų. Niekas nenori viso to perrašyti kliento serveryje + daug žmonių yra apmokyti dirbti su sąsaja. Nuo kitų metų prasidėjęs privalomas perėjimas prie BP 3.0 kelia paniką kūrėjų ir buhalterių galvose. Atsiliepimai bus labai nemalonūs. Be to, kyla kartelė stojant į profesiją, sunkiau programuoti, o standartiniai – dar sunkesni. Kiek kainuoja naujasis algoritmas standartiniuose dokumentuose? UV puikiai atrodo, kai ant dokumentų yra 2-3 mygtukai, UV puikiai tinka darbui mobiliuosiuose įrenginiuose, tačiau juo naudojasi tik 0,01 % įmonių. Turėsite persijungti, jei 1C nesugalvos kažko naujo, bet tai bus ilga ir visiems skausminga. O pinigus turės sumokėti pačios įmonės.

Aš irgi iš kontroliuojamų formų kol kas patyriau tik neigiamus dalykus, čia dar keli naujovės trūkumai:

  • Nieko? Na, aš su tuo susidūriau porą kartų, pavyzdžiui, parašydamas ir pridėdamas išorinę spausdinimo formą prie ZUP conf, apdorojimas yra visas epas, pilnas instrukcijų internete ir kodo puslapiuose.
    ant storo kliento yra viena procedūra su parametrais t.y. plėtra yra kelių minučių reikalas.
    o stabdžiai ploni matomi plika akimi
  • Kalbant apie galimybę paruošti valdomas formas – tai menas meno labui, bet kokia praktinė prasmė, ypač failo versijai?
  • 3 metus lipdžiau UV, bet dabar grįžau prie paprastų formų, ir patikėkite manimi, šis perėjimas buvo psichologiškai gana sunkus, bet tai yra mano sąmoningas pasirinkimas, nes tai, ką siūlo 1c UV, yra visiškai UG…. gal po poros metu 1c padarys proveržį, bet dabar ji tik ieško vietos, kur tą proveržį padaryti...
  • UV spinduliai konfigūratoriuje atidaromi daug ilgiau.
    Po to formų atidarymas 8.1 prilygsta perkėlimui iš sunkvežimio į lėktuvą!
  • Visiems daugiau problemų, vartotojus šokiruoja nauja sąsaja (ne visi tai pripažįsta, bet jie daug kvailesni dėl smulkmenų), pusė programuotojų tapo netinkami profesionalumui, paprastam specialistui tapo sunkiau. susirasti darbą ir kaip pagaminti kokybišką produktą. Ir pati šauniausia UV rinkodaros tema yra ta, kad jie sklando visur, kai perėjimas įvyksta su paprastu atnaujinimu, bet visi pamiršta, kad nuo pat pradžių reikia pasivyti naujausius leidimus! Bet iš principo idėja man patinka!
  • Nežinau, mano patirtis rodo priešingai. Ten, kur griežtų formų bumai jau keletą metų trenkia automatiškai, naujuose UV standartuose kas mėnesį prasideda „kodėl, kur dabar yra 1C atnaujinus šį mygtuką ir kodėl dabar jis neveikia“, o tai, matote, , greičio neprideda.
  • - Yra daugiau kodų
    - kodas tapo sudėtingesnis
    — standartinių modifikavimas yra daug sunkesnis
    - vartotojai, kuriems daviau UT11, nerado jokių pranašumų lyginant su 10.x
    - tačiau jie rado tam tikrų sulėtėjimų ir kai kurių funkcijų, pvz., paieškos, trūkumo (kažkodėl jie norėjo paieškos pirmyn atgal, o ne pasirinkimo)
    Mano nuomone, aukos per didelės dėl interneto kliento ir planšetinių kompiuterių. Be to, aš asmeniškai dar nemačiau realaus darbo su interneto klientu, kuriam reikia sėkmingai naudotis nuotoline prieiga
  • „Client-server bedlam“ turėtų padidinti našumą ir mastelį, o tuo pačiu metu išlaidos apima kodavimo padidėjimą.
    Tačiau ne visi patyrė padidėjimą, todėl nusivylimas. Ir tuo pačiu metu visi buvo linkę į kodavimo išlaidas.
    P.S. Tiesą sakant, man patinka valdomi, ramiai piešiu ant jų. Tačiau tipiški tapo iškrypę.
  • Namų kompiuteryje (įprastame kompiuteryje) gėriau pagal individualius verslininkus.
    8.3, BP3, languotas. Pagrindinis įspūdis, kad aš nedirbu, o visą laiką laukiu. hemoroidinis atsakas. DRUSKA sąskaitai formuojama velniškai paprasta – atrodo, kaip metų sąskaitos kortelė megaholikoje.
  • UT11 yra laukinis stabdis, siaubas ir apskritai košmaras.
    UT10 skrenda, palyginti su UT11.
    Dėl UV - blakės buvo užkrėstos metų metus, viskas kreivai, stulpeliai niekada netelpa viename ekrane, tempimas daugeliu atvejų baisus.
    Ir dar galiu išvardinti daug minusų, bet apie pliusus turbūt nieko nesakysiu. Jų tiesiog nėra.
    Firmos specialiai atsidūrė tokiomis formomis, nes plėtra kainuoja brangiau, specialių nebuvo ir normalių nėra.

Privalumų yra nedaug, bet, žinoma, jų yra...

privalumus:

Atsakymas buvo jau seniai, ką davė UP:

kelių platformų klientas

  • dirba blogomis ryšio linijomis
  • galimybė dirbti per naršyklę (neįdiegus kliento)