Ձևի հիմնական հատկանիշը. Հիմնական ձևի հատկանիշը Ինչպես ավելացնել նոր հատկանիշ 1-ում

Եվ տվյալների փոխանցման օբյեկտ կոդի կառուցվածքին, կառավարվող ձևշրջակա միջավայրում 1C 8.2.

Ներածություն

Սկսենք «կառավարվող ձև» հասկացության և 1C հարթակի հարակից հասկացությունների կարճ նկարագրությունից: Պլատֆորմի փորձագետները կարող են բաց թողնել այս բաժինը:

Հասանելի է դարձել 2008թ նոր տարբերակհարթակ 1C. Ձեռնարկություն 8.2 (այսուհետ՝ Կառավարվող հավելված), որն ամբողջությամբ փոխում է ինտերֆեյսի հետ աշխատանքի ամբողջ շերտը: Սա ներառում է հրամանի միջերեսը, ձևերը և պատուհանների համակարգը: Սա ոչ միայն փոխում է զարգացման մոդելը օգտագործողի ինտերֆեյսկոնֆիգուրացիայի մեջ, բայց նաև առաջարկում է նոր ճարտարապետություն հաճախորդի հավելվածի և սերվերի միջև ֆունկցիոնալությունը բաժանելու համար:
Կառավարվող հավելվածն աջակցում է հաճախորդների հետևյալ տեսակներին.

  • Հաստ հաճախորդ (նորմալ և կառավարվող գործարկման ռեժիմ)
  • Նիհար հաճախորդ
  • Վեբ հաճախորդ
Կառավարվող հավելվածն օգտագործում է կառուցված ձևեր նոր տեխնոլոգիա. Նրանք կոչվում են Կառավարվող ձևեր. Անցումը հեշտացնելու համար նախկին ձևերը (այսպես կոչված. կանոնավոր ձևեր) նույնպես աջակցվում են, բայց դրանց ֆունկցիոնալությունը չի մշակվում, և դրանք հասանելի են միայն գերհաճախորդի գործարկման ռեժիմում:
Մշակողի համար կառավարվող ձևերի հիմնական տարբերությունները.
  • Կառուցվածքի դեկլարատիվ, ոչ թե «պիքսելներով» նկարագրությունը։ Տարրերի հատուկ տեղադրումը կատարվում է ավտոմատ կերպով համակարգի կողմից, երբ ձևը ցուցադրվում է:
  • Ձևի բոլոր գործառույթները նկարագրված են ձևաթղթում մանրամասներԵվ հրամաններ. Մանրամասները տվյալներն են, որոնց հետ աշխատում է ձևը, իսկ հրամանները՝ կատարված գործողությունները:
  • Ձևը կատարվում է ինչպես սերվերի, այնպես էլ հաճախորդի վրա:
  • Հաճախորդի համատեքստում գրեթե բոլոր հավելվածների տեսակները հասանելի չեն, և, համապատասխանաբար, անհնար է փոխել տվյալները ինֆոբազայում:
  • Յուրաքանչյուր մեթոդի կամ ձևի փոփոխականի համար այն պետք է նշվի կազմման հրահանգը A, որը սահմանում է կատարման վայրը (հաճախորդ կամ սերվեր) և մուտքը ձևի համատեքստ:
Ահա ձևի մեթոդները կազմելու հրահանգները.
  • &AtClient
  • &Սերվերի վրա
  • &OnServerWithoutContext
  • &Հաճախորդում Առանց Համատեքստի Սերվերում
Եկեք լուսաբանենք վերը նշվածը: Սքրինշոթը ցույց է տալիս կառավարվող ձևի և դրա մոդուլի օրինակ մշակման ռեժիմում: Գտեք դեկլարատիվ նկարագրություն, հենարաններ, կազմման հրահանգներ և այլն:

Հետագա բոլոր քննարկումները կլինեն նկարազարդման աջ կողմի մասին, այն մասին, թե ինչպես պետք է կառուցվի մոդուլի կոդը և ինչ սկզբունքներ թույլ կտան իրականացնել հաճախորդ-սերվեր արդյունավետ փոխազդեցություն:

Եկեք սահմանենք խնդիրը

Մի քանի տարի է անցել այն պահից, երբ 1C պլատֆորմի նոր տարբերակը ակտիվորեն օգտագործվում է, և բազմաթիվ լուծումներ (կոնֆիգուրացիաներ) թողարկվել են ինչպես 1C-ի, այնպես էլ նրա բազմաթիվ գործընկերների կողմից:
Արդյո՞ք մշակողները մշակել են ընդհանուր ըմբռնում հաճախորդ-սերվեր փոխազդեցության սկզբունքների վերաբերյալ այս ընթացքում ձևաթղթեր ստեղծելիս, և փոխվե՞լ է արդյո՞ք իրականացման մոտեցումը: ծրագրային մոդուլներնոր ճարտարապետական ​​իրողություններո՞ւմ։

