Ձևի հիմնական մանրամասները. Կառավարվող ձևի մանրամասները (1Cv8) 1c կառավարվող ձևերը մանրամասներ են ավելացնում ծրագրային եղանակով
Ձևի մանրամասները
Ձևի մանրամասների հավաքածուն նկարագրում է ձևի մեջ ցուցադրվող, խմբագրված կամ պահվող տվյալների կազմը: Միևնույն ժամանակ, ձևի մանրամասներն իրենք չեն ապահովում տվյալների ցուցադրման և խմբագրման հնարավորությունը: Ձևի տարրերը (տե՛ս այս գլխի «Ձևի տարրեր» բաժինը), որոնք կապված են ձևի մանրամասների հետ, օգտագործվում են ցուցադրման և խմբագրման համար: Բոլոր ձևի մանրամասների հավաքածուն կկոչվի ձևի տվյալներ:
Կարևոր.Պետք է հիշել, որ, ի տարբերություն սովորական ձևերի, կառավարվող ձևի բոլոր տվյալները պետք է նկարագրվեն մանրամասների տեսքով: Չի թույլատրվում օգտագործել ձևի մոդուլի փոփոխականները որպես ձևի տարրերի տվյալների աղբյուրներ:
Հնարավոր է հանձնարարել Հիմնական ձևի մանրամասները, այսինքն՝ ատրիբուտներ, որոնք կորոշեն ձևի ստանդարտ ֆունկցիոնալությունը (ձևի ընդլայնում): Պետք է հիշել, որ ձևը կարող է ունենալ միայն մեկ հիմնական հատկանիշ.
Ձևի ընդլայնում– սրանք ManagedForm օբյեկտի լրացուցիչ հատկություններ, մեթոդներ և ձևի պարամետրեր են, որոնք բնորոշ են ձևի հիմնական տարր հանդիսացող օբյեկտին:
Ձևաթղթի մշակման գործընթացում դուք կարող եք հստակորեն սահմանել ձևի հատուկ մանրամասներ դիտելու և խմբագրելու հնարավորությունը՝ դերերի առումով՝ օգտագործելով Դիտել և Խմբագրել հատկությունները (ավելին մանրամասների համար տե՛ս «Խմբագրիչներ» բաժնում «Դերի վրա հիմնված ձևի կարգավորումներ» բաժինը։ «գլուխ): Բացի այդ, ձևի մեջ որոշակի հատկանիշի առկայությունը կարող է կազմաձևվել՝ օգտագործելով ֆունկցիոնալ ընտրանքները (ֆունկցիոնալ ընտրանքների մասին ավելի շատ մանրամասներ կարելի է գտնել «Կազմաձևման ինտերֆեյսի կառավարում» գլխում):
Ձևի հատկանիշի հատկություն Պահպանված տվյալներնշան է, որ մանրամասների ինտերակտիվ փոփոխությունը կհանգեցնի ձևի տվյալների խմբագրման համար արգելափակելու փորձին, ինչպես նաև ձևի փոփոխման դրոշի ավտոմատ կարգավորումին:
Տվյալների տեսակները հասանելի են կառավարվող ձևով
Կառավարվող ձևը սովորական ձևից տարբերվում է նաև տվյալների տեսակներով, որոնցով աշխատում է: Եթե նորմալ ձևն աշխատում է 1C:Enterprise-ի տրամադրած տեսակների մեծ մասի հետ (ներառյալ DirectoryObject, DocumentObject և այլն տեսակները), ապա կառավարվող ձևով կարելի է տարբերակել տեսակների հետևյալ կատեգորիաները.
- տեսակները, որոնք ուղղակիորեն օգտագործվում են ձևի մեջ, այն տեսակներն են, որոնք գոյություն ունեն բարակ և վեբ հաճախորդի կողքին (օրինակ՝ Number, DirectoryLink.Products, GraphicScheme, TabularDocument);
- տեսակներ, որոնք կվերածվեն հատուկ տվյալների տիպերի՝ կառավարվող ձևի տվյալների տեսակների: Նման տեսակները ցուցադրվում են փակագծերում դրված ձևի մանրամասների ցանկում, օրինակ (DirectoryObject.Products);
- դինամիկ ցուցակ (ավելի մանրամասների համար տե՛ս այս գլխի «Դինամիկ ցուցակ» բաժինը):
Դիմումի օբյեկտները ձևի տվյալների վերածելը
Հավելվածների որոշ տեսակներ (օրինակ՝ DirectoryObject և այլն) գոյություն չունեն բարակ և վեբ-հաճախորդի կողմում (Լրացուցիչ մանրամասների համար տե՛ս «Կառավարվող հավելվածի հայեցակարգ» գլուխը): Հետևաբար, նման հավելվածների տեսակները ձևով ներկայացնելու համար հարթակը ներկայացրել է տվյալների հատուկ տեսակներ, որոնք նախատեսված են կառավարվող ձևերում աշխատելու համար: Կառավարվող հավելվածի այս առանձնահատկությունն անհրաժեշտ է դարձնում հավելվածի օբյեկտները տվյալների ձևավորման համար փոխակերպել (և հակառակը):
Օգտագործվում են տվյալների հետևյալ տեսակները.
- Form DataStructure – պարունակում է կամայական տիպի հատկությունների մի շարք: Հատկություններ կարող են լինել այլ կառույցներ, հավաքածուներ կամ հավաքածուներով կառույցներ: Այս տեսակը ներկայացված է, օրինակ, DirectoryObject ձևով:
- FormDataCollection-ը մուտքագրված արժեքների ցանկ է, որը նման է զանգվածին: Հավաքածուի տարրը հասանելի է ինդեքսով կամ նույնացուցիչով: Որոշ դեպքերում ID-ով մուտքը կարող է հասանելի չլինել: Սա պայմանավորված է կիրառական օբյեկտի տեսակով, որը ներկայացված է այս հավաքածուով: Նույնացուցիչը կարող է լինել ցանկացած ամբողջ թիվ: Այս տեսակը ներկայացված է, օրինակ, աղյուսակային մասի տեսքով։
- Form DataStructureWithCollection-ը օբյեկտ է, որը միաժամանակ ներկայացված է որպես կառուցվածք և հավաքածու: Այն կարելի է վերաբերվել այնպես, ինչպես այս սուբյեկտներից որևէ մեկին: Այս տեսակը ներկայացնում է, օրինակ, մի ձևի գրառումների հավաքածու:
- Form DataTree – օբյեկտ, որը նախատեսված է հիերարխիկ տվյալներ պահելու համար:
Հավելվածի օբյեկտը ներկայացված է մեկ կամ մի քանի ձևի տվյալների տարրերով: Ընդհանուր առմամբ, ձևի տվյալների հիերարխիան և կազմը կախված են կառավարվող ձևի կիրառական օբյեկտների բարդությունից և փոխկապակցվածությունից:
Օրինակ, աղյուսակային մաս պարունակող փաստաթուղթը կներկայացվի FormDataStructure տիպի օբյեկտով (փաստաթուղթն ինքնին), որին ենթակա է FormDataCollection տիպի օբյեկտը (փաստաթղթի աղյուսակային մասը):
Կարևոր.Կազմաձևը մշակելիս կարևոր է հիշել, որ հավելվածի օբյեկտները հասանելի են միայն սերվերում, մինչդեռ ձևի տվյալների օբյեկտները կարող են օգտագործվել ինչպես սերվերի, այնպես էլ հաճախորդի վրա:
Տվյալների փոխանցում կառավարվող ձևի հաճախորդի և սերվերի մասերի միջև
Փաստորեն, մենք կարող ենք ասել, որ ձևի տվյալները տարբեր կիրառական օբյեկտների տվյալների միասնական ներկայացում են, որոնց հետ ձևը միատեսակ է աշխատում և որոնք առկա են ինչպես սերվերի, այնպես էլ հաճախորդի վրա: Այսինքն, ձևը պարունակում է կիրառական օբյեկտի տվյալների որոշակի «պրոյեկցիա» իր սեփական տվյալների տեսակների տեսքով և անհրաժեշտության դեպքում կատարում է փոխակերպում նրանց միջև: Այնուամենայնիվ, եթե կոնֆիգուրացիայի մշակողը կիրառում է տվյալների մշակման իր ալգորիթմը, ապա նա պետք է ինքնուրույն կատարի տվյալների փոխարկումը (մասնագիտացված տեսակներից դեպի հավելվածի տեսակներ և հակառակը):
Մասնագիտացված խմբագրիչում ձևի մանրամասները խմբագրելիս (մանրամասների համար տե՛ս «Խմբագիրներ» գլխի «Ձևի մանրամասներ» բաժինը), հնարավոր է ազդել հաճախորդի և սերվերի միջև տվյալների փոխանցման վրա, մինչ ձևն աշխատում է: Դրա համար օգտագործվում է մանրամասների խմբագրիչի սյունակը: Միշտ օգտագործեք. Այս հատկության ազդեցությունը տարբերվում է երեք տեսակի հատկանիշների համար.
- Դինամիկ ցուցակին ենթակա հատկանիշի համար (դինամիկ ցուցակի սյունակ).
- հատկությունը միացված է – հատկանիշը միշտ ընթերցվում է տվյալների բազայից և ներառվում է ձևի տվյալների մեջ.
- հատկությունն անջատված է. հատկանիշն ընթերցվում է տվյալների բազայից և ներառվում է ձևի տվյալների մեջ միայն այն դեպքում, երբ առկա է տվյալ հատկանիշի կամ դրա ենթակա հատկանիշի հետ կապված ձևի տեսանելի տարր:
- Շարժման հավաքածուին ենթակա պարագաների համար.
- հատկությունը միացված է. փաստաթղթերի շարժումները կարդացվում են տվյալների բազայից և առկա կլինեն ձևի տվյալների մեջ.
- գույքն անջատված է. փաստաթղթերի շարժումները չեն կարդացվի տվյալների բազայից և չեն ներառվի ձևի տվյալների մեջ (եթե չկա ձևի տարր, որը հղում է անում փաստաթղթերի շարժումներին):
- Ձևի այլ մանրամասներ.
- հատկությունը միացված է. հատկանիշը առկա կլինի ձևի տվյալների մեջ՝ անկախ նրանից, թե կա ձևի գոնե մեկ տարր, որը կապված է հատկանիշի կամ դրա ենթակա հատկանիշի հետ.
- հատկությունն անջատված է. հատկանիշը կհայտնվի ձևի տվյալների մեջ միայն այն դեպքում, եթե կա ձևի տարր՝ կապված հատկանիշի կամ դրա ենթակա հատկանիշի հետ: Ի տարբերություն դինամիկ ցանկի ատրիբուտների, հատկանիշի հետ կապված տարրի տեսանելիությունն այստեղ նշանակություն չունի։
Նշում. Պետք է հիշել, որ մայր հատկանիշի վրա դրված հատկությունը ազդում է բոլոր ենթակա ատրիբուտների վրա: Օրինակ, եթե Use հատկությունը միշտ մաքրվում է փաստաթղթի աղյուսակային մասի համար, ապա համակարգը համարում է, որ այս հատկությունը նույնպես մաքրված է բոլոր ստորադաս մանրամասների համար (չնայած գույքի փաստացի վիճակին):
Ծրագրի օբյեկտի տվյալները ձևի տվյալների վերածելու մեթոդներ
Հավելվածի օբյեկտները ձևի տվյալների և հետ փոխարկելու համար կա գլոբալ մեթոդների մի շարք.
- ValueInFormData (),
- FormDataInValue(),
- CopyFormData ().
Կարևոր.Մեթոդները, որոնք աշխատում են կիրառական օբյեկտների հետ, հասանելի են միայն սերվերի ընթացակարգերում: Ձևի տվյալների միջև արժեքների պատճենման մեթոդը հասանելի է սերվերի և հաճախորդի վրա, քանի որ այն չի պահանջում հավելվածի օբյեկտներ որպես պարամետրեր:
Ձևի տվյալները հավելվածի օբյեկտի վերածելիս պետք է հաշվի առնել դրանց համատեղելիությունը:
- ValueInFormData() – հավելվածի տիպի օբյեկտը փոխակերպում է ձևի տվյալների;
- FormDataInValue() – ձևի տվյալները փոխակերպում է հավելվածի տիպի օբյեկտի;
- CopyFormData() – պատճենում է այն տվյալները, որոնք ունեն համատեղելի կառուցվածք: Վերադարձնում է True, եթե պատճենը հաջող էր, կամ False, եթե օբյեկտի կառուցվածքը անհամատեղելի է:
Նշում. Հիմնական մանրամասներով ձևի ստանդարտ գործողություններ (ձև բացել, ստանդարտ Write հրամանի կատարում և այլն) կատարելիս փոխարկումն իրականացվում է ավտոմատ կերպով:
Եկեք օրինակ բերենք, թե ինչպես օգտագործել տվյալների փոխակերպումը ձեր սեփական ալգորիթմներում:
ObjectProduct = Directories.Products.FindByName("Coffeepot").GetObject(); ValueInFormData (ObjectItem, Object);
Ընթացակարգի ավարտը
&OnClient կարգը Գրել()
WriteOnServer();
Ընթացակարգի ավարտը
&OnServer կարգը WriteOnServer()
ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();
Ընթացակարգի ավարտը
ManagedForm օբյեկտը ունի նաև սերվերի վրա հասանելի մեթոդներ.
- ValueВFormAttribute() – հավելվածի տիպի օբյեկտը փոխակերպում է նշված ձևի հատկանիշի:
- FormAttributeVValue() – ձևի տվյալների հատկանիշը վերածում է հավելվածի տեսակի օբյեկտի:
Այս մեթոդների օգտագործումը սովորաբար ավելի հարմար է, քանի որ դրանք ունեն, օրինակ, տեղեկատվություն ձևի տեսակի մանրամասների մասին: Բացի այդ, Form AttributesValue() մեթոդը սահմանում է համապատասխանությունը ձևի տվյալների և օբյեկտի միջև, որն օգտագործվում է հաղորդագրություններ ստեղծելիս: Այս մասին ավելին կարող եք կարդալ «Ծառայությունների նավիգացիոն հնարավորություններ» գլխում:
Բերենք այս մեթոդների կիրառման օրինակ։
// Փոխակերպում է Object հատկանիշը հավելվածի օբյեկտի: Փաստաթուղթ = Form AttributesValue («Օբյեկտ»); // Կատարում է վերահաշվարկ՝ օգտագործելով փաստաթղթի մոդուլում սահմանված մեթոդը: Document.Recalculate(); // Վերափոխում է հավելվածի օբյեկտը հենարանի: ValueВFormAttributes (Փաստաթուղթ, «Օբյեկտ»);
Ընթացակարգի ավարտը
Ծրագրային ինտերֆեյս
FormDataTree
- FindById
- GetItems
Նկարագրություն:
Նախագծված է կառավարվող տվյալների մեջ ծառ մոդելավորելու համար:
Այս օբյեկտը կարող է սերիականացվել XDTO-ից/: Այս օբյեկտին համապատասխան XDTO տեսակը սահմանվում է անվանատարածքում։ XDTO տեսակի անունը.
GetItems
Շարահյուսություն:
GetItems ()
Վերադարձի արժեքը.
Տեսակ՝ Ծառի տարրերի տվյալների հավաքագրման ձև:
Նկարագրություն:
Ստանում է վերին մակարդակի ծառի տարրերի հավաքածու:
Հասանելիություն՝ հաճախորդ, սերվեր, thin client, web client:
FindById
Շարահյուսություն:
FindById (<Идентификатор>)
Ընտրանքներ:
<Идентификатор>(պարտադիր)
Տեսակ՝ համար։ Ծառի տարրի նույնացուցիչը:
Վերադարձի արժեքը.
Տեսակ՝ FormDataTreeElement:
Նկարագրություն:
Ստանում է հավաքածուի տարր ID-ով:
Հասանելիություն՝ հաճախորդ, սերվեր, thin client, web client:
FormDataTreeItem
Հատկություններ:
<Имя свойства> (<Имя свойства>)
- GetId (GetId)
- GetParent
- GetItems
- Սեփականություն
Նկարագրություն:
Ձևավորել տվյալների ծառի տարրը:
FormDataTreeItemCollection
Հավաքածուի տարրեր՝ DataFormTreeElement
Օբյեկտի համար հնարավոր է անցնել հավաքածուն՝ օգտագործելով օպերատորը For every... From... Loop: Անցումը ընտրում է հավաքածուի տարրերը: Հնարավոր է մուտք գործել հավաքածուի տարր՝ օգտագործելով [...] օպերատորը: Տարրի ինդեքսը փոխանցվում է որպես արգումենտ։
- Տեղադրեք
- Ավելացնել
- Ինդեքս (IndexOf)
- հաշվել
- Պարզ
- Ստացեք
- Տեղափոխել
- Ջնջել
Նկարագրություն:
Փայտե տարրերի հավաքածու.
Հասանելիություն՝ հաճախորդ, սերվեր, thin client, web client:
Տես նաեւ:
- FormDataTreeElement, GetElements մեթոդ
- DataFormTree, մեթոդ GetItems
Արժեքի ծառի հետ աշխատելու առանձնահատկությունները
Ծառի թարմացում
Խնդիր կա ընկնում էհարթակներ ծառը թարմացնելիս:
Եթե ծառի որևէ հանգույց ընդլայնվել է և ընտրվել է ստորադաս հանգույց, ապա ծառը գործառույթով թարմացնելիս. ValueInFormDataհարթակը ընկնում է.
Լուծում. Թարմացնելուց առաջ անհրաժեշտ է մաքրել ծառը:
Օրինակ:
&Սերվերի ընթացակարգի վրա ClearTree(տարրեր) տարրերից յուրաքանչյուր տարրի համար Loop ClearTree(element.GetElements()); End Cycle; տարրեր.Clear(); Ընթացակարգի ավարտը
&Սերվերի ընթացակարգի վրա Fill Concept Tree() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData (dConcepts, ConceptTree); Ընթացակարգի ավարտը
&OnClient ընթացակարգը OnDateOnChange(Element) Fill ConceptTree(); Ընթացակարգի ավարտը
1C:Enterprise հարթակը թույլ է տալիս ծրագրային կերպով ավելացնել և փոխել կառավարվող ձևի տարրերը: Եկեք պարզենք, թե ինչու դա կարող է անհրաժեշտ լինել:
Ձևի ծրագրային փոփոխությունը կարող է պահանջվել մի քանի դեպքերում.
- Ստանդարտ կոնֆիգուրացիաները վերջնականացնելիս՝ հետագա թարմացման ընթացակարգը հեշտացնելու համար: Այս դեպքում կփոխվի միայն ձևի մոդուլը: Մոդուլները շատ ավելի հեշտ են թարմացվում, քան ձևերը:
- Որոշ ընդհանուր ալգորիթմներ իրականացնելիս. Օրինակ, «Օբյեկտների մանրամասների խմբագրման արգելում» ենթահամակարգում կարող է կոճակ ծրագրավորվել ենթահամակարգին միացված բոլոր օբյեկտների համար, որպեսզի հնարավորություն ընձեռվի խմբագրել մանրամասները:
- Որոշ կոնկրետ ալգորիթմներ իրականացնելիս. Օրինակ, Nomenclature գրացուցակում ստեղծվում են դաշտեր լրացուցիչ մանրամասների խմբագրման համար:
Կառավարվող ձևով դուք կարող եք ծրագրային կերպով ավելացնել, փոխել և ջնջել.
- ռեկվիզիտներ;
- տեղական թիմեր;
- տարրեր.
Այս բոլոր գործողությունները հնարավոր են միայն սերվերում:
Ծրագրային ձևափոխումն ունի սահմանափակումներ.
- Դուք կարող եք ջնջել միայն ծրագրով ավելացված մանրամասները/հրամանները/տարրերը: Դուք չեք կարող ծրագրային կերպով ջնջել կոնֆիգուրատորում ստեղծված օբյեկտները:
- Դուք չեք կարող հատկանիշ նշանակել որպես հիմնական:
Ձևի հրամանների փոփոխություն
Կառավարել հրամանների կազմը օբյեկտի համար Կառավարվող ձևկա հավաքածու Թիմեր
Ավելացնել (< ИмяКоманды >)
Քանակ ()
Գտեք (< ИмяКоманды >)
Ջնջել (< Команда >)
Թիմերի հավաքածուն հասանելի է և՛ հաճախորդի, և՛ սերվերի վրա: Դուք կարող եք փոխել հավաքածուն (Ավելացնել() և Ջնջել() մեթոդները միայն սերվերում: Դուք կարող եք որոնել և ստանալ տարրերի քանակը (Գտնել () և Հաշվել () մեթոդները) ինչպես հաճախորդի, այնպես էլ սերվերի վրա:
Որպես ձևի հրամանների հետ աշխատելու օրինակ՝ եկեք ստեղծենք նոր ChangeHistory հրաման՝ «ChangeHistory...» վերնագրով, որը կկանչի մշակիչը։ Ցուցադրման պատմություն(). Ստեղծումը տեղի է ունենում, երբ ձևը բացվում է:
&Սերվերի վրա
Ընթացակարգը WhenCreatingOnServer (ձախողում, ստանդարտ մշակում)
Թիմ = Թիմեր. Ավելացնել ( «Փոփոխությունների պատմություն»);
Թիմ . Գործողություն = ;
Թիմ . Վերնագիր = «Փոփոխությունների պատմություն...».;
Ընթացակարգի ավարտը
&OnClient
Ընթացակարգը Connectable_DisplayHistory (Հրաման)
// հրամանի գործողություններ
Ընթացակարգի ավարտը
Հրամանների մշակիչը պետք է տեղակայված լինի ձևաթղթի վրա և ունենա &OnClient կոմպիլյացիայի հրահանգ:
Ձևի մանրամասների փոփոխություն
Ձևի մանրամասների կազմի ընթերցումը կատարվում է ֆունկցիայի միջոցով Ստացեք մանրամասներ(< Путь >) վերադարձնում է FormAttributes տիպի զանգված: Ֆունկցիայի պարամետրը սահմանում է մայր հատկանիշի ուղին (որպես տող): Եթե պարամետրը բաց է թողնված կամ դատարկ տող է նշված, վերին մակարդակի մանրամասները վերադարձվում են:
Մանրամասների փոփոխությունը կատարվում է մեթոդով Փոխել մանրամասները(<Ավելացված մանրամասներ>, <Շարժական մանրամասներ>) օբյեկտ Կառավարվող ձև. Դեպի պարամետրեր Ավելացված մանրամասներԵվ Շարժական մանրամասներՓոխանցվում են Form Attributes տեսակի տարրերով զանգվածներ:
Ուշադրություն.
Մանրամասների կազմը փոխելու գործընթացը բավականին ռեսուրսային է։ Ձևը իրականում վերստեղծվում է: Այս առումով ձևի մանրամասների հետ աշխատանքը կատարվում է խմբաքանակի ռեժիմով:
Եկեք ստեղծենք նոր ձևի հատկանիշ Գնորդ անունով.
AddedDetails = Նոր զանգված;
Ավելացված մանրամասներ: Ավելացնել (Նոր ձևի հատկանիշներ(«Գնորդ», Նոր տիպի նկարագրություն («DirectoryLink. Կողմնակիցներ»), «Հաճախորդ»));// Մանրամասների կազմության փոփոխություններ
);
Ձևի տարրերի փոփոխություն
Վերահսկել օբյեկտի տարրերի կազմը Կառավարվող ձևկա հավաքածու Տարրեր. Հավաքածուն ունի մի քանի մեթոդներ.
Տեղադրեք (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)
Ավելացնել (< Имя>, < ТипЭлемента>, < Родитель >)
Քանակ ()
Գտեք (< Имя >)
Տեղափոխել (< Элемент>, < Родитель>, < МестоРасположения >)
Ջնջել (< Элемент >)
Նյութերի հավաքածուն հասանելի է և՛ հաճախորդի, և՛ սերվերի վրա: Փոփոխել հավաքածուն (Տեղադրել մեթոդներ () , Ավելացնել () , Տեղափոխել () և Ջնջել () ) հասանելի են միայն սերվերում։ Դուք կարող եք որոնել և ստանալ տարրերի քանակը (Գտնել () և Հաշվել () մեթոդները) ինչպես հաճախորդի, այնպես էլ սերվերի վրա: Հավաքածուի տարրերը կարող են լինել.
- FormGroup;
- FormTable;
- FormField;
- Ձևի կոճակ:
Դուք կարող եք ծրագրային կերպով նշանակել իրադարձությունների մշակիչներ՝ տարրեր ձևավորելու համար: Մեթոդը նախատեսված է այս նպատակների համար SetAction (< ИмяСобытия>, < Действие >) .
Դիտարկենք հրամանների, մանրամասների և ձևի տարրերի հետ աշխատելու ամենատարածված օրինակները:
Հրամանի և դրա հետ կապված կոճակի ավելացում.
// Ստեղծեք հրաման
Թիմ = Թիմեր. Ավելացնել ( «Փոփոխությունների պատմություն»);
Թիմ . Գործողություն = «Plug-in_Display History»; // Ձևը պետք է պարունակի նշված անունով ընթացակարգ
Թիմ . Վերնագիր = «Փոփոխությունների պատմություն...».;
// Ստեղծեք կոճակ և կապեք այն հրամանի հետ
Տարր = Նյութեր. Ավելացնել ( «Փոփոխությունների պատմություն», Type("FormButton" ));
Element.CommandName = «Փոփոխությունների պատմություն»;
Հատկանիշի և հարակից մուտքագրման դաշտի ավելացում.
// Ավելացված մանրամասների նկարագրություն
AddedDetails = Նոր զանգված;
Ավելացված մանրամասներ: Ավելացնել(Նոր ձևաթղթեր («Գնորդ», նոր տեսակի նկարագրություն ( «DirectoryLink. Counterparties»), «Հաճախորդ» ));
// Մանրամասների կազմի փոփոխություն
ChangeDetails (Ավելացված մանրամասներ);
// Մուտքային դաշտի ստեղծում և ատրիբուտների հետ կապում
Տարր = Նյութեր. Ավելացնել ("Գնորդ" , Տիպ ("FormField" ));
Տարր . Դիտել = FormFieldView: Մուտքի դաշտ;
Տարր . PathToData= «Գնորդ» ;
Իրադարձությունների մշակիչի նշանակում ձևի տարրին.
ՆյութՀաճախորդ. SetAction(«Երբ այն փոխվում է», «Connected_BuyerOnChange»);
&OnClient
Ընթացակարգը Connected_BuyerOnChange(Տարր)
// Իրադարձությունների գործողություններ
Ընթացակարգի ավարտը
Ուշադրություն.
Ընթացակարգեր, որոնք դրված են որպես իրադարձությունների մշակիչներ՝ օգտագործելով մեթոդը SetAction (), խորհուրդ է տրվում տեղադրել Connectable_ նախածանցը։
Ուշադրություն.
Դուք կարող եք ներբեռնել մշակումը ծրագրային որոնման և կառավարվող ձևի մանրամասների, հրամանների և տարրերի փոփոխման օրինակներով:
Ձևի մանրամասները ապահովում են դրա կապը տվյալների հետ: Այս դեպքում մանրամասներից մեկը (և միայն մեկը) կարող է նշանակվել որպես հիմնական. դա կարող է լինել պարտադիր չէ տվյալների տեսակը, որի վրա մենք նկարում ենք ձևը: Բայց ձևի վարքագիծը կախված կլինի հիմնական հատկանիշի տվյալների տեսակից: Բացի ձևի վարքագիծը փոխելուց, ձևի մոդուլի համատեքստը փոխվում է: Ձևի մեթոդների և հատկությունների հետ մեկտեղ նրանում հասանելի են դառնում հիմնական հատկանիշի արժեք հանդիսացող օբյեկտի մեթոդներն ու հատկությունները։ Կարևոր է, որ «Ազատ ձև» տիպի ձևերը չունենան հիմնական մանրամասներ: Այս դեպքում ձևի վարքագիծը որոշվում է միայն օգտագործողի կարգավորումներով: Եկեք քննարկենք հիմնական մանրամասների վերաբերյալ հարցերը:
Հարց 10.05 քննության 1C. Պլատֆորմի պրոֆեսիոնալ. Ինչի համար է օգտագործվում հիմնական ձևի հատկանիշը:
- Սահմանում է տվյալների աղբյուրը ձևի համար որպես ամբողջություն
- Սահմանում է հարթակի ստանդարտ հնարավորությունները հիմնական հատկանիշում նշված տիպի տվյալների հետ ձևի հետ աշխատելու համար
- Տրամադրել տեղական ձևի համատեքստից օբյեկտի մանրամասներին ծրագրային մուտք գործելու հնարավորություն
- Ապահովում է օբյեկտի մանրամասների պատկերացում ձևի երկխոսության վրա
- 2-ը և 3-ը ճիշտ են
- 1-ը և 2-ը ճիշտ են
Ճիշտ պատասխանը թիվ վեցն է, տես վերևում։
Հարց 1C քննության 10.06. Պլատֆորմ Մասնագիտական. Ինչի՞ համար են անհրաժեշտ ձևի մանրամասները:
- Տվյալների բովանդակությունը նկարագրելու համար, որը ցուցադրվում, խմբագրվում կամ պահվում է ձևով
- Տվյալները ձևով ցուցադրելու և խմբագրելու համար
- 1-ը և 2-ը ճիշտ են
Ճիշտ պատասխանը երրորդն է՝ երկուսն էլ։
Հարց 1C քննության 10.07. Պլատֆորմ Պրոֆեսիոնալ. Հիմնական հատկանիշները կամայական վերահսկվող ձևին վերագրելու համար...
- Դուք պետք է նշեք «Հիմնական մանրամասներ» վանդակը ձևի ատրիբուտների հատկություններում
- անհրաժեշտ է լրացնել ձևի «Տվյալներ» հատկությունը՝ ընտրելով ձևի պահանջվող հատկանիշը
Ճիշտ պատասխանը երկրորդն է.
Հարց 10.08 քննության 1C. Պլատֆորմ Մասնագիտական. Հիմնական մանրամասները կամայական կանոնավոր ձևի վերագրելու համար...- ձևը պետք է դարձնել հիմնական, հիմնական մանրամասները որոշվում են ավտոմատ կերպով
- Դուք պետք է նշեք «Հիմնական մանրամասներ» վանդակը ձևի ատրիբուտների հատկություններում
- դուք պետք է գնաք «Խմբագրել» մենյու, «Հիմնական մանրամասներ» և ընտրեք ցանկալի արժեքը
- անհրաժեշտ է լրացնել ձևի «Տվյալներ» հատկությունը՝ ընտրելով ձևի պահանջվող հատկանիշը
Չորրորդ ճիշտ պատասխանն է.
Հիմնական մանրամասները ընդգծված են թավով.
Հարց 10.09 քննության 1C. Պլատֆորմ Մասնագիտական. Եթե կա մեկ հիմնական ձևի հատկանիշ, հնարավո՞ր է ավելացնել մեկ այլ հիմնական հատկանիշ:- Սա անհնար է
- Դա հնարավոր է ձևի հատկանիշի հատկությանը համապատասխան արժեք վերագրելով
- Դա հնարավոր է միայն ծրագրային կերպով՝ «Ձև» օբյեկտ մուտք գործելիս
- Դա հնարավոր է` համապատասխան ձևի հատկությանը ևս մեկ արժեք ավելացնելով
Ճիշտ պատասխանն առաջինն է, կա խիստ մեկ հիմնական պահանջ, քանի որ կապը օբյեկտի հետ պետք է լինի միանշանակ.
Հարց 10.113 քննության 1C. Պլատֆորմ պրոֆեսիոնալ: Նկարում ներկայացված ձևի մանրամասներից ո՞րն է հիմնականը:
- Արտարժույթի փոխարժեքների ցանկ
- DirectoryObject
- Գրացուցակի ձևաթղթերը հիմնական մանրամասներ չունեն
- Գրացուցակի ձևաթղթերն ունեն բոլոր հիմնական մանրամասները
Ձևը կառավարվում է ձևի տարբեր տարրերի միջոցով, որոնք հիերարխիկորեն տեղակայված են ներդիրում Տարրերձևավորող. Ամենակարևոր տարրը հենց ձևն է, որը գտնվում է տարրերի հիերարխիայի վերևում, իսկ մնացած տարրերը ենթակա են դրան։
Ձևի բոլոր տարրերը կարելի է բաժանել հինգ խմբի՝ դաշտեր, խմբավորման տարրեր, կոճակներ, զարդեր և աղյուսակներ: Իմ հոդվածներում ես կվերլուծեմ խմբերից յուրաքանչյուրը։ Այս հոդվածում մենք կսկսենք ուսումնասիրել դաշտային տարրի տեսակներից մեկը. մուտքի դաշտ, բայց մինչ այդ մենք կսովորենք, թե ինչպես ավելացնել տարր ձևին:
Տարրերի ավելացում ձևի մեջ
Դա արվում է բավականին պարզ. անհրաժեշտ է ընտրել տարրը Ձև Form Design Elements պատուհանում և սեղմեք «Ավելացնել» կոճակը: Դրանից հետո կբացվի պատուհան, որտեղ դուք պետք է ընտրեք ցանկալի տարրի տեսակը
Ընտրելուց հետո ցանկալի տարրը կհայտնվի պատուհանում Տարրեր.
Կառավարվող ձևի տարր Դաշտ
Եկեք նայենք կառավարվող ձևի տարրին Դաշտ. Այս տարրը անհրաժեշտ է ձևաթղթում տեղեկատվություն մուտքագրելու համար: Եվ նաև ցանկացած տեղեկատվություն ցուցադրելու համար: Այս տարրը ձևաթղթում ավելացնելուց հետո ձևի տարրի հատկությունների գունապնակը կբացվի աջ կողմում: Առայժմ ձեզ պետք է հետաքրքրի երկու հատկություն՝ DataPath և View:
DataPath հատկությունում մշակողը կարող է ձևի տարրը կապել ցանկալի ձևի հատկանիշի հետ: Խնդրում ենք նկատի ունենալ, որ տարրը ավելացնելուց հետո Մուտքի դաշտձևի վրա այն չի ցուցադրվել հենց ձևի վրա: Դա տեղի ունեցավ, քանի որ մեր նոր տարրը կապված չէ . Օրինակ՝ մշակման ձևի վրա ես ստեղծել եմ մի քանի ատրիբուտ՝ տարբեր պարզունակ տիպերով և մեկ հատկանիշ՝ հղումային տիպով։
Այժմ եկեք միացնենք մեր վերջերս ավելացված ձևի տարրը մանրամասներից մեկի հետ: Դա անելու համար ընտրեք ցանկալի հատկանիշը տարրի PathKData հատկությունից:
Դրանից հետո DataPath և View հատկությունները կլրացվեն, և տարրն ինքնին կցուցադրվի ձևի տեսքով:
Ուշադրություն դարձրեք տարրի հատկությանը Դիտել. Այս հատկությունը որոշում է մուտքագրման դաշտի ֆունկցիոնալությունը: Այս գույքի համար կարող եք ընտրել տարբեր արժեքներ:
Կախված ընտրված արժեքից, կորոշվի ֆունկցիոնալությունը: Վերևի նկարներում ընտրված արժեքն է՝ մուտքի դաշտ, այսինքն. մենք կարող ենք մուտքագրել ցանկացած արժեք այս մուտքագրման դաշտում, և եթե ընտրենք արժեք պիտակի դաշտ, ապա մենք չենք կարողանա որևէ բան մուտքագրել:
Այս գույքի արժեքը ԴիտելՄուտքային դաշտերը հարմար են ընտրելու համար, երբ պարզապես անհրաժեշտ է օգտատիրոջը ցույց տալ օգնության մասին տեղեկությունները:
Հիմա եկեք ավելացնենք նոր ձևի տարր՝ տիպով Մուտքի դաշտև միացրեք այն հենարանների հետ Մանրամասն Ամսաթիվմեզ արդեն ծանոթ DataPath հատկության միջոցով
Ինչպես տեսնում եք, մուտքագրման դաշտի տեսքը փոխվել է, և View հատկության համար արժեքների հնարավոր ընտրությունը նույնպես կփոխվի:
Այսպիսով, մենք եզրակացնում ենք, որ մուտքագրման դաշտի ֆունկցիոնալությունը կախված է հատկանիշի տեսակից:
Տիպի հետ հենարանների համար ԲուլյանՀետևյալ View գույքի արժեքները հասանելի կլինեն:
Իսկ հղման տեսակ ունեցող ատրիբուտների համար հասանելի կլինեն View հատկության այլ արժեքներ:
Գործնական օրինակների օգտագործմամբ ձևի տարրերի հետ ավելի մանրամասն աշխատանքը տրված է «Զարգացման հիմունքներ 1C-ում. տաքսի. Կառավարվող հավելվածի մշակում 12 քայլով»:
Երբեմն թվում է, թե 1C-ում ծրագրավորման լեզուն սովորելը բարդ և դժվար է: Իրականում, ծրագրավորումը 1C-ում հեշտ է: Իմ գրքերը կօգնեն ձեզ արագ և հեշտությամբ յուրացնել ծրագրավորումը 1C-ում և «Զարգացման հիմունքները 1C-ում. տաքսիում»
Սովորեք ծրագրավորում 1C-ում իմ «Ծրագրավորում 1C-ում 11 քայլով» գրքի օգնությամբ
- Ոչ բարդ տեխնիկական պայմաններ:
- Ավելի քան 700 էջ գործնական նյութ:
- Յուրաքանչյուր առաջադրանք ուղեկցվում է նկարով (սքրինշոթ):
- Խնդիրների հավաքածու տնային աշխատանքների համար:
- Գիրքը գրված է պարզ և պարզ լեզվով` սկսնակների համար:
Այս գիրքը հարմար է նրանց համար, ովքեր արդեն սկսել են ծրագրավորել և որոշակի դժվարություններ ունեն այս թեմայի հետ կապված, և նրանց համար, ովքեր երկար ժամանակ ծրագրավորում են, բայց երբեք չեն աշխատել 1C կառավարվող ձևերի հետ:
- Առանց բարդ տեխնիկական պայմանների;
- Ավելի քան 600 էջ գործնական նյութ;
- Յուրաքանչյուր օրինակ ուղեկցվում է նկարով (սքրինշոթ);
- Գիրքը ուղարկվում է էլեկտրոնային փոստով PDF ձևաչափով: Կարող է բացվել ցանկացած սարքի վրա:
Պրոմո կոդ 15% զեղչի համար - 48PVXHeYu
Եթե այս դասը օգնեց ձեզ լուծել որևէ խնդիր, ձեզ դուր եկավ կամ օգտակար համարեց, ապա կարող եք աջակցել իմ նախագծին՝ նվիրաբերելով ցանկացած գումար.
Դուք կարող եք ձեռքով վճարել.
Yandex.Money - 410012882996301
Վեբ փող - R955262494655
Միացե՛ք իմ խմբերին։
Եվ տվյալների փոխանցման օբյեկտ կոդի կառուցվածքին, վերահսկվող ձև 1C 8.2 միջավայրում:
Ներածություն
Սկսենք «կառավարվող ձև» հասկացության և 1C հարթակի հարակից հասկացությունների կարճ նկարագրությունից: Պլատֆորմի գիտակները կարող են ցանկանալ բաց թողնել այս բաժինը:2008 թվականին հասանելի դարձավ 1C պլատֆորմի նոր տարբերակը՝ Enterprise 8.2 (այսուհետ՝ Կառավարվող հավելված), որն ամբողջությամբ փոխում է ինտերֆեյսի հետ աշխատանքի ողջ շերտը։ Սա ներառում է հրամանի միջերեսը, ձևերը և պատուհանների համակարգը: Միևնույն ժամանակ, ոչ միայն փոխվում է կոնֆիգուրացիայի մեջ օգտագործողի միջերեսը մշակելու մոդելը, այլև առաջարկվում է նոր ճարտարապետություն՝ հաճախորդի հավելվածի և սերվերի միջև ֆունկցիոնալությունը բաժանելու համար:
Կառավարվող հավելվածն աջակցում է հաճախորդների հետևյալ տեսակներին.
- Հաստ հաճախորդ (նորմալ և կառավարվող գործարկման ռեժիմ)
- Նիհար հաճախորդ
- Վեբ հաճախորդ
Մշակողի համար կառավարվող ձևերի հիմնական տարբերությունները.
- Կառուցվածքի դեկլարատիվ, ոչ թե «պիքսել առ պիքսել» նկարագրություն: Տարրերի հատուկ տեղադրումն իրականացվում է ավտոմատ կերպով համակարգի կողմից, երբ ձևը ցուցադրվում է:
- Ձևի բոլոր գործառույթները նկարագրված են հետևյալ կերպ մանրամասներԵվ թիմեր. Մանրամասները տվյալներն են, որոնց հետ աշխատում է ձևը, իսկ հրամանները՝ կատարվող գործողությունները:
- Ձևն աշխատում է ինչպես սերվերի, այնպես էլ հաճախորդի վրա:
- Հաճախորդի համատեքստում գրեթե բոլոր հավելվածների տեսակներն անհասանելի են, և, համապատասխանաբար, անհնար է փոխել տվյալները տեղեկատվական բազայում:
- Յուրաքանչյուր մեթոդի կամ ձևի փոփոխականի համար այն պետք է նշվի կազմման հրահանգը, սահմանելով կատարման վայրը (հաճախորդ կամ սերվեր) և մուտք դեպի ձևի համատեքստ:
- &OnClient
- &Սերվերի վրա
- &OnServer Without Context
- &OnClientOnServerWithout Context
Հետագա բոլոր քննարկումները կլինեն նկարազարդման աջ կողմի մասին, այն մասին, թե ինչպես պետք է կառուցվի մոդուլի կոդը և ինչ սկզբունքներ թույլ կտան իրականացնել հաճախորդ-սերվեր արդյունավետ փոխազդեցություն:
Եկեք սահմանենք խնդիրը
Մի քանի տարի է անցել այն պահից, երբ 1C պլատֆորմի նոր տարբերակն ակտիվորեն օգտագործվում է, և բազմաթիվ լուծումներ (կոնֆիգուրացիաներ) թողարկվել են ինչպես 1C-ի, այնպես էլ նրա բազմաթիվ գործընկերների կողմից:Այս ընթացքում մշակողները մշակե՞լ են ընդհանուր ըմբռնում հաճախորդ-սերվեր փոխազդեցության սկզբունքների վերաբերյալ ձևաթղթերի ստեղծման ժամանակ, և արդյոք փոխվե՞լ է ծրագրային մոդուլների ներդրման մոտեցումը նոր ճարտարապետական իրողություններում:
Դիտարկենք կոդի կառուցվածքը (ձևի մոդուլը) նույն ստանդարտ կոնֆիգուրացիայի մի քանի ձևերով և փորձենք գտնել օրինաչափություններ:
Կառուցվածք ասելով մենք հասկանում ենք կոդի բաժիններ (առավել հաճախ դրանք մեկնաբանությունների բլոկներ են), որոնք մշակողի կողմից հատկացվում են մեթոդների խմբավորման և այս մեթոդների կոմպիլացիոն հրահանգների համար:
Օրինակ 1:
Իրադարձությունների մշակողների բաժին Մեթոդ - հաճախորդի վրա Մեթոդ - սերվերի վրա Մեթոդ - հաճախորդի վրա Ծառայությունների ընթացակարգերի և գործառույթների բաժին Մուտքի կառավարման օժանդակ գործառույթներ
Օրինակ 2:
Ծառայության ընթացակարգերը և գործառույթները Վճարային փաստաթղթերի արժեքներ Միջոցառումների մշակողներ
Օրինակ 3:
Սպասարկման ընթացակարգեր սերվերում Սպասարկման ընթացակարգեր հաճախորդի վրա Սպասարկման ընթացակարգեր սերվերում առանց համատեքստի Վերնագրի իրադարձությունների մշակիչներ Հրամանի իրադարձությունների մշակիչներ
Օրինակ 4:
Ընդհանուր նշանակության ընթացակարգեր Ձև իրադարձությունների մշակիչներ «Կոնտակտային տեղեկատվություն» ենթահամակարգի ընթացակարգեր
Ըստ էության, կոդի կառուցվածքը բացակայում է, կամ, մեղմ ասած, նման է 8.1 ձևերին.
- «Գեներալ, ծառայություն, օժանդակ» ոչ տեղեկատվական բառեր:
- Հաճախորդի և սերվերի մեթոդները բաժանելու երկչոտ փորձեր:
- Մեթոդները հաճախ խմբավորվում են ինտերֆեյսի տարրերով «Աշխատանք աղյուսակային մասի հետ Ապրանքներ, կոնտակտային տվյալներ»:
- Մեթոդների և ծածկագրերի խմբերի կամայական դասավորություն: Օրինակ՝ Իրադարձությունների կարգավորիչները կարող են լինել մի ձևով վերևում, մյուսում՝ ներքևում, երրորդում ընդհանրապես չընդգծված լինել և այլն:
- Եվ եկեք չմոռանանք, որ այս ամենը մեկ կոնֆիգուրացիայի շրջանակներում է:
- Այո, կան կոնֆիգուրացիաներ, որոնցում «General, Service, Auxiliary» բառերը միշտ նույն տեղերում են, բայց...
Ինչու՞ է ձեզ անհրաժեշտ կոդի կառուցվածքը:
- Պահպանման պարզեցում.
- Պարզեցնել ուսուցումը:
- Ընդհանուր/կարևոր/հաջող սկզբունքների արձանագրում.
- ... քո տարբերակը
Ինչու՞ չի օգնում 1C-ի զարգացման գոյություն ունեցող ստանդարտը:
Դիտարկենք ITS սկավառակների վրա և տարբեր «Մշակողների ուղեցույցներում...» հրապարակված սկզբունքները, որոնք առաջարկվում են կառավարվող ձև գրելիս:- Նվազագույնի հասցնել սերվերի զանգերի քանակը:
- Սերվերի վրա առավելագույն հաշվարկ:
- Սերվերի ոչ կոնտեքստային զանգերն ավելի արագ են, քան կոնտեքստային:
- Ծրագիր՝ հաշվի առնելով հաճախորդ-սերվեր հաղորդակցությունը:
- եւ այլն։
Դիզայնի նախշեր կամ սերնդային իմաստություն
Հաճախորդ-սերվեր փոխազդեցությունը տասնամյակներ շարունակ օգտագործվել է տարբեր ծրագրային տեխնոլոգիաներում: Նախորդ բաժնում նախանշված հարցերի պատասխանը վաղուց հայտնի է և ամփոփված է երկու հիմնական սկզբունքներում։- Հեռավոր ճակատ(այսուհետ՝ Հեռակա մուտքի միջերես)
- Տվյալների փոխանցման օբյեկտ(այսուհետ՝ Տվյալների փոխանցման օբյեկտ)
- … Հեռավոր մուտքի համար նախատեսված յուրաքանչյուր օբյեկտ պետք է ունենա ցածր հատիկավոր ինտերֆեյս, ինչը նվազագույնի կհասցնի զանգերի քանակը, որոնք անհրաժեշտ են կոնկրետ ընթացակարգ իրականացնելու համար: ... Հաշիվ-ապրանքագիր և դրա բոլոր կետերն առանձին պահանջելու փոխարեն, դուք պետք է մեկ հարցման մեջ կարդացեք և թարմացնեք բոլոր հաշիվ-ապրանքագրերը: Սա ազդում է օբյեկտի ամբողջ կառուցվածքի վրա... Հիշեք՝ հեռահար մուտքի ինտերֆեյս չի պարունակում տիրույթի տրամաբանություն.
- Եթե ես հոգատար մայր լինեի, անպայման երեխայիս կասեի. «Երբեք մի գրիր տվյալների փոխանցման օբյեկտներ»: Շատ դեպքերում տվյալների փոխանցման օբյեկտները ոչ այլ ինչ են, քան ուռած դաշտերի հավաքածու... Այս նողկալի հրեշի արժեքը բացառապես հնարավորության մեջ է մեկ զանգի ընթացքում ցանցի միջոցով փոխանցել բազմաթիվ տեղեկատվություն- տեխնիկա, որը մեծ նշանակություն ունի բաշխված համակարգերի համար:
Կաղապարների օրինակներ 1C հարթակում
Ծրագրային ծրագրավորման ինտերֆեյսը, որը հասանելի է ծրագրավորողին կառավարվող ձևը մշակելիս, պարունակում է այս սկզբունքների բազմաթիվ օրինակներ:Օրինակ, OpenForm() մեթոդը, տիպիկ «կոպիտ» ինտերֆեյս:
OpeningParameters = Նոր կառուցվածք ("Parameter1, Parameter2, Parameter3", Value1, Value2, Value3); Ձև = OpenForm (FormName, OpeningParameters);
Համեմատեք v8.1-ում ընդունված ոճի հետ:
Ձև = GetForm (FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();
Կառավարվող ձևի համատեքստում կան բազմաթիվ «Տվյալների փոխանցման օբյեկտներ»: Դուք կարող եք ընտրել համակարգայինԵվ մշակողի կողմից սահմանված.
Համակարգայինները մոդելավորում են կիրառական օբյեկտ հաճախորդի վրա՝ մեկ կամ մի քանի ձևի տվյալների տարրերի տեսքով: Անհնար է դրանք ստեղծել առանց ձևի մանրամասներին հղում կատարելու:
- DataFormsStructure
- DataFormsCollection
- DataFormStructureWithCollection
- DataShapesTree
- ValueInFormData ()
- FormDataValue ()
- CopyFormData ()
- ValueInFormAttributes ()
- FormAttributesValue()
Օրինակ 1C v8.1:
// հաճախորդի վրա FillUserCache (DepartmentLink) ձևի համատեքստում
Օրինակ 1C v8.2:
// սերվերի վրա ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache (DepartmentRef); ValueВFormAttributes (ProcessingObject, «Object»);
Տվյալների փոխանցման օբյեկտները, որոնց կառուցվածքը որոշվում է մշակողի կողմից, տիպերի փոքր ենթաբազմություն են, որոնք հասանելի են ինչպես հաճախորդի, այնպես էլ սերվերի վրա: Ամենից հաճախ որպես «կոշտ» ինտերֆեյսի մեթոդների պարամետրեր և արդյունքներ օգտագործվում են հետևյալը.
- Պարզունակ տեսակներ (տող, թիվ, բուլյան)
- Կառուցվածք
- Նամակագրություն
- Զանգված
- Հղումներ հավելվածի օբյեկտներին (եզակի նույնացուցիչ և տեքստի ներկայացում)
&OnServerWithoutContext ֆունկցիա ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [պատվեր [սխալի նկարագրություն] Յուրաքանչյուր պատվերի համար Orders Cycle StartTransaction(); Փորձեք DocOb = Order.GetObject(); …. այլ գործողություններ, հնարավոր է ոչ միայն պատվերով... Բացառություն CancelTransaction(); Errors.Insert(Order, ErrorDescription()); Վերջ փորձը; End Cycle; Վերադարձի սխալ; EndFunction // ServerChangeOrderStatus()
Կոդի կառուցվածքը
Հիմնական նպատակները, որոնք պետք է արտացոլի կառավարվող ձևի մոդուլը և մոտենա լուծմանը:- Հաճախորդի և սերվերի կոդի հստակ տարանջատում:Չմոռանանք, որ կատարման պահին դրանք երկու փոխազդող գործընթացներ են, որոնցից յուրաքանչյուրն ունի էապես տարբեր հասանելի գործառույթներ:
- Հեռավոր մուտքի ինտերֆեյսի հստակ նույնականացում, սերվերի ո՞ր մեթոդները կարող են կանչվել հաճախորդից, իսկ որոնք՝ ոչ: Հեռավոր ինտերֆեյսի մեթոդների անվանումները սկսվում են «Սերվեր» նախածանցով: Սա թույլ է տալիս անմիջապես տեսնել հսկողության փոխանցումը սերվերին կոդը կարդալիս և հեշտացնում է համատեքստային օգնության օգտագործումը: Նկատի ունեցեք, որ պաշտոնական առաջարկությունը (ITS) առաջարկում է անվանել մեթոդներ հետֆիքսներով, օրինակ՝ ChangeOrderStatusOnServer(): Այնուամենայնիվ, մենք կրկնում ենք, որ ոչ բոլոր սերվերի մեթոդները կարող են կանչվել հաճախորդից, և, հետևաբար, տրամաբանական հասանելիությունն ավելի կարևոր է, քան կոմպիլյացիայի գտնվելու վայրը: Հետևաբար, «Սերվեր» նախածանցով մենք նշում ենք միայն հաճախորդին հասանելի մեթոդները, եկեք անվանենք մեթոդի օրինակ ServerChangeOrderStatus():
- Ընթեռնելիություն.Ճաշակի հարց է, մենք ընդունում ենք պատվերը, երբ մոդուլը սկսվում է սերվերի վրա ձև ստեղծելու ընթացակարգերով և հեռահար մուտքի մեթոդներով:
- Պահպանելիություն.Նոր կոդ ավելացնելու համար պետք է լինի հստակ տեղ: Կարևոր կետն այն է, որ մոդուլի վերջում ավելացվում են կոնֆիգուրատորի կողմից ավտոմատ կերպով ստեղծված մեթոդի կաղապարներ: Քանի որ ձևի տարրերի համար իրադարձությունների մշակիչները ամենից հաճախ ավտոմատ կերպով ստեղծվում են, համապատասխան բլոկը գտնվում է վերջին տեղում, որպեսզի յուրաքանչյուր մշակիչ չքաշվի մոդուլի մեկ այլ տեղ:
- Գրաֆիկական տարբերակ – հստակ ցույց է տալիս կատարման հիմնական հոսքը:
- Տեքստի տարբերակը ձևանմուշի ձևավորման օրինակ է՝ կառուցվածքը նոր ձևի մոդուլում արագ տեղադրելու համար:
//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="«Ամսաթիվ =»"/> // <Описание> // // //////////////////////////////////////////// ////////////////////////// // ՄՈԴՈՒԼԻ ՓՈՓՈԽԱԿԱՆՆԵՐ ////////////////// /////////////////////////////////////////////////////////////////////// ////////// // ՍԵՐՎԵՐԻ ՄԱՍԻՆ //******** ՍԵՐՎԵՐԻ ՎՐԱ ԷՐԴԵՍՏՆԵՐԸ ******* &Սերվերի վրա Սերվերի վրա ստեղծման գործընթացի մասին (Խափանում, ստանդարտ մշակում) / /Տեղադրեք մշակողի բովանդակությունը Գործընթացի ավարտ //******* ՀԵՌԱԿԱ ՄՈՒՏՔԻ ԻՆՏԵՐՖԵՅՍ ******* //******** ԲԻԶՆԵՍ ՏՐԱՄԱԲԱՆՈՒԹՅՈՒՆԸ ՍԵՐՎԵՐԻ ՎՐԱ ******* ///////// //////////////////////////////////////// /////// /////////////////// // ՀԱՃԱԽՈՐԴԻ ԵՎ ՍԵՐՎԵՐԻ ԸՆԴՀԱՆՈՒՐ ՄԵԹՈԴՆԵՐԸ /////////////// /////// ////////////////////////////////////////// ///// //////// // ՀԱՃԱԽՈՐԴԻ ՄԱՍԻՆ //******** ԲԻԶՆԵՍ ՏՐԱՄԱԲԱՆՈՒԹՅՈՒՆԸ ՀԱՃԱԽՈՐԴԻ ՎՐԱ ******* //******** ԹԻՄ * ****** //******** ՀԱՃԱԽՈՐԴԻ ՄԻՋՈՑԱՌՈՒՄՆԵՐ ******* ///////////////////////// ///// ////////////////////////////////////////////////////////////// // / / ՀԻՄՆԱԿԱՆ ԾՐԱԳՐԻ ՕՊԵՐԱՏՈՐՆԵՐ
Առնչվող հարցեր
Եզրափակելով, մենք ուրվագծելու ենք մի քանի ոլորտներ, որոնց մասին օգտակար է մտածել հաճախորդ-սերվեր փոխազդեցության ծրագրավորման ժամանակ:- Հեռավոր մուտքի ինտերֆեյսի իրականացման ընտրանքներ. Ասինխրոնություն, մանրամասնության մակարդակ...
- Քեշավորում. 1C-ն անհաջող ճարտարապետական որոշում է կայացրել՝ ներմուծելով քեշավորումը միայն սովորական մոդուլների կանչման մեթոդների մակարդակում և չտրամադրելով վերահսկման հնարավորություններ (համապատասխանության ժամանակ, վերակայում ըստ պահանջի):
- Սերվերի անուղղակի զանգեր. Մի մոռացեք տեխնոլոգիական առանձնահատկությունների մասին, հաճախորդի վրա շատ «անվնաս» գործողություններ հրահրում են հարթակին կապ հաստատել սերվերի հետ:
