Me versionin 8.2 të platformës në 1C, filluan të përdoren parime të reja për ndërtimin e ndërfaqes dhe ndërveprimin e përdoruesit me bazën e të dhënave. Teknologjia e re quhet "Aplikacion i menaxhuar". Mekanizmat për ndërtimin e formave dhe skema e ndërveprimit midis përdoruesit të serverit 1C dhe bazës së të dhënave kanë pësuar përpunimin më të madh. Modaliteti normal mbështetet ende nga platforma, por me kalimin e kohës të gjithë përdoruesit e 1C do të kalojnë në format e menaxhuara.

Për përdoruesit e zakonshëm, forma e menaxhuar e një dokumenti 1C ndryshon nga ajo e zakonshme vetëm në pamje. Për zhvilluesin, ky është një mekanizëm i ri me rregullat, ligjet dhe kushtet e veta. Shumë fusha kanë pësuar ndryshime, por risitë e mëposhtme konsiderohen kryesore në mesin e zhvilluesve me përvojë të 1C:

  • Formimi i pavarur i strukturës së formës dhe vendosja e fushave nga platforma. Nëse zhvilluesit e mëparshëm përshkruanin pozicionin e një fushe duke specifikuar piksele, tani është e mundur vetëm të specifikohet lloji i grupimit;
  • Formulari përbëhet nga detaje që përfaqësojnë të dhënat e formularit, dhe komandat - procedurat dhe funksionet që duhen kryer;
  • Kodi i formës ekzekutohet si në anën e serverit ashtu edhe në anën e klientit. Në fund të fundit, forma në vetvete është një objekt konfigurimi i krijuar në server dhe shfaqet në klient. Kjo do të thotë se kombinon pjesët e klientit dhe serverit;
  • Nga ana e klientit, shumë lloje të dhënash janë bërë të padisponueshme dhe nuk është më e mundur të ndryshohen të dhënat në bazën e informacionit;
  • Për çdo procedurë ose funksion, duhet të specifikohet një cilësim i veçantë - një direktivë përpilimi. Ai është përgjegjës për vendin ku ekzekutohet kodi dhe mund të marrë vlerat e mëposhtme:
    • Naklient;
    • Në server;
    • OnServerWithoutContext;
    • OnClientOnServer;
    • Në klientin në server pa kontekst.

Pika e fundit është veçanërisht e mprehtë në modalitetin e formave të menaxhuara. Nëse një zhvillues ka pak njohuri për direktivat ose ndërveprimet klient-server, atëherë do të jetë jashtëzakonisht e vështirë për të që të krijojë një formë të menaxhuar. Të gjitha parimet e reja për ndërtimin e formave të menaxhuara në 1C: Enterprise 8.3 janë të bashkuara nga koncepti i përgjithshëm i një arkitekture me tre nivele. Ai përfshin kompjuterë klientë, një server 1C dhe një DBMS ku ruhen të dhënat.

Redaktimi i një formulari të menaxhuar në konfigurues është bërë gjithashtu i ndryshëm. Shumë aspekte kanë ndryshuar dhe zhvilluesit e versionit 7.7, të cilët nuk kishin forma të menaxhuara, mund të habiten. Edhe pamja e dizajnerit të formës ka ndryshuar, gjë që mund të shihet duke hapur ndonjë nga format e objektit të konfigurimit. Kur hapim një objekt, shohim një dritare të ndarë në disa seksione:

  1. Formoni elementet e ndërfaqes. Në pjesën e sipërme majtas është një dritare që liston të gjitha fushat e shfaqura në formularin e zgjedhur që sigurojnë ndërveprimin e programit me përdoruesin;
  2. Detajet e formularit. Në krye djathtas janë të gjitha të dhënat me të cilat funksionon formulari. Ato janë vendi ku ruhet informacioni në anën e klientit;
  3. Shfaq një formular të menaxhuar. Më poshtë shohim një vështrim paraprak bazuar në elementët e ndërfaqes;
  4. Moduli i formularit. Seksioni që përmban procedurat dhe funksionet e përdorura nga ky formular. Këtu mund të gjeni kodin për algoritmet për ndërveprimin e programit si me përdoruesin ashtu edhe me bazën e të dhënave.

Zhvilluesit e 1C po inkurajojnë klientët të kalojnë në format e menaxhuara, kështu që mësimi i parimeve të zhvillimit të formave të menaxhuara është çështje kohe. Pasi të filloni të punoni me këtë lloj formulari, do të kuptoni se ky është një hap drejt standardizimit të zhvillimit dhe ndjekjes së rregullave uniforme. Prandaj, aftësia për të punuar me format e menaxhuara në 1C 8.3 rrit nivelin tuaj si zhvillues 1C.

Parimet e dizajnit të formularëve të menaxhuar

Para së gjithash, për të kuptuar mekanizmin e modalitetit të menaxhuar 1C, duhet të mbani mend se formulari ekziston si në server ashtu edhe në klient. Për më tepër, në klient ky objekt është vetëm një imazh i ndërfaqes për ndërveprimin e përdoruesit me programin. Të gjitha llogaritjet, algoritmet, llogaritjet dhe përpunimi duhet të ndodhin vetëm në anën e serverit. Kjo diktohet jo vetëm nga pamundësia për të përdorur shumë funksione dhe parametra te klienti, por edhe nga kërkesat e performancës.