Դիտարկենք կոդի կառուցվածքը (ձևի մոդուլը) նույն բնորոշ կոնֆիգուրացիայի մի քանի ձևերով և փորձեք գտնել օրինաչափություններ:
Կառուցվածքի տակ մենք նկատի ունենք կոդի բաժիններ (առավել հաճախ դրանք մեկնաբանությունների բլոկներ են), որոնք հատկացվում են մշակողի կողմից՝ խմբավորելու մեթոդները և հրահանգները՝ այդ մեթոդները կազմելու համար։
Օրինակ 1:
Իրադարձությունների մշակման բաժին Մեթոդ - հաճախորդի վրա Մեթոդ - սերվերի վրա Մեթոդ - հաճախորդի վրա Ծառայությունների ընթացակարգերի և գործառույթների բաժին Մուտքի կառավարման օժանդակ գործառույթներ
Օրինակ 2:
Սպասարկման ընթացակարգեր և գործառույթներ Վճարային փաստաթղթեր Արժեքավոր արժեքներ Իրադարձությունների մշակողներ
Օրինակ 3:
Սպասարկման ընթացակարգեր սերվերում Սպասարկման ընթացակարգեր հաճախորդի վրա Սպասարկման ընթացակարգեր սերվերում առանց համատեքստի Վերնագրի իրադարձությունների մշակիչներ Հրամանի իրադարձությունների մշակիչներ
Օրինակ 4:
Ընդհանուր նշանակության ընթացակարգեր Ձև իրադարձությունների մշակիչներ «Կոնտակտային տեղեկատվություն» ենթահամակարգի ընթացակարգեր
Փաստորեն, կոդի կառուցվածքը բացակայում է, կամ, մեղմ ասած, նման է 8.1 ձևերին.

  • Ոչ տեղեկատվական բառեր «Գեներալ, ծառայություն, օժանդակ».
  • Հաճախորդի և սերվերի մեթոդները բաժանելու երկչոտ փորձեր:
  • Հաճախ մեթոդները խմբավորվում են ինտերֆեյսի տարրերով «Աշխատում է աղյուսակային մասԱպրանքներ, Կոնտակտային տվյալներ»:
  • Մեթոդների և ծածկագրերի խմբերի կամայական դասավորություն: Օրինակ, Event Handlers-ը կարող է լինել մի ձևով վերևում, մյուսով ներքևում, երրորդում ընդհանրապես չընդգծված լինել և այլն:
  • Եվ եկեք չմոռանանք, որ այս ամենը նույն կոնֆիգուրացիայի մեջ է:
  • Այո, կան կոնֆիգուրացիաներ, որոնցում «Գեներալ, ծառայություն, օժանդակ» բառերը միշտ նույն տեղերում են, բայց ...
Ինչու՞ է ձեզ անհրաժեշտ կոդի կառուցվածքը:
  • Պահպանման պարզեցում.
  • Պարզեցնել ուսուցումը:
  • Ընդհանուր/կարևոր/հաջող սկզբունքների ամրագրում.
  • …ձեր տարբերակը
Ինչու՞ 1C-ից գոյություն ունեցող զարգացման ստանդարտը չի օգնում:
Դիտարկենք այն սկզբունքները, որոնք հրապարակվել են ITS սկավառակների վրա և տարբեր «Developer's Guides...»-ում, որոնք առաջարկվում են կառավարվող ձև գրելիս:
  • Նվազագույնի հասցնել սերվերի զանգերի քանակը:
  • Սերվերի վրա առավելագույն հաշվարկ:
  • Սերվերի ոչ կոնտեքստային զանգերն ավելի արագ են, քան համատեքստային զանգերը:
  • Ծրագիր՝ հաշվի առնելով հաճախորդ-սերվեր փոխազդեցությունը:
  • եւ այլն։
Սրանք կարգախոսներ են, որոնք բացարձակապես ճիշտ են, բայց ինչպե՞ս կարող են դրանք իրագործվել։ Ինչպե՞ս նվազագույնի հասցնել զանգերի քանակը, ի՞նչ է նշանակում ծրագրավորել հաճախորդ-սերվեր ռեժիմում:

Դիզայնի նախշեր կամ սերնդային իմաստություն

Հաճախորդ-սերվեր փոխազդեցությունը տասնամյակներ շարունակ օգտագործվել է տարբեր ծրագրային տեխնոլոգիաներում: Նախորդ բաժնում նախանշված հարցերի պատասխանը վաղուց հայտնի է և ամփոփված է երկու հիմնական սկզբունքներում։
  • Հեռավոր ճակատ(այսուհետ՝ Ինտերֆեյս հեռավոր մուտք)
  • Տվյալների փոխանցման օբյեկտ(այսուհետ՝ Տվյալների փոխանցման օբյեկտ)
Խոսք Մարտին Ֆաուլերին, այս սկզբունքների նրա նկարագրությունը.
  • հեռավոր մուտքի համար պոտենցիալ նախատեսված յուրաքանչյուր օբյեկտ պետք է ունենա ցածր հատիկավոր ինտերֆեյս, ինչը նվազագույնի կհասցնի զանգերի քանակը, որոնք անհրաժեշտ են որոշակի ընթացակարգի իրականացման համար: … Հաշիվը և դրա բոլոր կետերը առանձին պահանջելու փոխարեն, անհրաժեշտ է մեկ զանգով կարդալ և թարմացնել հաշիվ-ապրանքագրի բոլոր կետերը: Սա ազդում է օբյեկտի ամբողջ կառուցվածքի վրա... Հիշեք՝ հեռակառավարման ինտերֆեյսը չի պարունակում տիրույթի տրամաբանություն.
  • Եթե ​​ես հոգատար մայր լինեի, անպայման կասեի երեխայիս. «Երբեք մի գրիր տվյալների փոխանցման օբյեկտներ»: Շատ դեպքերում տվյալների միգրացիայի օբյեկտները ոչ այլ ինչ են, քան ուռած դաշտային հավաքածու… Այս նողկալի հրեշի արժեքը բացառապես հնարավորության մեջ է մեկ զանգի ընթացքում ցանցի միջոցով փոխանցել բազմաթիվ տեղեկություններ- տեխնիկա, որը մեծ նշանակություն ունի բաշխված համակարգերի համար:
Կաղապարների օրինակներ 1C հարթակում
API-ը, որը հասանելի է ծրագրավորողին, երբ մշակում է կառավարվող ձև, պարունակում է այս սկզբունքների բազմաթիվ օրինակներ:
Օրինակ՝ OpenForm() մեթոդը՝ տիպիկ «կոպիտ» ինտերֆեյս։
OpenParameters = Նոր կառուցվածք ("Parameter1, Parameter2, Parameter3", Value1, Value2, Value3); Ձև = OpenForm (FormName, OpenParameters);
Համեմատեք v8.1 ոճի հետ:
Ձև = GetForm (FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

Կառավարվող ձևի համատեքստում «Տվյալների փոխանցման օբյեկտների» մի շարք: Կարելի է տարբերել համակարգայինԵվ մշակողի կողմից սահմանված.
Համակարգայինները մոդելավորում են կիրառական օբյեկտ հաճախորդի վրա՝ մեկ կամ մի քանի ձևի տվյալների տարրերի տեսքով: Դուք չեք կարող դրանք ստեղծել ձևի մանրամասներին կապելուց դուրս:

  • DataFormsStructure
  • DataFormsCollection
  • DataFormStructureCollection
  • DataFormsTree
Տվյալների փոխանցման համակարգի օբյեկտների փոխակերպումը հավելվածի տեսակների և հակառակը կատարվում է հետևյալ մեթոդներով.
  • ValueVDataForm()
  • FormDataToValue()
  • CopyFormData ()
  • ValueVFormProps()
  • FormAttributeToValue()
Հաճախ հարմարեցման ժամանակ օգտագործվում է հստակ փոխակերպում առկա լուծում. Մեթոդները կարող են ակնկալել (առանձնահատկությունների) մուտքագրման պարամետրեր, ինչպիսիք են ValueTable-ը, այլ ոչ թե FormDataCollection-ը, կամ մեթոդը սահմանվել է հավելվածի օբյեկտի համատեքստում և անհասանելի է դարձել ձևից ուղղակի զանգի համար:
Օրինակ 1C v8.1:
// հաճախորդի վրա FillUsersCache (DepartmentReference) ձևի համատեքստում
Օրինակ 1C v8.2:
// սերվերի վրա ProcessingObject = FormAttributeToValue («Օբյեկտ») ձևի համատեքստում: ProcessingObject.FillCacheUsers (DepartmentReference); ValueVFormAttribute (ProcessingObject, «Object»);

Տվյալների միգրացիայի օբյեկտները, որոնց կառուցվածքը սահմանվում է մշակողի կողմից, տիպերի փոքր ենթաբազմություն են, որոնք հասանելի են ինչպես հաճախորդի, այնպես էլ սերվերի վրա: Ամենից հաճախ, որպես «կոպիտ» ինտերֆեյսի մեթոդների պարամետրեր և արդյունքներ, օգտագործվում են հետևյալը.

  • Պարզունակ տեսակներ (տող, թիվ, բուլյան)
  • Կառուցվածք
  • Նամակագրություն
  • զանգված
  • Հղումներ հավելվածի օբյեկտներին (եզակի նույնացուցիչ և տեքստի ներկայացում)
Օրինակ՝ մեթոդն ընդունում է կարգավիճակը փոխելու պատվերների ցանկը և հաճախորդին վերադարձնում է սխալների նկարագրությունը:
&OnServerWithoutContext ֆունկցիա ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [պատվեր [սխալի նկարագրություն] Յուրաքանչյուր պատվերի համար Orders From Orders Loop StartTransaction(); Փորձ DocOb = Order.GetObject(); …. այլ գործողություններ, հնարավոր է ոչ միայն պատվերով... Exception CancelTransaction(); Errors.Insert(Order, DescriptionError()); Փորձի ավարտ; End Cycle; Վերադարձի սխալ; EndFunction // ServerChangeOrderStatus()

Կոդի կառուցվածքը

Հիմնական նպատակները, որոնք պետք է արտացոլի կառավարվող ձևի մոդուլը և մոտենա լուծմանը:
  • Հաճախորդի և սերվերի կոդի հստակ տարանջատում:Չմոռանանք, որ կատարման պահին դրանք երկու փոխազդող գործընթացներ են, որոնցից յուրաքանչյուրում առկա ֆունկցիոնալությունը զգալիորեն տարբերվում է։
  • Հեռավոր մուտքի ինտերֆեյսի հստակ ընտրություն, սերվերի ո՞ր մեթոդները կարող են կանչվել հաճախորդից, և որոնք՝ ոչ: Հեռավոր ինտերֆեյսի մեթոդների անվանումները սկսվում են «Սերվեր» նախածանցով: Սա թույլ է տալիս անմիջապես տեսնել հսկողության անցումը սերվերին կոդը կարդալիս և հեշտացնում է կոնտեքստային ակնարկների օգտագործումը: Նկատի ունեցեք, որ պաշտոնական առաջարկությունը (ITS) առաջարկում է անվանել մեթոդներ հետֆիքսներով, օրինակ՝ ChangeOrderStatusOnServer(): Այնուամենայնիվ, կրկնելու համար, ոչ բոլոր սերվերի մեթոդները կարող են կանչվել հաճախորդից, և, հետևաբար, տրամաբանական հասանելիությունն ավելի կարևոր է, քան կոմպիլյացիայի գտնվելու վայրը: Հետևաբար, «Server» նախածանցով մենք նշում ենք միայն հաճախորդին հասանելի մեթոդները, օրինակ մեթոդը կկոչվի ServerChangeOrderStatus():
  • Ընթեռնելիություն.Ճաշակի հարց է, մենք ընդունում ենք պատվերը, երբ մոդուլը սկսվում է սերվերի վրա ձև ստեղծելու ընթացակարգերով և հեռահար մուտքի մեթոդներով:
  • Պահպանելիություն.Նոր կոդը ավելացնելու տեղը պետք է հստակ սահմանված լինի: Կարևոր կետ, որոնք ավտոմատ կերպով ստեղծվում են մեթոդի կոճակի կոնֆիգուրատորի կողմից, ավելացվում են մոդուլի վերջում։ Քանի որ ձևի տարրերի իրադարձությունների մշակիչները ամենից հաճախ ստեղծվում են ավտոմատ կերպով, համապատասխան բլոկը տեղադրվում է վերջին տեղում, որպեսզի յուրաքանչյուր մշակիչ չքաշվի մոդուլի մեկ այլ տեղ:
Ստորև ներկայացված է թվարկված նպատակներն իրագործող մոդուլի հիմնական կառուցվածքը:
  • Գրաֆիկական տարբերակ - հստակ ցույց է տալիս կատարման հիմնական հոսքը:
  • Տեքստի տարբերակը ձևանմուշի ձևավորման օրինակ է՝ կառուցվածքը նոր ձևի մոդուլում արագ տեղադրելու համար:

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Ամսաթիվ = ""/> // <Описание> // // /////////////////////////////////////////////////////////////////// / //////////////////////////// // ՄՈԴՈՒԼԻ ՓՈՓՈԽԱԿԱՆՆԵՐ ///////////////// / ////////////////////////////////////////////////////////////////// // ///////////// // ՍԵՐՎԵՐԻ ՄԱՍԻՆ //******** ՍԵՐՎԵՐԻ ՎՐԱ ՄԻՋՈՑԱՌՈՒՄՆԵՐԸ ******* &Սերվերի վրա Ընթացակարգը Սերվերի վրա Ստեղծման մասին ( Խափանում, ստանդարտ մշակում) //Տեղադրեք մշակողի բովանդակությունը EndProcedure //******* ՀԵՌԱԿԱ ՄՈՒՏՔԻ ԻՆՏԵՐՖԵՅՍ ******* //******** ԲԻԶՆԵՍ ՏՐԱՄԱԲԱՆՈՒԹՅՈՒՆԸ ՍԵՐՎԵՐԻ ՎՐԱ **** *** /////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////// /////////////////////////// Հաճախորդի վրա // ******* Բիզնես տրամաբանություն հաճախորդի վրա ******* //******* ՀՐԱՄԱՆՆԵՐ ******* //******** ՄԻՋՈՑԱՌՈՒՄՆԵՐ ՀԱՃԱԽՈՐԴԻ ՎՐԱ ****** ////////////// /////////////////////////////////////////////////////////////////// //////////////// / / ՀԻՄՆԱԿԱՆ ԾՐԱԳՐԻ ՕՊԵՐԱՏՈՐՆԵՐ

Առնչվող հարցեր
Եզրափակելով, մենք նախանշում ենք մի քանի ոլորտներ, որոնց մասին օգտակար է մտածել հաճախորդ-սերվեր փոխազդեցությունը ծրագրավորելիս:
  • Հեռավոր մուտքի ինտերֆեյսի ներդրման տարբերակներ. Ասինխրոնություն, հատիկավորություն...
  • caching. 1C-ն դժբախտ ճարտարապետական ​​որոշում է կայացրել՝ ներմուծելով քեշավորումը միայն սովորական մոդուլների կանչման մեթոդների մակարդակում և չտրամադրելով կառավարման տարբերակներ (արդիական ժամանակ, վերակայում ըստ պահանջի):
  • Սերվերի անուղղակի զանգեր. Մի մոռացեք տեխնոլոգիական առանձնահատկությունների մասին, հաճախորդի վրա շատ «անվնաս» գործողություններ հրահրում են պլատֆորմին սերվեր մուտք գործելու համար:

Օգտագործողի աշխատանքը դիրեկտորիաների և փաստաթղթերի հետ 1C-ում բաղկացած է ձևի դաշտերը լրացնելուց:

1C մանրամասները գրացուցակի և փաստաթղթի դաշտերն են, որոնք ցուցադրվում են ձևաթղթում, որպեսզի օգտագործողը լրացնի դրանք:

Եկեք մանրամասն քննարկենք 1C-ի մանրամասների թեման:

Ինչ է Requisites 1C-ը

Յուրաքանչյուր գրացուցակ և 1C փաստաթուղթ բաղկացած է մի շարք դաշտերից: Նման դաշտերը կոչվում են 1C մանրամասներ (1C ծրագրավորողի համար):

Կազմաձևիչում, 1C կազմաձևման ծառում, բացեք ցանկացած գրացուցակ կամ փաստաթուղթ և կտեսնեք Requisites մասնաճյուղը: Սա գրացուցակի մանրամասների (դաշտերի) ցանկն է:

Նայեք, թե ինչպես են նույն 1C մանրամասները նայում 1C գրացուցակի ձևաթղթում:

Յուրաքանչյուր 1C հատկանիշ ունի հատկություններ, որոնք ցույց են տալիս, թե ինչ տեսակի արժեք է պահվում հատկանիշում (տող, թիվ և այլն) և ինչպես է օգտատերը աշխատել դրա հետ:

Աջ սեղմեք ցանկացած 1C հատկանիշի վրա և սեղմեք Հատկություններ: Աջ կողմում գտնվող պատուհանում կբացվի ընտրված հատկանիշի հատկությունների ցանկը:

1C ռեկվիզիտների հիմնական հատկությունները.

Ստանդարտ մանրամասներ 1C

Ինչպես նկատեցիք, հղման ձևն ունի 1C մանրամասներ, որոնք նշված չեն կազմաձևիչում՝ խումբ, անուն, BIC:

Գրացուցակի ցուցակի ձևում կան նաև 1C մանրամասներ, որոնք ցուցակում չկան՝ ջնջման նշան։

Սրանք 1C ստանդարտ ռեկվիզիտներ են: Ինչ է դա? Յուրաքանչյուրը լռելյայն ունի 1C ռեկվիզիտների մի շարք: Գրացուցակների համար սա, օրինակ, ծածկագիր և անուն է: Փաստաթղթերի համար սա ամսաթիվն ու համարն է:

Ստանդարտ 1C մանրամասները կարելի է դիտել հետևյալ կերպ.

  • Գնացեք 1C օբյեկտի խմբագրին (տեղեկատու գիրք կամ փաստաթուղթ)՝ կրկնակի սեղմելով դրա վրա
  • Բացվող խմբագրում ընտրեք Տվյալների ներդիրը
  • Այստեղ դուք կարող եք սահմանել ստանդարտ մանրամասների կոդը և գրացուցակի անվանումը
  • Սեղմեք 1C Ստանդարտ մանրամասներ կոճակը՝ ամբողջական ցանկը տեսնելու համար:

Ընդհանուր մանրամասներ 1C

Սկսած 1C 8.2.14 տարբերակից, 1C-ում հայտնվել է նոր Օբյեկտ 1C - Ընդհանուր մանրամասներ 1C: Դրանով դուք կարող եք ավելացնել հատկանիշ (դաշտ), որն անմիջապես առկա կլինի բազմաթիվ գրացուցակներում և փաստաթղթերում:

Ընդհանուր հենարաններ 1C-ի հատկությունները.

  • Ավտոմատ օգտագործում - ավելացնում է ընդհանուր հատկանիշ 1C բոլոր գրացուցակներին և փաստաթղթերին միանգամից
  • Կազմը - թույլ է տալիս ավելացնել 1C ընդհանուր հատկանիշը միայն անհրաժեշտ գրացուցակներում և փաստաթղթերում (ավտոմատ օգտագործել, այնուհետև սահմանել Չօգտագործել):

Ինչպես ավելացնել ռեկորդներ 1C

Աջ սեղմեք ցանկալի գրացուցակի 1C Requisites մասնաճյուղի վրա և ընտրեք Ավելացնել:

Մենք պետք է մուտքագրենք 1C հատկանիշի անունը, օրինակ՝ «Գրասենյակի հասցե» և «Գրասենյակի հասցե» հոմանիշը: Մենք թողնում ենք լռելյայն տեսակը String, բայց նշում ենք անսահմանափակ երկարություն վանդակը:

Եկեք ճիշտ նույն կերպ ավելացնենք ևս մեկ հատկանիշ 1C, պարզապես ընտրեք Բուլյան տեսակը, եկեք այն անվանենք «WorksOn Weekends»:

Ինչպես ցուցադրել մանրամասները 1C ձևի վրա (հաստ հաճախորդ 1C)

Բացենք նույն գրացուցակի Forms մասնաճյուղը։ Ձևը բացելու համար ընտրեք տարրի ձևը և մկնիկի օգնությամբ կրկնակի սեղմեք դրա վրա։

Քաշեք մկնիկը ձևի եզրին և ձգեք այն (ըստ ցանկության):

Կազմաձևողի վահանակում սեղմեք «Տվյալների տեղադրում» կոճակը: Կարող եք նաև օգտագործել Ձև / Տվյալների տեղադրման ընտրացանկը:

Դուք տեսնում եք, որ մեր մանրամասները չեն ցուցադրվում ձևի վրա: Դրանց վրա նշան դրեք: Ինչպես նաև վանդակները Տեղադրել պիտակներ և Տեղադրել ավտոմատ կերպով:

Ինչպես ցուցադրել մանրամասներ 1C ձևի վրա (1C բարակ հաճախորդ)

Բացենք նույն գրացուցակի Forms մասնաճյուղը։ Ընտրեք տարրի ձևը և մկնիկի օգնությամբ կրկնակի սեղմեք դրա վրա:

Պահանջների ներդիրում ընդլայնեք «Օբյեկտ» տողը: Դուք կտեսնեք գրացուցակում ավելի վաղ ավելացված մանրամասների ցանկը:

Այժմ պարզապես քաշեք անհրաժեշտ հատկանիշը աջ պատուհանից ձախ պատուհան և այն կհայտնվի ձևի վրա:

1C ձևի մանրամասները

Հաստ հաճախորդի մեջ ձևն ունի իր մանրամասները: Դրանք գտնվում են Պահանջների ներդիրում:

Այս մանրամասները չեն պահվում տվյալների բազայում, բայց դրանք կարող են օգտագործվել ձևի վրա այն դաշտերի համար, որոնք անհրաժեշտ են ձևի հետ աշխատելու համար:

Օրինակ, ձևի վրա նշան եք ավելացրել: Երբ սեղմում եք ձևի վրա, ինչ-որ բան է պատահում: Նշման վանդակի արժեքը ձեզ համար կարևոր չէ (պետք չէ գրել այն), այն օգտագործվում է միայն դրա հետ աշխատելիս ձևը փոխելու համար: Այս դեպքում դուք օգտագործում եք ոչ թե հղում հատկանիշը որպես տվյալ, այլ ձևի հատկանիշը։

Պարբերական մանրամասներ 1C

1C 7.7 տարբերակում եղել են պարբերական մանրամասներ։ Դրանց իմաստը հետևյալն է՝ ռեկվիզիտների արժեքը տարբեր ամսաթվերի ժամանակ տարբեր է։ Օրինակ՝ սեպտեմբերի 1-ի արժեքը մեկն է, իսկ հոկտեմբերի 1-ինը՝ մեկ այլ: Նույն հենարաններով։

1C 8-ում պարբերական մանրամասներ չկան: Սա իրականացվում է հետևյալ կերպ.

Ձևի ատրիբուտներն ապահովում են դրա կապը տվյալների հետ: Այս դեպքում մանրամասներից մեկը (և միայն մեկը) կարող է նշանակվել որպես հիմնական. դա կարող է պարտադիր լինել ոչ այն տվյալների տեսակից, որի օբյեկտի համար մենք գծում ենք ձևը: Բայց ձևի վարքագիծը կախված կլինի հիմնական հատկանիշի տվյալների տեսակից: Բացի ձևի վարքագիծը փոխելուց, ձևի մոդուլի համատեքստում փոփոխություն կա: Ձևի մեթոդների և հատկությունների հետ մեկտեղ նրանում հասանելի են դառնում հիմնական հատկանիշի արժեք հանդիսացող օբյեկտի մեթոդներն ու հատկությունները։ Կարևոր է, որ «Ազատ ձև» տեսակի ձևերը չունենան հիմնական հատկանիշը։ Այս դեպքում ձևի վարքագիծը որոշվում է միայն օգտագործողի կարգավորումներով: Եկեք նայենք հիմունքներին:

Հարց 1C քննության 10.05. Պլատֆորմի մասնագետ: Ինչի համար է հիմնական ձևի հատկանիշը:

  1. Նշում է տվյալների աղբյուրը ձևի համար որպես ամբողջություն
  2. Սահմանում է հարթակի ստանդարտ առանձնահատկությունները, որպեսզի ձևը աշխատի հիմնական հատկանիշի համար նշված տիպի տվյալների հետ
  3. Ձևի տեղական համատեքստից օբյեկտի ատրիբուտներին ծրագրային կերպով մուտք գործելու հնարավորություն ապահովելու համար
  4. Ապահովում է օբյեկտի ատրիբուտների պատկերացում ձևի երկխոսության վրա
  5. Ճիշտ 2 և 3
  6. Ճիշտ 1 և 2

Ճիշտ պատասխանը վեցերորդն է, տես վերևում։


Հարց 1C քննության 10.06. Պլատֆորմի մասնագետ. Ինչի՞ համար են նախատեսված ձևի մանրամասները:
  1. Ցուցադրվող, խմբագրված կամ պահվող տվյալների կազմը նկարագրելու համար
  2. Տվյալները ձևով ցուցադրելու և խմբագրելու համար
  3. Ճիշտ 1 և 2

Ճիշտ պատասխանը երրորդն է՝ երկուսն էլ։

Հարց 10.07 քննության 1C. Պլատֆորմի մասնագետ. Հիմնական հատկանիշը կամայական կառավարվող ձևին վերագրելու համար...

  1. ձևի հատկանիշի հատկություններում անհրաժեշտ է նշել «Հիմնական հատկանիշ» վանդակը
  2. անհրաժեշտ է լրացնել ձևի «Տվյալներ» հատկությունը՝ ընտրելով ձևի պահանջվող հատկանիշը

Ճիշտ պատասխանը երկրորդն է.

Հարց 1C քննության 10.08. Պլատֆորմի մասնագետ. Հիմնական հատկանիշը կամայական սովորական ձևին վերագրելու համար...
  1. ձևը պետք է դարձնել հիմնական, հիմնական հատկանիշը որոշվում է ավտոմատ կերպով
  2. ձևի հատկանիշի հատկություններում անհրաժեշտ է նշել «Հիմնական հատկանիշ» վանդակը
  3. դուք պետք է մուտքագրեք «Խմբագրել» ցանկը, «Հիմնական հատկանիշներ» կետը և ընտրեք ցանկալի արժեքը
  4. անհրաժեշտ է լրացնել ձևի «Տվյալներ» հատկությունը՝ ընտրելով ձևի պահանջվող հատկանիշը

Ճիշտ պատասխանը չորրորդն է.

Հիմնական հենակետերը ընդգծված են թավով.

Հարց 10.09 քննության 1C. Պլատֆորմի մասնագետ. Եթե ​​ունեք մեկ հիմնական ձևի հատկանիշ, կարո՞ղ եք ավելացնել մեկ այլ հիմնական ձևի հատկանիշ:
  1. Սա անհնար է
  2. Դա հնարավոր է ձևի հատկանիշի հատկությանը համապատասխան արժեք վերագրելով
  3. Կարող է կատարվել միայն ծրագրային եղանակով, երբ մուտք գործեք «Ձև» օբյեկտ
  4. Դա հնարավոր է ձևի համապատասխան հատկությանը ևս մեկ արժեք ավելացնելով

Ճիշտ պատասխանը առաջինն է, հիմնական հատկանիշը խիստ մեկն է, քանի որ կապը օբյեկտի հետ պետք է լինի միանշանակ.

Հարց 10.113 քննության 1C. Պլատֆորմի մասնագետ: Նկարում ներկայացված ձևի մանրամասներից ո՞րն է հիմնականը:

  1. ՑուցակԱրժույթի դրույքաչափեր
  2. DirectoryObject
  3. Գրացուցակի ձևերը չունեն հիմնական հատկանիշ
  4. Գրացուցակների ձևերը ունեն բոլոր հիմնական մանրամասները
Ճիշտ պատասխանը երկրորդն է՝ այն, որը համարձակ է:

Ձևաթղթեր 1C:Enterprise-ում նախատեսված են տվյալների բազայում պարունակվող տեղեկատվությունը ցուցադրելու և խմբագրելու համար: Ձևերը կարող են պատկանել որոշակի կոնֆիգուրացիայի օբյեկտներին կամ գոյություն ունենալ դրանցից առանձին և օգտագործվել ամբողջ կիրառական լուծումների կողմից որպես ամբողջություն:

Օրինակ՝ ուղեցույց Անվանակարգկարող է ունենալ մի քանի ձևեր, որոնք կօգտագործվեն հատուկ նպատակների համար՝ գրացուցակի տարր խմբագրելը, ցուցակի ցուցադրումը և այլն.

Սրա հետ մեկտեղ կարող են լինել ընդհանուր ձևեր, որոնք չեն պատկանում կոնկրետ կոնֆիգուրացիայի օբյեկտներին՝ ընդհանուր ձևեր։

Հիմնական ձևեր

Յուրաքանչյուր կոնֆիգուրացիայի օբյեկտ կարող է օգտագործվել որոշակի ստանդարտ գործողություններ կատարելու համար: Օրինակ, ցանկացած գրացուցակի համար կարող է անհրաժեշտ լինել ցուցադրել դրա տարրերի ցանկը, ցուցադրել գրացուցակի առանձին տարրեր, ցուցադրել գրացուցակի խումբ, ընտրել տարրեր և տարրերի խմբեր գրացուցակից: Ցանկացած փաստաթղթի համար նման գործողությունների ցանկը շատ ավելի փոքր կլինի՝ դիտել փաստաթղթերի ցանկը, ընտրել փաստաթղթերի ցանկից և դիտել մեկ փաստաթուղթ:

Նման ստանդարտ գործողությունների կատարումը կիրառական լուծման օբյեկտների տվյալների հետ ապահովելու համար նրանցից յուրաքանչյուրի համար կա մի շարք հիմնական ձևեր, որոնք կօգտագործվեն համապատասխան գործողություններ կատարելիս: Հիմնականը կարող է վերագրվել այս օբյեկտին ենթակա ձևերից որևէ մեկին։ Օրինակ, գրացուցակը Անվանակարգկարող են լինել հետևյալ հիմնական ձևերը.

Եվ փաստաթուղթը Ապրանքների և ծառայությունների ստացումհիմնական ձևերի կազմը տարբեր կլինի.

Այսպիսով, եթե օգտագործողը ցանկանում է տեսնել գրացուցակի ցուցակը Անվանակարգկամ փաստաթղթերի ցանկ Ապրանքների և ծառայությունների ստացում, համակարգը կբացի համապատասխան ձևը, որը նշանակված է որպես այս օբյեկտների ցուցակի ձև:

Ավտոմատ ստեղծվող ձևեր

1C:Enterprise 8 համակարգի կարևոր հատկանիշը ավտոմատ ստեղծվող ձևերի մեխանիզմն է։ Այս մեխանիզմը ծրագրավորողին ազատում է կոնֆիգուրացիայի յուրաքանչյուր օբյեկտի համար բոլոր հնարավոր ձևերը ստեղծելուց: Բավական է, որ մշակողը ավելացնի նոր կոնֆիգուրացիայի օբյեկտ, և համակարգն ինքը կստեղծի անհրաժեշտ ձևերը օգտատիրոջ աշխատանքի ճիշտ պահերին այս օբյեկտում պարունակվող տեղեկատվությունը ցուցադրելու համար:

Այսպիսով, մշակողը պետք է ստեղծի կիրառական լուծման օբյեկտների իր ձևերը միայն այն դեպքում, եթե դրանք պետք է ունենան տարբերություններ (տարբեր ձևավորում կամ հատուկ վարքագիծ) համակարգի կողմից ինքնաբերաբար ստեղծվող ձևերից:

Ձևը տվյալների հետ կապելը

Այն փաստը, որ ձևը պատկանում է այս կամ այն ​​կոնֆիգուրացիայի օբյեկտին, չի որոշում ձևի մեջ ցուցադրվող տվյալների կազմը: Որ ձևը պատկանում է, օրինակ, գրացուցակին Անվանակարգ, թույլ է տալիս այն վերագրել այս գրացուցակի հիմնական ձևերից մեկին, բայց ոչ մի կերպ չի որոշում, թե ինչպիսի տվյալներ կցուցադրի այս ձևը և ինչպիսին կլինի դրա վարքագիծը:

Ձևը տվյալների հետ կապելու համար օգտագործվում են ձևի ատրիբուտները, որոնք ցույց են տալիս ձևի կողմից ցուցադրվող տվյալների ցանկը։ Բոլոր ձևերն ինքնին ունեն նույն վարքագիծը, անկախ նրանից, թե ինչ տվյալներ են ցուցադրում: Այնուամենայնիվ, ձևի ատրիբուտներից մեկը կարող է սահմանվել որպես հիմնական ձևի հատկանիշ (այն ընդգծված է թավով), որի դեպքում ձևի ստանդարտ վարքագիծը և դրա հատկությունները կլրացվեն՝ կախված հիմնական ձևի հատկանիշի տեսակից.

Օրինակ, եթե փաստաթուղթը նշանակված է որպես ձևի հիմնական հատկանիշ Ապրանքների և ծառայությունների ստացում, ապա երբ ձևը փակվի, համակարգը կխնդրի այս փաստաթուղթը ձայնագրելու և տեղադրելու հաստատում։ Եթե, ասենք, տեղեկատու գրքույկ է նշանակվում որպես ձևի հիմնական հատկանիշ Անվանակարգ, ապա ձևը փակելիս նման հաստատման հարցում չի լինի։

Ձևի կառուցվածքը

Ձևերի հիմնական առանձնահատկությունն այն է, որ դրանք մշակողի կողմից մանրամասնորեն չեն գծվում՝ «պիքսելներով»: Կազմաձևի ձևը ձևի կազմի տրամաբանական նկարագրությունն է: Եվ տարրերի կոնկրետ տեղադրումը համակարգը կատարվում է ավտոմատ կերպով, երբ ձևը ցուցադրվում է:

Ձևի այն մասը, որը ցուցադրվում է (տեսանելի է օգտագործողի համար) նկարագրվում է որպես ձևի տարրեր պարունակող ծառ:

Տարրերը կարող են լինել մուտքային դաշտեր, վանդակներ, ռադիո կոճակներ, կոճակներ և այլն: Բացի այդ, տարրը կարող է լինել այլ տարրերի խումբ: Խումբը կարող է ներկայացվել որպես շրջանակով վահանակ, էջերով վահանակ (ներդիրներով), ինքնին էջ, հրամանների վահանակ: Բացի այդ, տարրը կարող է լինել աղյուսակ, որը ներառում է նաև տարրեր (սյունակներ): Տարրերի կառուցվածքը նկարագրում է, թե ինչպիսի տեսք կունենա ձևը:

Ձևի բոլոր գործառույթները նկարագրված են մանրամասների և հրամանների տեսքով: Մանրամասները տվյալներն են, որոնց հետ աշխատում է ձևը, իսկ հրամանները՝ կատարված գործողությունները: Այսպիսով, ձևաթղթի խմբագրիչը պետք է ձևի մեջ ներառի անհրաժեշտ մանրամասներն ու հրամանները, ստեղծի ձևի տարրեր, որոնք ցուցադրում են դրանք և, անհրաժեշտության դեպքում, տարրերը դասավորի խմբերի:

Այս տրամաբանական նկարագրության հիման վրա համակարգը ավտոմատ կերպով ստեղծում է ձևի տեսքը՝ օգտագործողին ցուցադրելու համար: Միևնույն ժամանակ, համակարգը հաշվի է առնում ցուցադրվող տվյալների տարբեր հատկությունները (օրինակ՝ տեսակը), որպեսզի օգտագործողի համար հնարավորինս հարմար դասավորի ձևի տարրերը:

Մշակողը կարող է ազդել տարբեր պարամետրերով տարրերի դասավորության վրա: Այն կարող է որոշել տարրերի հերթականությունը, նշել ցանկալի լայնությունը և բարձրությունը: Այնուամենայնիվ, սա ընդամենը մի քանի լրացուցիչ տեղեկատվություն է, որը կօգնի համակարգին ցուցադրել ձևը:

Ձևաթղթերում մշակողը կարող է օգտագործել ոչ միայն ձևի հրամանները, այլև գլոբալ հրամանները, որոնք օգտագործվում են ամբողջ կազմաձևման հրամանների միջերեսում: Բացի այդ, ներդրվել է պարամետրիզացվող հրամաններ ստեղծելու հնարավորություն, որոնք կբացեն այլ ձևեր՝ հաշվի առնելով ընթացիկ ձևի կոնկրետ տվյալները։ Օրինակ, դա կարող է լինել զանգ դեպի պահեստի մնացորդների հաշվետվության, որը ներկայումս ընտրված է հաշիվ-ապրանքագրի ձևում:

Հիմնական 1C օբյեկտները, որոնք օգտագործվում են կառավարվող ձևերի հետ աշխատելիս, ներկայացված են ստորև: Տրված են կոդերի համառոտ օրինակներ, որոնք ցույց են տալիս այս օբյեկտների ավանդական օգտագործումը 1C կոնֆիգուրացիաներ գրելիս:

Այս ձևը

Օգտագործվում է ձևի մոդուլում, ընթացակարգերում&AtClient և &AtServer:

Թույլ է տալիս մուտք գործել ինչպես ձևի տարրեր, այնպես էլ ատրիբուտներ:

Ձևի տարրը հասանելի է օբյեկտի միջոցովՏարրեր և նման է հետևյալին.

ThisForm.Items.VersionNumber.Header = "v."+ProgramVersion;

Ձևի վրա գոյություն ունեցող հատկանիշի հասանելիությունը հետևյալն է.

ThisForm.AnnouncementText="Բարև, ընկերնե՛ր!";

Պարզեցված մուտք դեպի ձևի տարրեր և ատրիբուտներ

Ձևի մոդուլում, սկզբունքորեն, դուք չեք կարող նշել հիմնաբառըԱյս ձևը . Դուք կարող եք մուտք գործել ձևի տարրեր և ատրիբուտներ պարզեցված ձևով.

// Ձևի տարր

Elements.VersionNumber.Title = "v."+ProgramVersion;

// Ձևավորել հենարաններ

AnnouncementText="Բարև, ընկերնե՛ր!";

Ձևի մանրամասների ստացման առանձնահատկությունները (կարևոր է)

Եթե ​​ձևի հենարանը պարզ տիպի է.Տող, համար, ամսաթիվ ... ապա դուք կարող եք ստանալ (սահմանել) հատկանիշի արժեքը պարզապես անունով.

Text=ProductName; // Ապրանքի անունը ձևի հատկանիշ է

Այնուամենայնիվ, այս կերպ հնարավոր չէ ստանալ «բարդ» տեսակի մանրամասները.Արժեքների աղյուսակ, Արժեքների ծառ . Այս տիպով ատրիբուտ անունով անունով ձեռք բերելու ժամանակ կվերադարձվի տիպի օբյեկտDataFormsCollection.

«Բարդ» տիպով հատկանիշի արժեքը ստանալու համար անհրաժեշտ է օգտագործել ֆունկցիանFormAttributeToValue():

CurrentTable=FormAttributeToValue("SelectedConstructionObjects");

«Բարդ» հատկանիշի արժեքը սահմանելու համար կարող եք օգտագործել ֆունկցիանValueVPropsForm(<Значение>, <ИмяРеквизита>) , երկու պարամետրերն էլ պարտադիր են։

Գործառույթներ FormAttributeToValue()Եվ ValueVFormProps()հասանելի է միայն սերվերում:

Օբյեկտ

Խստորեն ասած՝ ձևի մեջ նման բանալի բառ չկա։ Պարզապես, երբ ձև է ստեղծվում, օրինակ՝ տարրի ձև, 1C-ն ավտոմատ կերպով ձևաթղթի վրա ստեղծում է ատրիբուտ անունով:Օբյեկտ . Այս հատկանիշի միջոցով հասանելի են ընթացիկ օբյեկտի հատկությունները, որը խմբագրվում է ձևի վրա:

կամ ավելի ամբողջական նշում.

Այս Օբյեկտը

Պարունակում է ինքնին առարկան: Նախատեսված է օբյեկտ ստանալու համար օբյեկտի մոդուլում կամ ձևի մոդուլում:

Օգտագործում՝ միայն կարդալու համար:

Հասանելիություն՝ սերվեր, հաստ հաճախորդ, արտաքին կապ: