Izmantojot platformas 8.2 versiju 1C, sāka izmantot jaunus interfeisa konstruēšanas un lietotāja mijiedarbības ar datu bāzi principus. Jaunā tehnoloģija tiek saukta par "Pārvaldīto lietojumprogrammu". Veidlapu konstruēšanas mehānismi un mijiedarbības diagramma starp 1C servera lietotāju un datubāzi ir pakļauti vislielākā apstrādei. Platforma joprojām atbalsta parasto režīmu, taču laika gaitā visi 1C lietotāji pārslēgsies uz pārvaldītajām formām.
Parastajiem lietotājiem 1C dokumenta pārvaldītā forma no parastās atšķiras tikai pēc izskata. Izstrādātājam tas ir jauns mehānisms ar saviem noteikumiem, likumiem un nosacījumiem. Daudzās jomās ir notikušas izmaiņas, taču šādi jauninājumi tiek uzskatīti par galvenajiem pieredzējušo 1C izstrādātāju vidū:
- Neatkarīga formas struktūras veidošana un lauku izvietošana pie platformas. Ja agrāk izstrādātāji lauka pozīciju aprakstīja, norādot pikseļus, tad tagad ir iespējams norādīt tikai grupēšanas veidu;
- Veidlapa sastāv no detaļām, kas attēlo veidlapas datus, un komandām - veicamajām procedūrām un funkcijām;
- Veidlapas kods tiek izpildīts gan servera, gan klienta pusē. Galu galā pati forma ir konfigurācijas objekts, kas izveidots serverī un parādīts klientā. Tas nozīmē, ka tas apvieno klienta un servera daļas;
- Klienta pusē daudzi datu veidi ir kļuvuši nepieejami un vairs nav iespējams mainīt datus infobāzē;
- Katrai procedūrai vai funkcijai ir jānorāda īpašs iestatījums - kompilācijas direktīva. Tas ir atbildīgs par koda izpildes vietu, un tam var būt šādas vērtības:
- Naklient;
- Uz servera;
- OnServerWithoutContext;
- OnClientOnServer;
- Klientā serverī bez konteksta.
Pēdējais punkts ir īpaši aktuāls pārvaldīto formu režīmā. Ja izstrādātājam ir maz izpratnes par direktīvām vai klienta un servera mijiedarbību, viņam būs ārkārtīgi grūti izveidot pārvaldītu veidlapu. Visus jaunos pārvaldīto formu veidošanas principus 1C:Enterprise 8.3 apvieno vispārējā trīs līmeņu arhitektūras koncepcija. Tas ietver klientu datorus, 1C serveri un DBVS, kurā tiek glabāti dati.
Pārvaldītās veidlapas rediģēšana konfiguratorā arī ir kļuvusi atšķirīga. Ir mainījušies daudzi aspekti, un 7.7 versijas izstrādātāji, kuriem nebija pārvaldītas formas, var būt pārsteigti. Pat veidlapu noformētāja izskats ir mainījies, ko var redzēt, atverot jebkuru no konfigurācijas objektu formām. Atverot objektu, mēs redzam logu, kas sadalīts vairākās sadaļās:
- Veidlapas saskarnes elementi. Augšējā kreisajā stūrī ir logs, kurā uzskaitīti visi izvēlētajā formā redzamie lauki, kas nodrošina programmas mijiedarbību ar lietotāju;
- Veidlapas informācija. Augšējā labajā stūrī ir visi dati, ar kuriem darbojas veidlapa. Tie ir vieta, kur informācija tiek glabāta klienta pusē;
- Parādīt pārvaldītu veidlapu. Zemāk mēs redzam sākotnējo izskatu, pamatojoties uz saskarnes elementiem;
- Veidlapas modulis. Sadaļa, kurā ietvertas šajā veidlapā izmantotās procedūras un funkcijas. Šeit jūs varat atrast algoritmu kodu programmas mijiedarbībai gan ar lietotāju, gan datu bāzi.
1C izstrādātāji mudina klientus pāriet uz pārvaldītajām formām, tāpēc pārvaldīto formu izstrādes principu apguve ir laika jautājums. Kad sāksit strādāt ar šāda veida veidlapām, sapratīsit, ka tas ir solis pretī izstrādes standartizēšanai un vienotu noteikumu ievērošanai. Tāpēc spēja strādāt ar pārvaldītajām formām 1C 8.3 paaugstina jūsu kā 1C izstrādātāja līmeni.
Pārvaldīto veidlapu dizaina principi
Pirmkārt, lai saprastu 1C pārvaldītā režīma mehānismu, jāatceras, ka veidlapa pastāv gan serverī, gan klientā. Turklāt klientam šis objekts ir tikai interfeisa attēls lietotāja mijiedarbībai ar programmu. Visiem aprēķiniem, algoritmiem, aprēķiniem un apstrādei jānotiek tikai servera pusē. To nosaka ne tikai nespēja izmantot daudzas klienta funkcijas un parametrus, bet arī veiktspējas prasības.
Jūs varat noskaidrot, kur procedūra tiek izpildīta, izmantojot direktīvas nosaukumu, kas ir jāraksta pirms katras procedūras un funkcijas formas modulī. Formulējums “Bez konteksta” norāda, ka pārvaldītās formas dati netiks nodoti šai procedūrai serverī. Tādējādi šādās procedūrās nebūs iespējams rakstīt algoritmus, pamatojoties uz lietotāja ievadītajām vērtībām. Ja šis formulējums nav norādīts, veidlapa tiek pārsūtīta pilnībā ar visām detaļām, un jūs varēsiet tām piekļūt.
1C izstrādātāji stingri iesaka izmantot nekontekstuālus servera zvanus, pēc iespējas samazināt to skaitu un mēģināt neveikt klienta aprēķinus. Iesācējiem izstrādātājiem bez teorētiskās apmācības ir grūti ievērot visus šos noteikumus un pareizi mainīt kodu. Pirms sākat strādāt patstāvīgi, būs noderīgi atvērt pārvaldītās konfigurācijas veidlapu un apskatīt sintaksi un klienta un servera mijiedarbību.
&Servera procedūrā maksājumu norēķinu dokumentu saņemšana no krātuves (jauna adrese krātuvē) &Serverā bez konteksta funkcija ir aprēķini ar klientu (dokumenta pamatā) &Serverī bez konteksta procedūras Aizpildiet kontrolpunkta atlases sarakstu (atlases saraksts, darījuma partneris, Informācijas datums) & Par klienta procedūru Galvenajai aizpildīšanai Darījuma partnera pabeigšana (Selected Value, papildu parametri) &Par servera procedūru SetText Maksājumu un norēķinu dokumentu() &Par servera funkciju IsFilledInitialDocuments()Jaunie 1C veidlapu izstrādes noteikumi dos lielu labumu, ja visi izstrādātāji tos ievēros. Turklāt izmaiņas uz labo pusi jutīs ikviens – programmētāji, uzņēmumi, kas strādā 1C, franšīzes ņēmēji un 1C izstrādātāji. Galvenās 1C pārvaldīto formu pareizas izmantošanas sekas:
- Vienkārša konfigurācijas uzturēšana un uzlabota koda lasāmība. No tā varam secināt, ka viena izstrādātāja rakstītu algoritmu vienmēr var izlabot cits darbinieks, netērējot daudz laika;
- Klientā un serverī strādājoša koda atdalīšana. Ņemot vērā, cik atšķirīga ir katrā no šīm pusēm pieejamā funkcionalitāte, to atdalīšana būtu pareizais solis.
- Izstrādātājiem padziļināta izpratne par platformas loģiku, klienta un servera mijiedarbību un viņu rakstītajiem algoritmiem. Versijā 8.0 un vecākās versijās ļoti bieži tika atrastas dokumentu formas vai uzziņu grāmatas, kas izstrādātas, nesaprotot klienta-servera daļu;
- Konfigurāciju veiktspējas palielināšana un klientu datoru slodzes samazināšana;
- Samazinātas izmaksas par datoru iegādi darba vietām, jo nav nepieciešams iegādāties jaudīgus datorus.
Pārvaldītas formas izvēle par galveno 1C palaišanas režīmu var radīt daudz pārsteigumu. Bet ar pareizo pieeju šis solis nesīs lielas dividendes, tāpēc arvien vairāk 1C lietotāju visā Krievijā izlemj to pieņemt. Ņemot vērā to, ka uzņēmums 1C nākotnē rēķinās ar pārvaldīto formu attīstību, ir riskanti palikt pie novecojušām tradicionālajām formām.
Laba diena.
Šeit ir saraksts ar to, ko varat iegūt šeit:
- Parāda dokumenta tabulas daļu kā koku un pārvērš to atpakaļ tabulas daļā.
- Darbs ar nosacījumu formatējumu un tā programmatiskā izmantošana.
- Dinamiskas izmaiņas formas detaļu sastāvā
- Ērts interfeiss koka rediģēšanai
Un tagad šeit ir sākotnējie dati par problēmu, kas tiek atrisināta:
Mēs runāsim par aplēsēm par kaut ko celtniecību. Ir darbu veidu (turpmāk tekstā vienkārši darbs) un materiālu katalogs. Ir materiāla patēriņa likme uz darba vienību. Nepieciešams izstrādāt dokumentu, kurā lietotājs varētu katram darbam norādīt materiālu sarakstu tādā daudzumā, kāds nepieciešams, lai veiktu noteiktu šī darba apjomu katrā ēkas stāvā (patiesībā tas nav stāvs vispār , bet telpa, sekcija,... ko vien vēlies, ka ir iespējams izjaukt objektu, kas tiek būvēts).
Tie. Mums ir šāda dokumenta tabulas daļas struktūra:
stāvs - vēl nav skaidrs, kas tas ir
darba apjoms - numurs 15.3
materiālu daudzums - numurs 15.3
Šķiet vienkārši, bet praksē mēs saņemam daudz atkārtotas informācijas. Piemēram, mums ir divi darbi, katrs ar 10 materiāliem un 9 stāvi. Tās būs 180 rindiņas dokumentā, kurā kolonna “darbs” visur ir gandrīz vienāda, katrs materiāls tiek atkārtots 9 reizes.
Zemāk ir divi vienas un tās pašas informācijas attēlojumi. 1 - lineāri, 2 - koka formā ar dinamiskām daudzuma kolonnām. Skaidrības labad izcēlu dažādus datus krāsās: sarkans - darbs, zils - materiāls, grīda - ceriņi, zaļa - darba apjoms, oranža - izmaksas, melna - materiālu daudzums.
Otrā iespēja nepārprotami ietaupa vietu ekrānā. Pirmajā mums ir 150 kameras ar informāciju, otrajā - 52. Turklāt, jo vairāk grīdu un materiālu darbā, jo lielāks ietaupījums.
Šī ir otrā iespēja, ko mēs ieviesīsim šajā nodarbībā.
Tātad, atveriet konfiguratoru. Domāju, ka no diviem direktorijiem, dokumenta un informācijas reģistra var pats uzskicēt datu struktūru. Tāpēc stāstu sākšu no brīža, kad mums jau ir kaut kas līdzīgs šim:
- Katalogs "Darbi"
- Katalogs "Materiāli" (vai nomenklatūra - tas nav svarīgi)
- Dokuments "..." (varat to saukt par "tāmi" vai kā citādi)
- Informācijas reģistrs, periodisks, kurā mērījumi: darbs, materiāls; resurss: izdevumu konts (varat izveidot tam reģistratoru, varat atstāt tiešo rediģēšanu)
Pirmkārt, jums ir jāizlemj par metodi, kā pārveidot tabulas daļu kokā. Pirmais (vienkāršākais) ir izmantot pieprasījumu, lai veiktu darba lauka kopsummas. Mīnuss šeit ir tāds, ka tabulas daļai nevar pievienot divus identiskus darbus ar dažādu materiālu sastāvu, jo darbs būs galvenā joma. Mūsu darbs tiks apvienots vienā koka mezglā, un tajā esošie materiāli tiks apvienoti. Otrs veids ir pievienot atslēgas lauku, kas noteiks, vai rindas pieder vienam mezglam.
Man šķiet, ka otrā metode ir kaitinošāka, tā pievieno dokumentam papildu informāciju, bet kods kļūst caurspīdīgs, saprotams un uzticams. Mēs izmantosim numuru kā atslēgu. Pievienosim darba laukus darba numurs un materiāla numurs.
Šeit mums trūkst trešās analīzes - grīdas. Mūsu gadījumā tas būs pozitīvs vesels skaitlis. Ērtības labad galvenē pievienosim lauku “Stāvu skaits”. Šis lauks ievērojami vienkāršos mūsu dzīvi. Mēs uzskatām par nepieņemamu gadījumu, kad tabulas daļā ir stāvs Nr. 9 un maksimālais stāvu skaits ir 8;
Nākamais solis ir atbrīvoties no lauka “Darba apjoms” un atstāt tikai daudzumu. Rindās, kur MaterialNumberInWork = 0, daudzumu uzskatīsim par darba apjomu.
Tā tas ir ar struktūru, iejutīsimies formā. Izveidosim noklusējuma formu, kurā ievietosim visu, kas mums ir.
Pirmkārt, mēs ievietosim numuru un datumu vienā rindā, šī darbība vienmēr jāveic automātiski, tas ir kā kāpnes kodā.
Tālāk uzzīmējiet formas atribūtu “Darba koks” ar vērtības tipu “Vērtību koks”. Pievienosim tai kolonnas: Number, WorkMaterial, Expense, This isWork. Starp elementiem izveidosim divas lapas: servisa lapu, kur nosūtīsim īsto tabulas daļu un koku, kur nosūtīsim koku. Mēs parādīsim visas koka kolonnas, izņemot izvēles rūtiņu “Šis ir darbs”.
Tagad iedziļināsimies kodā. Mums būs nepieciešama procedūra, kas zīmē kolonnas ar daudzumiem, pamatojoties uz stāvu skaitu. Sauksim to par "UpdateColumnComposition ()". Tajā dinamiski veidosim/dzēsīsim veidlapas detaļas un veidlapas elementus. Šī procedūra tiks izsaukta, kad tiks izveidota veidlapa un mainīsies stāvu skaits. Tie. Iespējams, ka procedūras izsaukšanas brīdī mums jau ir dažas kolonnas, un mums tās ir jāatstāj, lai nezaudētu datus.
Šeit ir tā sintakse:
&Serverī
Procedūra UpdateColumnComposition()
//1. Veidlapas pārskatīšanas rediģēšana, kolonnu pievienošana kokam
koks = FormAttributesValue("Darba koks");
mCUremove = jauns masīvs;
MaxColumnNumber = 0;
Katrai koka kolonnai
Ja Lev(Slejas nosaukums, 3) = "Skaits", tad
DaudzumsNumurs = skaitlis(vid.(Slejas.Nosaukums,4));
Ja QuantityNumber>Object.NumberofFloors Tad
mCUnoņemt.Pievienot(kolonna);
endIf;
Ja QuantityNumber>MaxColumnNumber Tad
MaxColumnNumber = DaudzumsNumber;
endIf;
endIf;
EndCycle;
//2.
Sīkāka informācija dzēšanai = jauns masīvs;
Katram elementamMKUremove no MKUremove cikla
Detaļas dzēšanai.Add("Darba koks." + elements MK dzēšanai.Nosaukums);
//formas elementam jābūt avarētam pirms butaforijas
Elements.Delete(Elements["Darba koks" + MKUdelete elements.Name])
EndCycle;
//3.
DetailsToAdd = jauns masīvs;
NewFormAttributes = NewFormAttributes("Numurs"+JaunsNumurs, NewTypeDescription("Numurs", JaunsNumursQualifiers(15,3)), "Darba koks", "uz "+JaunsNumurs);
Sīkāka informācijaPievienot.Pievienot(NewFormAttributes);
EndCycle;
//4.
ChangeDetails (detaļas pievienošanai, detaļas dzēšanai);
//5. Uzzīmējam jaunus formas elementus, tie jāpievieno pēc atribūtu izveides
Ja w = 1 Pēc objekta stāvu skaita — maksimālais kolonnu skaits
NewNumber = MaxColumnNumber + w;
NewColumn = Elements.Add("Darba koka numurs"+JaunsNumurs, Tips("FormField"), Elements.WorkTree);
NewColumn.View = FormFieldView.InputField;
NewColumn.DataPath = "TreeWork.Number"+JaunsNumurs;
Jauna kolonna.Platums = 7;
NewColumn.SetAction("OnChange", "QuantityOnChange");
NewColumn.Header = "uz" + w;
EndCycle;
Procedūras beigas
Komentēsim tās darba posmus:
1. Mēs izejam cauri visām koka kolonnām, lai uzzinātu, cik daudz mums jau ir. Šeit mēs nosakām tā numuru pēc kolonnas nosaukuma un, ja tas ir lielāks par nepieciešamo daudzumu, pievienojam to sarakstam dzēšanai. Mēs atrodam arī maksimālo esošās kolonnas skaitu. (Strādājam ar veidlapas detaļām!!!)
2. Pārvērtiet dzēšamo kolonnu sarakstu par rindu sarakstu ar datu nosaukumiem. Pirmkārt, mēs uzreiz iznīcinām formas elementus, jo... Jūs nevarat izdzēst atribūtus, kas tiek parādīti veidlapā.
3. Izveidojiet sarakstu ar kolonnām, kuras nepieciešams izveidot.
4. Izsauciet iebūvēto procedūru Change Details, pēc kuras mums vairs nav papildu kolonnu un ir parādījušās trūkstošās.
Faktiski šajā procedūrā mēs redzējām, kā pareizi dinamiski uzzīmēt veidlapas detaļas un formas elementus. No svarīgākajām niansēm:
-Jūs nevarat izdzēst informāciju, kas nav izveidota programmatiski
-Jūs nevarat izdzēst veidlapas elementos izmantoto informāciju
Saglabājot un palaižot uzņēmumu, mēs redzēsim, ka, atverot esošu dokumentu, nekavējoties tiek uzzīmēts nepieciešamais kolonnu skaits, un, mainoties stāvu skaitam, viss tiek nekavējoties dinamiski pārzīmēts.
Tagad uzrakstīsim procedūru tabulas pārvēršanai kokā. Pārbaudei aizpildiet dokumenta tabulas daļu, kā parādīts attēlā:
Šim nolūkam veidlapā atstājām īsto cilnes daļu, lai varētu atkļūdot un pārbaudīt rezultātu.
&Serverī
Procedūra TabPartInTree()
Koks = FormAttributesValue("Darba koks");
Koks.Rindas.Notīrīt();
lineWork = "";
Darba numurs = "";
Materiāla numurs = "";
Object.TabularPart1.Sort("Darba numurs,MateriālanumursDarbā");
Katram Select From Object.TabularPart1 Loop
//Kontrolēt stāvu skaitu
Floor = Select.Floor;
Ja stāvs > objekts.stāvu skaits, tad
Turpināt;
endIf;
Ja stāvs = 0, tad
Turpināt;
endIf;
Ja darba numurs<>Pēc tam atlasiet Darba numurs
rowWorks = Tree.Lines.Add();
lineJob.Number = SelectDarbaNumurs;
lineWork.WorkMaterial = Select.Work;
stringJob.ThisJob = patiess;
//nākamais darbs ir sācies, materiālus sāksim skaitīt no sākuma
Materiāla numurs = "";
JobNumber = SelectDarbaNumber;
endIf;
Ja SelectedMaterialNumberInJob = 0, tad//šī ir darba rinda
lineWork["Daudzums"+Grīdas] = Atlasiet.Daudzums;
Citādi // šī ir rinda ar materiālu
Ja materiāla numurs<>Pēc tam darbā atlasiet materiāla numuru
stringMaterial = stringWork.Strings.Add();
stringMaterial.Number = Select.MaterialNumberInJob;
stringMaterial.WorkMaterial = Select.Material;
lineMaterial.KConsumption = Select.KConsumption;
stringMaterial.ThisWork = False;
MaterialNumber=SelectedMaterialNumberInJob;
endIf;
lineMaterial["Daudzums"+Grīda] = Izvēlieties.Daudzums;
endIf;
EndCycle;
ValueВFormProps(koks,"Darba koks");
Procedūras beigas
Šeit nav daudz ko komentēt. Izmantojot laukus “Darba numurs” un “Materiāla numursDarbā”, es nosaku, ka mums ir rinda ar attiecīgi darbu vai materiālu, pievienoju rindiņu saknei vai darbam. Ja mainījusies tikai grīda, tad ņemam tikai daudzumu. Tiek nogrieztas papildu grīdas, trūkstošās grīdas nesabojās koka struktūru.
Mēs izsaucam šo procedūru, veidojot to serverī pēc “UpdateColumnComposition()”.
Tagad varat to pārbaudīt, palaižot uzņēmumu un atverot iepriekš izveidoto dokumentu.
Tagad pirms dokumenta rakstīšanas mums ir jādara pretējais, saglabājot koku tabulas sadaļā. Mēs rakstām procedūru:
&OnClient
Procedūra PlaceTreeВTabPart()
Objekts.Materiāli.Notīrīt();
Katram PageWork darbam no TreeWork.GetElements() Loop
p.Grīda = w;
str.Daudzums = strWork["Daudzums"+w];
EndCycle;
Katrai lapaiMateriāls no PageWork.GetElements() Loop
Ja w = 1 pēc objekta stāvu skaita, cikls
str = Objekts.Materiāli.Pievienot();
p.Darba numurs = p.Darba numurs;
p.MaterialNumberInWork = p.Material.Number;
p.Darbs = str.Darbs.Darba materiāls;
str.Material = strMaterial.WorkMaterial;
str.KConsumption = str.Material.KConsumption;
p.Grīda = w;
str.Daudzums = strMateriāls["Daudzums"+f];
EndCycle;
EndCycle;
EndCycle;
Procedūras beigas
Nosacītā veidlapas dizains 1C 8 tiek izmantots, lai kontrolētu pārvaldītās veidlapas tabulas elementu redzamību, pieejamību un krāsu (un to izmanto arī ACS un dinamiskajos sarakstos). Tās izmantošanas ērtība slēpjas faktā, ka jūs reiz iestatījāt nosacījumu, ar kādu jāmaina jūsu veidlapas dizains. Pēc tam, kad lietotājs strādā ar veidlapu, kad nosacījums tiek aktivizēts, dizains mainīsies automātiski. Nav nepieciešams izmantot formas notikumus un rakstīt nevajadzīgu kodu.
Jāaizstāj, ka nosacījumformu dizains darbojas tikai konfigurācijās, kurās tiek izmantota pārvaldīta lietojumprogramma (Accounting 3.0, ZUP 3.0/3.1, Trade Management 11 utt.)
Nosacīts dizains 1s. Interaktīva iestatīšana
Vēl viena nosacītā stila priekšrocība ir tā, ka varat to pielāgot, neierakstot nevienu koda rindiņu. Lai to izdarītu, veidlapā ir nepieciešams:
- Atvērt veidlapas rekvizītus -> izskata cilne -> Nosacītā izskats Atvērt;
- Atvērsies galds ;
- Pirmajā kolonnā jums jāizvēlas dizains (vai vairāki vienlaikus);
- Otrajā kolonnā iestatiet nosacījumu, ar kuru tiks aktivizēts atlasītais dizains;
- Trešajā kolonnā ir jāatlasa veidlapas elementi, kurus ietekmēs izvēlētais dizains.
Lūdzu, ņemiet vērā, ka nosacījuma stils ietekmē tikai veidlapu tabulas kolonnas. Kolonnā varat atlasīt arī citus veidlapas elementus Formatēti lauki, bet tas nedos nekādu rezultātu.
Nosacīta formas dizains. Interaktīvas iestatīšanas piemērs
Kā piemēru uzrakstīju vienkāršu apstrādi, uz kuras formām tika pievienots atribūts ar tipu Vērtību tabula, ar trim kolonnām. Un arī trīs detaļas ar tipu Būla. Jūs varat lejupielādēt apstrādi.
Apstrādes forma izskatās šādi:
Šai veidlapai iestatīsim šādu nosacītu dizainu: iestatot detaļas Slēpt kolonnu1 nozīmē Taisnība, paslēpt informāciju veidlapas tabulā 1. kolonna.
- Atveriet nosacījumu formas iestatījumu iestatījumus;
- Pievienosim tabulai jaunu rindu;
- Kolonnā Dekors Noklikšķiniet uz pogas ar trim punktiem un atlasiet opciju Redzamība, nozīme Nē;
- Kolonnā Stāvoklis Noklikšķiniet uz pogas ar trim punktiem un atvērtajā logā pievienojiet jaunu atlasi. Ievadīsim tur šādas vērtības: Kreisā vērtība — HideColumn1, Salīdzinājuma veids — Vienāds, Labā vērtība — Jā;
- Kolonnā Formatēti lauki noklikšķiniet uz pogas ar trim punktiem, atveramajā logā pievienojiet jaunu elementu un atlasiet vērtību Tabulas formas Kolonna1;
- Rezultātā mums vajadzētu būt nosacīta izskata iestatījumam, kas ir līdzīgs nākamajā attēlā redzamajam;
- Nospiedīsim pogu labi, saglabājiet mūsu apstrādi un palaidiet to režīmā 1C uzņēmums;
- Atzīmējot lodziņu Paslēpt 1. kolonnu, veidlapas noformējumā notiks šādas izmaiņas.
Reģistrācija ar nosacījumiem 8.3. Programmatūras konfigurācijas piemērs
Izmantojot to pašu ārējo apstrādi kā iepriekšējā rindkopā, mēs sniegsim nosacītā izskata programmatiskās iestatīšanas piemēru. Jums jāveic šādas darbības: uzstādot rekvizītus Mainīt ColorColumns2 nozīmē Taisnība, tabulas formā iekrāso fonu 2. kolonnas, uzstādot rekvizītus Padarīt 3. kolonnu par nepieejamu nozīmē Taisnība, padarīt nepieejamu veidlapu tabulā rekvizīti 3. kolonna.
Veidosim veidlapas modulī servera procedūru un izsauksim to SetConditionalAppearance un nekavējoties pievienojiet tās aicinājumu procedūrai Kad CreatedOnServer.
&OnServerProcedureWhenCreatingOnServer(Failure, StandardProcessing) SetConditionalDesign(); Procedūras beigas &Servera procedūru komplekta nosacījuma izskats() Procedūras beigas
Mēs ierakstīsim visu tālāk norādīto kodu procedūrā SetConditionalAppearance. Mums ir jāpievieno jauns nosacījuma formas elements, lai to izmantotu standarta veidlapu kolekcija Nosacītā veidošanās.
Element = ConditionalDesign.Elements.Add();
Tāpat kā interaktīvajā versijā mums ir jāaizpilda dizains, nosacījumi un lauki izveidotajā elementā. Lai norādītu lauku, mums ir jāizveido datu kompozīcijas lauks ar kolonnas nosaukumu, kurai tiks piemērots dizains. Ja ir vairāki lauki, pievienojiet nepieciešamo datu sastāva lauku skaitu. Atlasēm veidojam atlases elementus datu kompozīcijai un aizpildām tiem kreiso vērtību, labo vērtību un salīdzināšanas veidu. Lai uzstādītu nepieciešamos dizainus, aizpildiet pieejamo dizainu parametrus. Mūsu piemērs rada šādu kodu:
Element = ConditionalDesign.Elements.Add(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn2.Name); Elementu atlase = Element.Selection.Elements.Add(Type("Datukompozīcijas atlases elements")); Elementu atlase.LeftValue = NewDataCompositionField("ChangeColumnColor2"); Elementu atlase.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = True; Element.Design.SetParameterValue("BackgroundColor", NewColor(255, 0, 0));
Tādējādi mēs izveidojām dizainu tabulas otrajai kolonnai. Trešajai kolonnai tas tiek darīts līdzīgā veidā, tāpēc mēs pie tā sīkāk nepakavēsimies. Nobeiguma procedūras kods SetConditionalAppearance izskatīsies šādi:
&Servera procedūrā SetConditionalAppearance() Element = ConditionalAppearance.Elements.Add(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn2.Name); Elementu atlase = Element.Selection.Elements.Add(Type("Datukompozīcijas atlases elements")); Elementu atlase.LeftValue = NewDataCompositionField("ChangeColumnColor2"); Elementu atlase.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = True; Element.Design.SetParameterValue("BackgroundColor", NewColor(255, 0, 0)); Element = ConditionalDesign.Elements.Add(); ElementField = Element.Fields.Elements.Add(); ItemField.Field = NewDataCompositionField(Items.FormTableColumn3.Name); Elementu atlase = Element.Selection.Elements.Add(Type("Datukompozīcijas atlases elements")); ElementSelection.LeftValue = New DataCompositionField("Padarīt 3. kolonnu par nepieejamu"); Elementu atlase.ComparisonView = DataCompositionComparisonView.Equals; ElementSelect.RightValue = True; Element.Design.SetParameterValue("Pieejamība", False); Procedūras beigas
Atgādināšu, ka varat lejupielādēt apstrādi, kas rakstīta, pamatojoties uz analizētajiem piemēriem.
Veidlapas 1C: Enterprise ir paredzētas datu bāzē esošās informācijas parādīšanai un rediģēšanai. Veidlapas var piederēt konkrētiem konfigurācijas objektiem vai pastāvēt atsevišķi no tiem, un tās izmanto viss lietojumprogrammas risinājums.
Piemēram, direktorijs Nomenklatūra var būt vairākas formas, kas tiks izmantotas konkrētiem mērķiem - direktorija elementa rediģēšanai, saraksta parādīšanai utt.:
Līdzās tam var būt vispārīgas formas, kas nepieder pie konkrētiem konfigurācijas objektiem – vispārīgās formas.
Pamatformas
Katru konfigurācijas objektu var izmantot, lai veiktu dažas standarta darbības. Piemēram, jebkuram direktorijam var būt nepieciešams parādīt tā elementu sarakstu, parādīt atsevišķus direktorija elementus, parādīt direktorijas grupu, atlasīt elementus un elementu grupas no direktorija. Jebkuram dokumentam šādu darbību saraksts būs daudz mazāks: dokumentu saraksta skatīšana, atlase no dokumentu saraksta un atsevišķa dokumenta skatīšana.
Lai nodrošinātu šādu standarta darbību veikšanu ar lietojumprogrammu risinājuma objektu datiem, katram no tiem ir noteikta pamatformu kopa, kas tiks izmantota, veicot atbilstošās darbības. Kā galveno var piešķirt jebkuru no šim objektam pakārtotajām formām. Piemēram, direktorijā Nomenklatūra Var pastāvēt šādas pamata formas:
Un dokuments Preču un pakalpojumu saņemšana galveno formu sastāvs būs atšķirīgs:
Tādējādi, ja lietotājs vēlas apskatīt direktoriju sarakstu Nomenklatūra vai dokumentu saraksts Preču un pakalpojumu saņemšana, sistēma atvērs atbilstošo veidlapu, kas norādīta kā šo objektu saraksta forma.
Automātiski ģenerētas veidlapas
Svarīga 1C:Enterprise 8 sistēmas iezīme ir automātiski ģenerētu veidlapu mehānisms. Šis mehānisms atbrīvo izstrādātāju no nepieciešamības izveidot visas iespējamās veidlapas katram konfigurācijas objektam. Izstrādātājam vienkārši jāpievieno jauns konfigurācijas objekts, un sistēma pati ģenerēs nepieciešamās veidlapas īstajos lietotāja darba brīžos, lai parādītu šajā objektā ietverto informāciju.
Tādējādi izstrādātājam ir jāizveido savas lietojumprogrammu risinājumu objektu formas tikai tad, ja tām ir jāatšķiras (atšķirīgs dizains vai īpaša uzvedība) no sistēmas automātiski ģenerētajām formām.
Veidlapas saistīšana ar datiem
Tas, vai forma pieder noteiktam konfigurācijas objektam, nenosaka formā parādīto datu sastāvu. Fakts, ka forma pieder, piemēram, direktorijai Nomenklatūra, ļauj to piešķirt kā vienu no galvenajām šī direktorija formām, taču nekādā veidā nenosaka, kādus datus šī forma parādīs un kāda būs tās darbība.
Lai veidlapu saistītu ar datiem, tiek izmantotas veidlapas detaļas, kas norāda veidlapas attēloto datu sarakstu. Visām veidlapām ir tāda pati darbība neatkarīgi no tā, kādus datus tās parāda. Tomēr vienu no formas atribūtiem var norādīt kā galveno atribūtu tai (tas ir izcelts treknrakstā), un tādā gadījumā formas standarta uzvedība un tās īpašības tiks papildinātas atkarībā no tā, kāda veida galvenais formas atribūts ir:
Piemēram, ja dokuments ir piešķirts kā galvenā formas atribūts Preču un pakalpojumu saņemšana, tad, aizverot formu, sistēma pieprasīs apstiprinājumu par šī dokumenta ierakstīšanu un ievietošanu. Ja jūs piešķirat, piemēram, direktoriju kā galveno veidlapas prasību Nomenklatūra, tad šāds apstiprinājuma pieprasījums neparādīsies, aizverot formu.
Veidlapas struktūra
Veidlapu galvenā iezīme ir tā, ka izstrādātājs tās nav zīmējis detalizēti, “pikseļi pa pikseļiem”. Veidlapa konfigurācijā ir formas sastāva loģisks apraksts. Un konkrēto elementu izvietojumu sistēma veic automātiski, kad tiek parādīta forma.
Parādītā formas daļa (redzama lietotājam) ir aprakstīta kā koks, kas satur formas elementus.
Elementi var būt ievades lauki, izvēles rūtiņas, radio pogas, pogas utt. Turklāt elements var būt grupa, kas ietver citus elementus. Grupu var attēlot kā paneli ar rāmi, paneli ar lapām (grāmatzīmēm), pašu lapu vai komandu paneli. Turklāt elements var būt tabula, kurā ir iekļauti arī elementi (kolonnas). Elementu struktūra apraksta, kā veidlapa izskatīsies.
Visa veidlapas funkcionalitāte ir aprakstīta detaļu un komandu veidā. Detaļas ir dati, ar kuriem veidlapa darbojas, un komandas ir veicamās darbības. Tādējādi izstrādātājam veidlapu redaktorā ir jāiekļauj veidlapā nepieciešamās detaļas un komandas, jāizveido veidlapas elementi, kas tos parāda, un, ja nepieciešams, elementi jāsakārto grupās.
Pamatojoties uz šo loģisko aprakstu, sistēma automātiski ģenerē veidlapas izskatu, ko parādīt lietotājam. Šajā gadījumā sistēma ņem vērā dažādus attēloto datu rekvizītus (piemēram, tipu), lai veidlapas elementus sakārtotu pēc iespējas ērtāk lietotājam.
Izstrādātājs var ietekmēt elementu izvietojumu ar dažādiem iestatījumiem. Tas var noteikt elementu secību, norādīt vēlamo platumu un augstumu. Tomēr šī ir tikai papildu informācija, kas palīdz sistēmai parādīt veidlapu.
Veidlapās izstrādātājs var izmantot ne tikai pašas formas komandas, bet arī globālās komandas, kas tiek izmantotas visas konfigurācijas komandu saskarnē. Turklāt ir iespējams izveidot parametrējamas komandas, kas atvērs citas formas, ņemot vērā konkrētās pašreizējās formas datus. Piemēram, tas varētu būt pārskata izsaukšana par atlikumiem noliktavā, kas pašlaik ir atlasīta rēķina veidlapā.
Galvenā problēma ir tā, ka 10-15 gadu laikā jau ir sastādīts daudz koda parastajām formām. To visu neviens negrib pārrakstīt uz klients-servera + ļoti daudz cilvēku ir apmācīti strādāt ar interfeisu. Obligātā pāreja uz BP 3.0, kas sākas nākamgad, rada paniku izstrādātāju un grāmatvežu prātos. Atsauksmes būs ļoti nepatīkamas. Turklāt latiņa iekļūšanai profesijā paceļas, programmēšana ir grūtāka, bet standarta kļuvuši vēl grūtāki. Kādas ir jaunā algoritma izmaksas standarta dokumentos? UV izskatās lieliski, ja uz dokumentiem ir 2-3 pogas, UV ir lieliski piemērots darbam ar mobilajām ierīcēm, taču to izmanto tikai 0,01% uzņēmumu. Jums būs jāpārslēdzas, ja 1C nenāks klajā ar kaut ko jaunu, bet tas būs ilgi un sāpīgi visiem. Un tā nauda būs jāmaksā pašiem uzņēmumiem.
Arī es no kontrolētajām formām līdz šim esmu piedzīvojis tikai negatīvas lietas, šeit ir vēl daži jaunieveduma mīnusi:
- Nekas? Nu ar šo pāris reizes saskāros, piemēram, ZUP conf uzrakstot un pievienojot ārējo drukāšanas formu, apstrāde tur ir vesela epopeja, pilna ar instrukcijām internetā un koda lapām vajadzētu.
uz bieza klienta ir viena procedūra ar parametriem t.i. attīstība ir dažu minūšu jautājums.
un bremzes ir plānas, redzamas ar neapbruņotu aci - Kas attiecas uz spēju sagatavot pārvaldāmas formas - tā ir māksla mākslas dēļ, bet kāda ir praktiskā jēga, īpaši faila versijai?
- 3 gadus veidoju UV, bet tagad pārgāju atpakaļ uz vienkāršām formām, un ticiet man, šī pāreja bija psiholoģiski diezgan sarežģīta, taču tā ir mana apzināta izvēle, jo tas, ko 1c piedāvā UV, ir pilnīgi UG…. varbūt pēc pāris gadiem 1c veiks izrāvienu, bet tagad viņa tikai meklē vietu, kur šo izrāvienu izdarīt...
- UV staru atvēršana konfiguratorā prasa daudz ilgāku laiku.
Pēc tam veidlapu atvēršana 8.1 ir kā pārsēšanās no kravas automašīnas uz lidmašīnu! - Visiem ir vairāk problēmu, lietotāji ir šokēti par jauno interfeisu (ne visi to atzīst, bet viņi ir daudz stulbāki par mazākām lietām), puse programmētāju ir kļuvuši nepiemēroti profesionālismam, vidējam speciālistam ir kļuvis grūtāk atrast darbu un kā ražot kvalitatīvu produktu. Un stilīgākā UV mārketinga tēma ir tā, ka tie paceļas visur, kur notiek pāreja ar vienkāršu atjauninājumu, bet visi aizmirst, ka no sākuma jums ir jāpanāk jaunākie izdevumi! Bet principā man ideja patīk!
- Es nezinu, mana pieredze liecina par pretējo. Kur striktās formās bumi jau vairākus gadus sit automātiski, tad jaunajā UV standartā katru mēnesi sākas “kāpēc, kur tagad pēc šīs pogas atjaunināšanas ir 1C un kāpēc tagad nestrādā”, kas, redz. , nepievieno ātrumu.
- - ir vairāk koda
- kods ir kļuvis sarežģītāks
— standarta modificēšana ir daudz grūtāka
- lietotāji, kuriem iedevu UT11, neatrada nekādas priekšrocības salīdzinājumā ar 10.x
- taču viņi atklāja dažus palēninājumus un dažu funkciju, piemēram, meklēšanas, trūkumu (kādu iemeslu dēļ viņi vēlējās meklēt uz priekšu atpakaļ, nevis atlasi)
Mans viedoklis ir, ka upuri ir pārāk lieli tīmekļa klienta un planšetdatoru labā. Turklāt es personīgi vēl neesmu redzējis reālu darbu ar tīmekļa klientu, kuram ir nepieciešams veiksmīgi izmantot attālo piekļuvi - Klienta-servera savienojumam ir jānodrošina veiktspējas un mērogojamības pieaugums, vienlaikus izmaksās iekļaujot kodēšanas palielināšanu.
Tomēr ne visi piedzīvoja pieaugumu, tāpēc arī vilšanās. Un tajā pašā laikā visi bija pakļauti kodēšanas izmaksām.
P.S. Īstenībā man patīk kontrolētie, mierīgi zīmējos uz tiem. Bet tipiskie ir kļuvuši perversi. - Mājas datorā (parastā datorā) es dzeru pēc individuālo uzņēmēju domām.
8.3, BP3, rūtains. Galvenais iespaids ir tāds, ka es nestrādāju, bet visu laiku gaidu. hemoroīda reakcija. SĀLS kontam veidojas gluži vienkārši - šķiet kā konta karte gadam megaholdēšanā. - UT11 ir mežonīga bremze, šausmas un kopumā murgs.
UT10 lido, salīdzinot ar UT11.
Attiecībā uz UV - blaktis ir invadētas jau gadiem, viss ir greizs, kolonnas nekad neiederas vienā ekrānā, stiepšanās daudzos gadījumos ir briesmīga.
Un es joprojām varu uzskaitīt daudz mīnusu, bet es droši vien neko neteikšu par plusiem. Viņi vienkārši neeksistē.
Firmas speciāli sanāca ar šīm formām, jo izstrāde maksā dārgāk, nebija speciālo un nav arī normālu.
Priekšrocību ir maz, bet tās, protams, pastāv...
plusi:
Atbilde ir bijusi jau ilgu laiku, ko sniedza UP:
vairāku platformu klients
- strādā pie sliktām sakaru līnijām
- spēja strādāt caur pārlūkprogrammu (bez klienta instalēšanas)
Notiek ielāde...