Ju mund të kuptoni se ku ekzekutohet procedura me emrin e direktivës, e cila duhet të shkruhet para secilës procedurë dhe të funksionojë në modulin e formularit. Formulimi "Pa kontekst" tregon se të dhënat në formularin e menaxhuar nuk do t'i kalojnë kësaj procedure në server. Kështu, në procedura të tilla nuk do të jetë e mundur të shkruhen algoritme bazuar në vlerat e futura nga përdoruesi. Nëse ky formulim nuk është i specifikuar, atëherë formulari transmetohet në tërësi me të gjitha detajet dhe ju do të keni mundësi t'i aksesoni ato.

Zhvilluesit e 1C rekomandojnë fuqimisht përdorimin e thirrjeve jokontekstuale të serverit, duke zvogëluar numrin e tyre sa më shumë që të jetë e mundur dhe duke u përpjekur të mos kryejnë llogaritjet tek klienti. Është e vështirë për zhvilluesit fillestarë pa trajnim teorik të respektojnë të gjitha këto rregulla dhe të ndryshojnë saktë kodin. Para se të filloni të punoni vetë, do të jetë e dobishme të hapni formularin e konfigurimit të menaxhuar dhe të shikoni sintaksën dhe mënyrën se si klienti dhe serveri ndërveprojnë.

&Në procedurën e serverit Merr dokumentet e shlyerjes së pagesës nga hapësira ruajtëse (Adresa e re në hapësirë ​​ruajtëse) &Në server pa kontekst Funksioni është llogaritjet me klientin (baza e dokumentit) &Në server pa procedurë kontekstuale Plotësoni listën e përzgjedhjes së pikës së kontrollit (Lista e përzgjedhjes, homologu, Data e informacionit) & mbi procedurën e klientit Për plotësimin e plotësimit të kundërpartisë së kreut (Vlera e zgjedhur, parametrat shtesë) &Në procedurën e serverit SetTeksti i dokumenteve të pagesës dhe shlyerjes() &Në funksionin e serverit IsFilledInitialDocuments()

Rregullat e reja për zhvillimin e formave 1C do të jenë me përfitim të madh nëse të gjithë zhvilluesit i përmbahen atyre. Për më tepër, të gjithë do t'i ndiejnë ndryshimet për mirë - programuesit, kompanitë që punojnë në 1C, ekskluzivitetet dhe zhvilluesit 1C. Pasojat kryesore të përdorimit të saktë të formave të menaxhuara në 1C:

  1. Lehtësia e mirëmbajtjes së konfigurimit dhe rritja e lexueshmërisë së kodit. Nga kjo mund të konkludojmë se një algoritëm i shkruar nga një zhvillues mund të korrigjohet gjithmonë nga një punonjës tjetër pa shpenzuar shumë kohë;
  2. Ndarja e kodit që funksionon në klient dhe server. Duke marrë parasysh se sa i ndryshëm është funksionaliteti i disponueshëm në secilën nga këto anë, ndarja e tyre do të ishte masa e duhur;
  3. Kuptimi më i thellë i zhvilluesve për logjikën e platformës, ndërveprimet klient-server dhe algoritmet që ata shkruajnë. Në versionet 8.0 dhe më herët, ishte shumë e zakonshme të gjeje forma dokumentesh ose libra referimi të zhvilluara pa kuptuar pjesën klient-server;
  4. Rritja e performancës së konfigurimeve dhe reduktimi i ngarkesës në kompjuterët e klientëve;
  5. Ulja e kostove për blerjen e kompjuterëve për vendet e punës për shkak të mungesës së nevojës për të blerë PC të fuqishëm.

Zgjedhja e një forme të menaxhuar si mënyra kryesore e nisjes 1C mund të paraqesë shumë surpriza. Por me qasjen e duhur, ky hap do të sjellë dividentë të mëdhenj, kjo është arsyeja pse gjithnjë e më shumë përdorues të 1C në të gjithë Rusinë po vendosin ta marrin atë. Duke marrë parasysh faktin se kompania 1C po mbështet në zhvillimin e formave të menaxhuara në të ardhmen, është e rrezikshme të qëndroni në ato konvencionale të vjetëruara.

Diten e mire.

Këtu është një listë e asaj që mund të merrni këtu:

  1. Shfaq pjesën tabelare të dokumentit si pemë dhe e kthen atë përsëri në pjesën tabelare.
  2. Puna me formatimin e kushtëzuar dhe përdorimi i tij programatik.
  3. Ndryshimi dinamik në përbërjen e detajeve të formës
  4. Ndërfaqe e përshtatshme për modifikimin e pemëve

Dhe tani këtu janë të dhënat fillestare të problemit që po zgjidhet:

Do të flasim për vlerësime për ndërtimin e diçkaje. Ekziston një drejtori e llojeve të punës (në tekstin e mëtejmë thjesht si punë) dhe materialeve. Ekziston një normë e konsumit të materialit për njësi të punës. Është e nevojshme të zhvillohet një dokument në të cilin përdoruesi mund të specifikojë për secilën punë një listë të materialeve në sasinë e nevojshme për të kryer një sasi të caktuar të kësaj pune në çdo kat të ndërtesës (në fakt, ndonjëherë ky nuk është fare kat , por nje dhome, nje seksion,... cfare te duash qe mund te prishesh nje objekt ne ndertim).

ato. Ne kemi strukturën e mëposhtme të pjesës tabelare të dokumentit:

dysheme - nuk është ende e qartë se çfarë është

fushëveprimi i punës - numri 15.3

sasia e materialeve - numri 15.3

Duket e thjeshtë, por në praktikë marrim shumë informacione të përsëritura. Për shembull, kemi dy punime, secila me 10 materiale dhe 9 kate. Do të jenë 180 rreshta në dokument, në të cilin kolona "punë" është pothuajse e njëjtë kudo, çdo material përsëritet 9 herë.

Më poshtë janë dy paraqitje të të njëjtit informacion. 1 - Linearisht, 2 - në formën e një peme me kolona sasiore dinamike. Për qartësi, unë theksova të dhëna të ndryshme në ngjyra: e kuqe - punë, blu - material, dysheme - jargavan, jeshile - vëllimi i punës, portokalli - kosto, e zezë - sasia e materialeve.

Opsioni i dytë kursen qartë hapësirën e ekranit. Në të parën kemi 150 qeli me informacion, në të dytën - 52. Për më tepër, sa më shumë dysheme dhe materiale në punë, aq më të mëdha janë kursimet.

Ky është opsioni i dytë që do të zbatojmë në këtë mësim.

Pra, hapni konfiguruesin. Unë mendoj se ju mund të skiconi vetë një strukturë të dhënash nga dy drejtori, një dokument dhe një regjistrim informacioni. Prandaj, unë do ta filloj historinë nga momenti kur tashmë kemi diçka të tillë:

  • Drejtoria "Punët"
  • Drejtoria "Materiale" (ose nomenklatura - nuk ka rëndësi)
  • Dokumenti "..." (mund ta quash "Përllogaritje" ose diçka tjetër)
  • Regjistri i informacionit, periodik, në të cilin matje: punë, material; burimi: llogaria e shpenzimeve (mund të krijoni një regjistrues për të, mund të lini redaktim të drejtpërdrejtë)

Së pari, duhet të vendosni për metodën e shndërrimit të pjesës tabelare në një pemë. E para (më e thjeshta) është përdorimi i një kërkese për të bërë totale për fushën e punës. E keqja këtu është se nuk mund të shtojmë dy vepra identike me përbërje të ndryshme materialesh në pjesën tabelare, sepse puna do të jetë një fushë kyçe. Puna jonë do të kombinohet në një nyje të pemës dhe materialet në të do të kombinohen. Mënyra e dytë është të shtoni një fushë kyçe që do të përcaktojë nëse rreshtat i përkasin të njëjtës nyje.

Më duket më e bezdisshme metoda e dytë, dokumenti ka detaje shtesë, por kodi bëhet transparent, i kuptueshëm dhe i besueshëm. Ne do të përdorim numrin si çelës. Le të shtojmë fushat numrin e punës dhe numrin e materialit në punë.

Këtu na mungon analitika e tretë - dyshemeja. Në rastin tonë do të jetë një numër i plotë pozitiv. Për lehtësi, ne do të shtojmë fushën "Numri i kateve" në kokë. Kjo fushë do ta thjeshtojë shumë jetën tonë. Ne e konsiderojmë të papranueshëm rastin kur pjesa tabelare përmban katin nr. 9, dhe numri maksimal i kateve është 8.

Hapi tjetër është të hiqni qafe fushën "Sasia e punës" dhe të lini vetëm sasinë. Në rreshtat ku MaterialNumberInWork = 0 do ta konsiderojmë sasinë si vëllim të punës.

Kjo është ajo me strukturën, le të hyjmë në formë. Le të krijojmë një formë të paracaktuar në të cilën do të vendosim gjithçka që kemi.

Së pari, ne do të bëjmë numrin dhe datën në një rresht, ky veprim duhet të bëhet gjithmonë automatikisht, është si një shkallë në kod.

Më pas, vizatoni atributin e formës "Pema e punës" me llojin e vlerës "Pema e vlerës". Le t'i shtojmë kolonat: Numri, Materiali i Punës, Shpenzimi, Kjo është Puna. Ne do të krijojmë dy faqe midis elementeve: një faqe shërbimi, ku do të dërgojmë pjesën reale tabelare, dhe një pemë, ku do të dërgojmë pemën. Ne do të shfaqim të gjitha kolonat e pemës përveç kutisë së kontrollit "Kjo është punë".

Tani le të hyjmë në kod. Do të na duhet një procedurë që vizaton kolona me sasi në bazë të numrit të kateve. Le ta quajmë "UpdateColumnComposition()". Në të do të krijojmë/fshijmë në mënyrë dinamike detajet e formularit dhe elementet e formës. Kjo procedurë do të thirret kur të krijohet forma dhe kur numri i kateve të ndryshojë. ato. Ne mund të kemi tashmë disa kolona në kohën kur thirret procedura dhe duhet t'i lëmë ato për të mos humbur të dhënat.

Këtu është sintaksa e saj:

&Në server
Procedura UpdateColumnComposition()
//1. Redaktimi i rishikimit të formularit, shtimi i kolonave në pemë
pemë = FormAttributesValue("Pema e punës");
mCUremove = Array i ri;
MaxColumnNumber = 0;
Për çdo kolonë nga cikli i kolonave
Nëse Lev(Column.Name, 3) = "Count" atëherë
SasiaNumri = numri(avg(Emri i kolonës,4));
Nëse SasiaNumber>Object.Numberofloors Pastaj
mCUremove.Add(Column);
fundNëse;
Nëse SasiaNumber>MaxColumnNumber Pastaj
MaxColumnNumber = Numri i sasisë;
fundNëse;
fundNëse;
Cikli i Fundit;
//2.
Detajet për fshirje = Array i ri;
Për çdo elementMKU hiqni nga cikli MKU hiqni
Detajet për fshirje.Add("Pema e punës." + elementi për fshirje.Emri);
//elementi i formës duhet të prishet përpara mbështetësve
Elements.Delete(Elementet["Pema e punës" + elementMCUdelete.Emri])
Cikli i Fundit;
//3.
DetailsKAdd = Array i ri;


NewFormAttributes = NewFormAttributes("Number"+NewNumber, NewTypeDescription("Number", NewNumberQualifiers(15,3)), "WorkTree", "to "+NewNumber);
DetailsToAdd.Add(NewFormAttributes);
Cikli i Fundit;
//4.
Ndrysho Detajet (DetajetPër të Shtuar, Detajet Për Fshirje);
//5. Ne vizatojmë elemente të reja të formës, ato duhet të shtohen pas krijimit të atributeve
Për w = 1 Sipas objektit Numri i kateve - Numri maksimal i ciklit të kolonave
NewNumber = MaxColumnNumber + w;
NewColumn = Elements.Add("WorkTreeNumber"+NewNumber, Type("FormField"), Elements.WorkTree);
NewColumn.View = FormFieldView.InputField;
NewColumn.DataPath = "TreeWork.Number"+Numri i ri;
Kolona e Re.Gjerësia = 7;
NewColumn.SetAction("OnChange", "QuantityOnChange");
NewColumn.Header = "to" + w;
Cikli i Fundit;
Përfundimi i procedurës

Le të komentojmë për fazat e punës së tij:

1. Kalojmë nëpër të gjitha kolonat e pemës për të zbuluar se sa kemi tashmë. Këtu përcaktojmë numrin e saj me emrin e kolonës dhe, nëse është më i madh se sasia e kërkuar, e shtojmë në listë për fshirje. Gjejmë gjithashtu numrin maksimal të kolonës ekzistuese. (po punojmë me detajet e formularit!!!)

2. Konvertoni listën e kolonave që do të fshihen në një listë rreshtash me emra të dhënash. Për një gjë, ne shkatërrojmë menjëherë elementet e formës, sepse ... Ju nuk mund të fshini atributet që shfaqen në formular.

3. Krijoni një listë të kolonave që duhet të krijohen.

4. Thirrni procedurën e integruar Change Details, pas së cilës nuk kemi më kolona shtesë dhe janë shfaqur ato që mungojnë.

Në fakt, në këtë procedurë ne pamë se si të vizatojmë saktë në mënyrë dinamike detajet e formës dhe elementet e formës. Nga nuancat e rëndësishme:

-nuk mund të fshini detaje që nuk janë krijuar në mënyrë programore

-Nuk mund të fshini detajet e përdorura në elementët e formës

Pasi të kemi ruajtur dhe nisur ndërmarrjen, do të shohim që kur hapim një dokument ekzistues, menjëherë vizatohet numri i kërkuar i kolonave dhe kur ndryshon numri i kateve, gjithçka rivizatohet menjëherë në mënyrë dinamike.

Tani le të shkruajmë një procedurë për konvertimin e një tabele në një pemë. Për provën, plotësoni pjesën tabelare në dokument si në figurë:

Për këtë qëllim, ne lamë pjesën reale të skedës në formular në mënyrë që të mund të korrigjojmë dhe kontrollojmë rezultatin.

&Në server
Procedura TabPartInTree()
Pema = FormAttributesValue("Pema e punës");
Tree.Rreshtat.Clear();
lineWork = "";
Numri i Punës = "";
Numri i Materialit = "";
Object.TabularPart1.Sort("Numri i Punës,Numri i MaterialitNëPuna");
Për çdo përzgjedhje nga objekti.TabularPart1 Cikli
//Kontrolloni numrin e kateve
Kati = Zgjidh.Kati;
Nëse Kati > Objekti.Numri i kateve Pastaj
Vazhdo;
fundNëse;
Nëse Kati = 0 Atëherë
Vazhdo;
fundNëse;
Nëse numri i punës<>Zgjidhni numrin e punës më pas
rowWorks = Tree.Lines.Add();
lineJob.Number = ZgjidhniNumrin e Punës;
lineWork.WorkMaterial = Zgjidh.Puna;
stringJob.ThisJob = E vërtetë;
//puna e radhës ka filluar, ne do të fillojmë numërimin e materialeve nga fillimi
Numri i Materialit = "";
Numri i Punës = Zgjidh Numri i Punës;
fundNëse;
Nëse SelectedMaterialNumberInJob = 0 atëherë//kjo është linja e punës
lineWork["Sasia"+Kati] = Zgjidh.Sasia;
Përndryshe // kjo është një linjë me materialin
Nëse Numri i Materialit<>Më pas zgjidhni numrin e materialit në punë
stringMaterial = stringWork.Strings.Add();
stringMaterial.Number = Zgjidh.MaterialNumberInJob;
stringMaterial.WorkMaterial = Zgjidh.Material;
lineMaterial.KConsumption = Zgjidh.KConsumption;
stringMaterial.ThisWork = False;
MaterialNumber=SelectedMaterialNumberInJob;
fundNëse;
lineMaterial["Sasia"+Kati] = Zgjidh.Sasia;
fundNëse;
Cikli i Fundit;
ValueВFormProps(Pema,"Pema e punës");
Përfundimi i procedurës

Nuk ka shumë për të komentuar këtu. Duke përdorur fushat “Numri i punës” dhe “Numri i materialit në punë” përcaktoj se kemi një rresht me një punë ose një material, përkatësisht, shtojmë një rresht në rrënjë ose në vepër. Nëse ka ndryshuar vetëm dyshemeja, atëherë marrim vetëm sasinë. Katet shtesë janë prerë, dyshemetë që mungojnë nuk do të prishin strukturën e pemës.

Ne e quajmë këtë procedurë kur e krijojmë atë në server pas “UpdateColumnComposition()”.

Tani mund ta provoni duke hapur ndërmarrjen dhe duke hapur dokumentin e krijuar më parë.

Tani duhet të bëjmë të kundërtën përpara se të shkruajmë dokumentin, duke ruajtur pemën në pjesën tabelare. Ne shkruajmë procedurën:

&OnClient
Procedura PlaceTreeВTabPart()
Objekti.Materiale.Clear();
Për çdo PageWork Nga TreeWork.GetElements() Loop


p.Kati = w;
str.Sasia = strWork["Sasia"+w];
Cikli i Fundit;
Për çdo PageMaterial Nga PageWork.GetElements() Loop
Për w = 1 Sipas ciklit të kateve
str = Object.Materials.Add();
p.Numri i punës = p.Numri i punës;
p.Numri i MaterialitNëPuna = p.Numri i Materialit;
p.Puna = rr.Puna.Material i punës;
str.Material = strMaterial.WorkMaterial;
str.KConsumption = str.Material.KConsumption;
p.Kati = w;
str.Sasia = strMaterial["Sasia"+f];
Cikli i Fundit;
Cikli i Fundit;
Cikli i Fundit;
Përfundimi i procedurës

Dizajni i formës së kushtëzuar në 1C 8 përdoret për të kontrolluar dukshmërinë, aksesueshmërinë dhe ngjyrën e elementeve të tabelës të një forme të menaxhuar (dhe përdoret gjithashtu në ACS dhe listat dinamike). Lehtësia e përdorimit të tij qëndron në faktin se dikur keni vendosur kushtin me të cilin duhet të ndryshojë dizajni i formës suaj. Pas kësaj, kur përdoruesi punon me formularin, kur të aktivizohet kushti, dizajni do të ndryshojë automatikisht. Nuk ka nevojë të përdorni ngjarje të formularit dhe të shkruani kode të panevojshme.

Duhet të zëvendësohet që dizajni i formës së kushtëzuar funksionon vetëm në konfigurime duke përdorur një aplikacion të menaxhuar (Accounting 3.0, ZUP 3.0/3.1, Trade Management 11, etj.)

Dizajni i kushtëzuar 1s. Konfigurimi interaktiv

Një avantazh tjetër i stilimit të kushtëzuar është se mund ta personalizoni pa shkruar një rresht të vetëm kodi. Për ta bërë këtë, formulari kërkon:

  • Vetitë e hapura të formës -> skeda e paraqitjes -> Paraqitja e kushtëzuar e hapur;
  • Do të hapet një tryezë ;
  • Në kolonën e parë ju duhet të zgjidhni një dizajn (ose disa menjëherë);
  • Në kolonën e dytë, vendosni kushtin me të cilin do të aktivizohet dizajni i zgjedhur;
  • Në kolonën e tretë, ju duhet të zgjidhni elementët e formularit që do të ndikohen nga dizajni i zgjedhur.

Ju lutemi vini re se stilimi i kushtëzuar ndikon vetëm në kolonat e tabelës. Ju gjithashtu mund të zgjidhni elementë të tjerë të formës në kolonë Fushat e formatuara, por kjo nuk do të japë asnjë rezultat.

Dizajni i formës së kushtëzuar. Shembull i konfigurimit interaktiv

Për shembull, kam shkruar një përpunim të thjeshtë, në format e të cilit është shtuar një atribut me llojin Tabela e vlerave, me tre kolona. Dhe gjithashtu tre detaje me llojin logjike. Mund ta shkarkoni përpunimin.

Formulari i përpunimit duket si ky:

Le të vendosim modelin e mëposhtëm të kushtëzuar për këtë formë: kur vendosni detajet Fsheh kolonën 1 në kuptim E vërtetë, fshihni detajet në tabelën e formularit Kolona 1.

  • Hapni cilësimet e cilësimeve të formës së kushtëzuar;
  • Le të shtojmë një rresht të ri në tabelë;
  • Në një kolonë Dekor Klikoni në butonin me tre pika dhe zgjidhni parametrin Dukshmëria, kuptimi Nr;

  • Në një kolonë gjendja Klikoni në butonin me tre pika dhe shtoni një përzgjedhje të re në dritaren që hapet. Le të fusim vlerat e mëposhtme atje: Vlera e majtë - HideColumn1, Lloji i krahasimit - E barabartë, Vlera e djathtë - Po;

  • Në një kolonë Fushat e formatuara klikoni në butonin me tre pika, shtoni një element të ri në dritaren që hapet dhe zgjidhni vlerën Tabela ShapesColumn1;
  • Si rezultat, duhet të kemi një cilësim të paraqitjes së kushtëzuar të ngjashme me atë në figurën e mëposhtme;

  • Le të shtypim butonin Ne rregull, ruajeni përpunimin tonë dhe drejtojeni atë në modalitet Ndërmarrja 1C;
  • Kur kontrolloni kutinë Fshih kolonën 1, ndryshimet e mëposhtme do të ndodhin në hartimin e formularit.


Regjistrimi me kusht 8.3. Shembull i konfigurimit të softuerit

Duke përdorur të njëjtin përpunim të jashtëm si në paragrafin e mëparshëm, do të japim një shembull të vendosjes programatike të paraqitjes së kushtëzuar. Ju duhet të bëni sa më poshtë: kur instaloni mbështetëset ChangeColorColumns2 në kuptim E vërtetë, në formën e tabelës ngjyrosni sfondin Kolonat 2, kur vendosni mbështetësit Bëje kolonën 3 të padisponueshme në kuptim E vërtetë, bëj të padisponueshëm në tabelën e formularit shtylla 3.

Le të krijojmë një procedurë serveri në modulin e formës dhe ta thërrasim atë SetConditionalAppearance dhe menjëherë shtoni thirrjen e saj në procedurë Kur KrijohetOnServer.

&OnServerProcedureWhenCreatingOnServer(Dështim, StandardProcessing) SetConditionalDesign(); Fundi i Procedurës &Në Server Procedura Vendos Paraqitja e Kushtëzuar () Fundi i Procedurës

Ne do të shkruajmë të gjithë kodin e mëposhtëm në një procedurë SetConditionalAppearance. Ne duhet të shtojmë një element të ri të formës së kushtëzuar për këtë ne përdorim koleksionin standard të formularit Formimi i kushtëzuar.

Element = ConditionalDesign.Elements.Add();

Ashtu si në versionin interaktiv, duhet të plotësojmë dizajnin, kushtet dhe fushat në elementin e krijuar. Për të specifikuar një fushë, ne duhet të krijojmë një fushë të përbërjes së të dhënave me emrin e kolonës në të cilën do të aplikohet dizajni. Nëse ka disa fusha, shtoni numrin e kërkuar të fushave të përbërjes së të dhënave. Për zgjedhjet, ne krijojmë elementë përzgjedhës për përbërjen e të dhënave dhe plotësojmë vlerën e majtë, vlerën e djathtë dhe llojin e krahasimit për to. Për të vendosur modelet e kërkuara, plotësoni parametrat e modeleve të disponueshme. Shembulli ynë prodhon kodin e mëposhtëm:

Element = ConditionalDesign.Elements.Add(); ElementFusha = Element.Fushat.Elementet.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn2.Name); Zgjedhja e elementit = Element.Selection.Elements.Add(Type("Elementi i përzgjedhjes së përbërjes së të dhënave")); Element Selection.LeftValue = NewDataCompositionField("ChangeColumnColor2"); Element Selection.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = E vërtetë; Element.Design.SetParameterValue("BackgroundColor", NewColor(255, 0, 0));

Kështu, ne krijuam një dizajn për kolonën e dytë të tabelës. Për kolonën e tretë është bërë në mënyrë të ngjashme, kështu që ne nuk do të ndalemi në të në detaje. Kodi përfundimtar i procedurës SetConditionalAppearance do të duket kështu:

&Në procedurën e serverit SetConditionalAppearance() Element = ConditionalAppearance.Elements.Add(); ElementFusha = Element.Fushat.Elementet.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn2.Name); Zgjedhja e elementit = Element.Selection.Elements.Add(Type("Elementi i përzgjedhjes së përbërjes së të dhënave")); Element Selection.LeftValue = NewDataCompositionField("ChangeColumnColor2"); Element Selection.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = E vërtetë; Element.Design.SetParameterValue("BackgroundColor", NewColor(255, 0, 0)); Element = ConditionalDesign.Elements.Add(); ElementFusha = Element.Fushat.Elementet.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn3.Name); Zgjedhja e elementit = Element.Selection.Elements.Add(Type("Elementi i përzgjedhjes së përbërjes së të dhënave")); ElementSelection.LeftValue = New DataCompositionField("Bëni kolonën 3 të padisponueshme"); Element Selection.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = E vërtetë; Element.Design.SetParameterValue("Availability", False); Përfundimi i procedurës

Më lejoni t'ju kujtoj se mund të shkarkoni përpunimin e shkruar në bazë të shembujve të analizuar.

Format në 1C: Enterprise janë të destinuara për shfaqjen dhe modifikimin e informacionit të përmbajtur në bazën e të dhënave. Formularët mund t'i përkasin objekteve specifike të konfigurimit ose ekzistojnë veçmas prej tyre dhe përdoren nga e gjithë zgjidhja e aplikacionit.

Për shembull, një drejtori Nomenklatura mund të ketë disa forma që do të përdoren për qëllime specifike - redaktimi i një elementi drejtorie, shfaqja e një liste, etj.:

Së bashku me këtë, mund të ketë forma të përgjithshme që nuk i përkasin objekteve specifike të konfigurimit - forma të përgjithshme.

Format bazë

Çdo objekt konfigurimi mund të përdoret për të kryer disa veprime standarde. Për shembull, për çdo drejtori mund t'ju duhet të shfaqni një listë të elementeve të tij, të shfaqni elementë individualë të drejtorisë, të shfaqni një grup drejtorie, të zgjidhni elemente dhe grupe elementesh nga drejtoria. Për çdo dokument, lista e veprimeve të tilla do të jetë shumë më e vogël: shikimi i një liste dokumentesh, përzgjedhja nga një listë dokumentesh dhe shikimi i një dokumenti të veçantë.

Për të siguruar që veprime të tilla standarde të kryhen me të dhënat e objekteve të zgjidhjes së aplikimit, për secilën prej tyre ekziston një grup formash bazë që do të përdoren gjatë kryerjes së veprimeve përkatëse. Secili nga format në varësi të këtij objekti mund të caktohet si ai kryesor. Për shembull, në drejtori Nomenklatura Mund të ekzistojnë format e mëposhtme themelore:

Dhe dokumenti Pranimi i mallrave dhe shërbimeve përbërja e formave kryesore do të jetë e ndryshme:

Kështu, nëse përdoruesi dëshiron të shikojë listën e drejtorive Nomenklatura ose listën e dokumenteve Pranimi i mallrave dhe shërbimeve, sistemi do të hapë formularin përkatës të caktuar si formulari i listës për këto objekte.

Format e gjeneruara automatikisht

Një tipar i rëndësishëm i sistemit 1C:Enterprise 8 është mekanizmi i formave të gjeneruara automatikisht. Ky mekanizëm e çliron zhvilluesin nga nevoja për të krijuar të gjitha format e mundshme për çdo objekt konfigurimi. Zhvilluesi duhet vetëm të shtojë një objekt të ri konfigurimi dhe vetë sistemi do të gjenerojë, në momentet e duhura në punën e përdoruesit, format e nevojshme për të shfaqur informacionin që përmban ky objekt.

Kështu, zhvilluesi duhet të krijojë format e tij të objekteve të zgjidhjes së aplikimit vetëm nëse ato duhet të kenë dallime (dizajn të ndryshëm ose sjellje specifike) nga format e gjeneruara automatikisht nga sistemi.

Lidhja e një formulari me të dhënat

Nëse një formë i përket një objekti të caktuar konfigurimi nuk përcakton përbërjen e të dhënave që shfaqen në formë. Fakti që forma i përket, për shembull, një drejtorie Nomenklatura, ju lejon ta caktoni atë si një nga format kryesore për këtë direktori, por nuk përcakton në asnjë mënyrë se çfarë të dhënash do të shfaqë ky formular dhe si do të jetë sjellja e tij.

Për të lidhur një formular me të dhënat, përdoren detajet e formularit, të cilat tregojnë listën e të dhënave të shfaqura nga formulari. Të gjitha format, vetë, kanë të njëjtën sjellje, pavarësisht se çfarë të dhënash shfaqin. Sidoqoftë, një nga atributet e formës mund të caktohet si atributi kryesor për të (është theksuar me shkronja të zeza), me ç'rast sjellja standarde e formës dhe vetitë e saj do të plotësohen në varësi të llojit të atributit të formës kryesore:

Për shembull, nëse një dokument caktohet si atributi kryesor i formës Pranimi i mallrave dhe shërbimeve, atëherë me mbylljen e formularit, sistemi do të kërkojë konfirmimin e regjistrimit dhe postimit të këtij dokumenti. Nëse caktoni, të themi, një direktori si atributin kryesor të formularit Nomenklatura, atëherë një kërkesë e tillë konfirmimi nuk do të shfaqet kur mbyllet formulari.

Struktura e formës

Karakteristika kryesore e formularëve është se ato nuk janë tërhequr nga zhvilluesi në detaje, "piksel pas piksel". Një formë në një konfigurim është një përshkrim logjik i përbërjes së formularit. Dhe vendosja specifike e elementeve kryhet automatikisht nga sistemi kur shfaqet forma.

Pjesa e shfaqur e formularit (e dukshme për përdoruesin) përshkruhet si një pemë që përmban elemente të formës.

Elementet mund të jenë fushat e hyrjes, kutitë e kontrollit, butonat e radios, butonat, etj. Për më tepër, një element mund të jetë një grup që përfshin elementë të tjerë. Një grup mund të përfaqësohet si një panel me një kornizë, një panel me faqe (shënues), një faqe në vetvete ose një panel komandimi. Përveç kësaj, elementi mund të jetë një tabelë, e cila gjithashtu përfshin elemente (kolona). Struktura e elementit përshkruan se si do të duket forma.

I gjithë funksionaliteti i formularit përshkruhet në formën e detajeve dhe komandave. Detajet janë të dhënat me të cilat funksionon forma dhe komandat janë veprimet që duhen kryer. Kështu, zhvilluesi në redaktuesin e formularit duhet të përfshijë detajet dhe komandat e nevojshme në formë, të krijojë elementë të formës që i shfaqin ato dhe, nëse është e nevojshme, t'i rregullojë elementet në grupe.

Bazuar në këtë përshkrim logjik, sistemi gjeneron automatikisht pamjen e formularit për t'i shfaqur përdoruesit. Në këtë rast, sistemi merr parasysh vetitë e ndryshme të të dhënave të shfaqura (për shembull, llojin) në mënyrë që të rregullojë elementët e formularit sa më të përshtatshëm për përdoruesin.

Zhvilluesi mund të ndikojë në rregullimin e elementeve me cilësime të ndryshme. Mund të përcaktojë rendin e elementeve, të tregojë gjerësinë dhe lartësinë e dëshiruar. Megjithatë, ky është vetëm disa informacione shtesë për të ndihmuar sistemin të shfaqë formularin.

Në forma, zhvilluesi mund të përdorë jo vetëm komandat e vetë formularit, por edhe komandat globale të përdorura në ndërfaqen e komandës së të gjithë konfigurimit. Përveç kësaj, është e mundur të krijohen komanda të parametrizueshme që do të hapin forma të tjera duke marrë parasysh të dhënat specifike të formularit aktual. Për shembull, kjo mund të jetë thirrja e një raporti mbi bilancet në magazinë që është përzgjedhur aktualisht në formularin e faturës.

Problemi kryesor është se gjatë 10-15 viteve tashmë janë përpiluar shumë kode për forma të zakonshme. Askush nuk dëshiron t'i rishkruajë të gjitha këto në server-klient + shumë njerëz janë të trajnuar për të punuar me ndërfaqen. Kalimi i detyrueshëm në BP 3.0 duke filluar nga viti i ardhshëm po krijon panik në mendjet e zhvilluesve dhe kontabilistëve. Reagimet do të jenë shumë të pakëndshme. Përveç kësaj, shiriti i hyrjes në profesion po rritet, programimi është më i vështirë, dhe ato standarde janë bërë edhe më të vështira. Sa është kostoja e algoritmit të ri në dokumentet standarde? UV-ja duket e mrekullueshme kur keni 2-3 butona në dokumente, UV-ja është e shkëlqyeshme për të punuar në pajisje celulare, por 0,01% e kompanive e përdorin atë. Do të duhet të ndërroni nëse 1C nuk del me diçka të re, por do të jetë e gjatë dhe e dhimbshme për të gjithë. Dhe vetë kompanitë do të duhet të paguajnë paratë.

Edhe unë kam përjetuar vetëm gjëra negative nga format e kontrolluara, por këtu janë disa disavantazhe të tjera të inovacionit:

  • Asgjë? Epo, kam hasur disa herë, për shembull, duke shkruar dhe bashkangjitur një formular printimi të jashtëm në konfiskimin e ZUP-it, përpunimi atje është një epope e tërë, plot udhëzime në internet dhe faqet e kodit duhet.
    në klientin e trashë ekziston një procedurë me parametra d.m.th. zhvillimi është çështje minutash.
    dhe frenat janë të holla të dukshme me sy të lirë
  • Sa i përket aftësisë për të përgatitur forma të menaxhueshme - ky është art për hir të artit, por cila është pika praktike, veçanërisht për versionin e skedarit?
  • Kam skalitur në UV për 3 vjet, por tani u ktheva përsëri në forma të thjeshta dhe më besoni, ky tranzicion ishte psikologjikisht mjaft i vështirë për t'u bërë, por kjo është zgjedhja ime e vetëdijshme sepse ajo që ofron 1c në UV është plotësisht UG…. ndoshta pas disa vitesh 1c do të bëjë një përparim, por tani ajo thjesht po kërkon vendin ku ta bëjë këtë zbulim...
  • UV-të në konfigurues kërkojnë shumë më shumë kohë për t'u hapur.
    Pas kësaj, hapja e formularëve në 8.1 është si transferimi nga një kamion në një aeroplan!
  • Ka më shumë probleme për të gjithë, përdoruesit janë të tronditur nga ndërfaqja e re (jo të gjithë e pranojnë atë, por ata janë shumë më budallenj për gjërat më të vogla), gjysma e programuesve janë bërë të papërshtatshëm për profesionalizëm, është bërë më e vështirë për specialistin mesatar. gjeni një punë dhe si të prodhoni një produkt cilësor. Dhe tema më e lezetshme e marketingut e UV-së është se ato fluturojnë kudo që tranzicioni ndodh me një përditësim të thjeshtë, por të gjithë harrojnë se që në fillim duhet të kapni hapat me publikimet më të fundit! Por në parim më pëlqen ideja!
  • Nuk e di, përvoja ime tregon të kundërtën. Aty ku bumet në forma strikte po godasin automatikisht prej disa vitesh, në standardet e reja UV çdo muaj fillon "pse, ku është 1C tani pas përditësimit të këtij butoni dhe pse tani nuk funksionon", gjë që shihni. , nuk shton shpejtësi.
  • - ka më shumë kod
    - kodi është bërë më kompleks
    — modifikimi i atyre standarde është shumë më i vështirë
    - përdoruesit të cilëve u dhashë UT11 nuk gjetën ndonjë avantazh në krahasim me 10.x
    - por ata gjetën disa ngadalësime dhe mungesë të disa funksioneve si kërkimi (për disa arsye ata donin kërkim përpara-prapa dhe jo përzgjedhje)
    Mendimi im është se sakrificat janë shumë të mëdha për hir të klientit të internetit dhe tabletave. Për më tepër, personalisht, nuk kam parë ende punë reale me një klient në internet, i cili duhet të përdorë me sukses aksesin në distancë
  • Bedlam klient-server duhet të sigurojë një rritje të performancës dhe shkallëzueshmërisë, ndërsa në të njëjtën kohë kostot përfshijnë një rritje të kodimit.
    Megjithatë, jo të gjithë pësuan një rritje, prandaj zhgënjimi. Dhe në të njëjtën kohë, të gjithë ishin të vendosur në kostot e kodimit.
    P.S. Në fakt, më pëlqejnë të kontrolluarit, i tërheq me qetësi. Por tipiket janë bërë perverse.
  • Në shtëpi (kompjuter normal) pijen e bëj sipas sipërmarrësve individualë.
    8.3, BP3, me damë. Përshtypja kryesore është se nuk punoj, por pres gjithë kohën. përgjigje hemorroide. SALT për llogarinë është formuar aq e thjeshtë sa dreqin - duket si një kartë llogarie për vitin në një mega-mbajtje.
  • UT11 është një frenim i egër, tmerr dhe në përgjithësi një makth.
    UT10 fluturon në krahasim me UT11.
    Përsa i përket UV - insektet janë infektuar prej vitesh, gjithçka është e shtrembër, kolonat nuk përshtaten kurrë në një ekran, shtrirja është e tmerrshme në shumë raste.
    Dhe unë ende mund të rendis shumë minus, por ndoshta nuk do të them asgjë për pluset. Ata thjesht nuk ekzistojnë.
    Konkretisht firmat përfunduan me këto forma, sepse zhvillimi kushton më shumë, nuk kishte speciale dhe nuk ka normale.

Ka pak avantazhe, por sigurisht që ekzistojnë...

pro:

Përgjigja ka qenë prej kohësh se çfarë ka dhënë UP-ja:

klient ndër platformë

  • duke punuar në linja të këqija komunikimi
  • aftësia për të punuar përmes një shfletuesi (pa instaluar një klient)