Во новите верзии на конфигурациите на системот 1C: Enterprise, многу функции и процедури се префрлија од објектни модули (документи, директориуми, итн.) во модули за менаџери. Ајде да ги погледнеме разликите помеѓу овие два модула.
Според теоријата на објектно-ориентираното програмирање, објектните методи се поделени во две групи: статични и едноставни. Едноставните методи имаат пристап само до одредена инстанца од класа. Статичните методи немаат пристап до објектните податоци, туку работат со класата како целина.
Ако сето ова го преведеме во смисла на системот 1C: Enterprise, тогаш Модул за објектсодржи едноставни методи. За да ги користите, прво мора да добиете одреден објект: елемент од директориум, документ итн. Менаџерски модулсодржи статички методи. За да го користите, нема потреба посебно да го добивате секој специфичен објект, тој ви овозможува да работите со целата колекција одеднаш.
Модул за објектможе да има процедури и функции кои можат да се користат надворешно. За таа цел, таквата постапка или функција се означува со зборот Извоз.
Функција NewFunction() Извоз
За да користите таква функција од објектен модул, мора прво, имајќи врска до бараниот објект, да ја добиете со помош на функцијата GetObject().
Per= Предмет. NewFunction();
Слично на тоа, можете да креирате нови променливи кои можат да се користат од различни конфигурациски објекти.
Променлива NewVariable Export
Директориумски елемент = Директориуми. Номенклатура. FindByCode("000000001");
Објект = Елемент на директориум. GetObject();
Предмет. NewVariable= );
На овој начин, можете да ги дополните стандардните процедури, функциите и својствата (променливите) на објектите. Ваквите променливи се динамични, не се зачувуваат во инфобазата и постојат само додека работат со примениот објект.
Менаџерски модулги има сите исти можности, единствената разлика е во тоа што за да го користите не треба да добивате специфичен објект, модулот за менаџер ви овозможува да работите со целата колекција на објекти од одреден тип;
Постапка NewProcedure() Извоз
Директориумски елемент = Директориуми. Номенклатура. NewProcedure();
Или за променлива:
Променлива NewVariable Export
Директориумски елемент = Директориуми. Номенклатура. новаПроменлива;
Да ги погледнеме разликите во употребата на објектниот модул и модулот менаџер користејќи го примерот на постапката за креирање печатена форма на документ.
Кога го користите објектниот модул, кодот ќе изгледа вака:
Функција Печатење документ (врска) Извоз
//Мора да пренесете врска до одреден документ до оваа функција
Врати TabDoc;
Крајна функција
На формуларот за документ, треба да креирате процедура која ќе пренесе врска до документот до функцијата за печатење.
&OnClient
Процедура печатење (команда)
TabDoc = PrintOnServer();
TabDoc. Прикажи() ;
Крај на постапката
&На серверот
Функција PrintOnServer()
Doc = FormAttributesValue("Објект" ) ;
Враќање Доц. PrintDocument(Object.Link) ;
Крајна функција
Недостаток на овој метод е што печати само еден објект. Ако треба да отпечатите неколку документи одеднаш, тогаш треба да го добиете секој од нив, а потоа да ја повикате функцијата од објектниот модул. Ова бара значителни системски ресурси затоа што кога некој објект се превзема, целиот објект се става во RAM меморијата.
Од гледна точка на перформанси, многу е подобро да се користи модулот за менаџер секогаш кога е можно. Во нашиот пример, решението на проблемот ќе изгледа вака.
Функција PrintOnServer()
Документи за враќање. Нашиот документ. PrintDocument (ArrayLinks);
Крајна функција
Ако го користите модулот за менаџер, постапката за печатење може да се повика и од формата на документот и од формуларот за список, пренесувајќи врски до неколку документи во низа. Во овој случај, системот не треба да го добива секој документ од низата, што значително ги заштедува системските ресурси.
Значи, кога да се користи објектен модул и кога да се користи модул за менаџер?
Се зависи од задачата. Ако упатувањето на објектот е доволно за да се заврши (на пример, задача за печатење), тогаш подобро е да се користи модулот за менаџер. Ако задачата е да ги промените податоците, на пример, да пополните документ, тогаш треба да го добиете и да го користите објектниот модул.
Написот ја продолжува серијата „Први чекори во развојот на 1C“, детално ги разгледува следните прашања:
- Што е софтверски модул и од кои делови се состои?
- За што служи модулот за апликација? Зошто има два од нив? Кога се стартува кој? Кои се суптилностите на делото?
- Кои настани се поврзани со почетокот на работата на системот, како и каде да се обработат?
- За што служи модулот за надворешно поврзување? Кога и како да го користите?
- Кога се користи модулот за сесија?
- Кои се вообичаените модули? Кои се неговите својства и правила за работа? Зошто да се користи својството „Повторна употреба на повратните вредности“?
- Кога се користи модулот за форма и кои настани може да се обработат во него?
- За што служи објектниот модул? Од кои делови се состои? Како можам да ги видам настаните на достапните модули?
- Кои се суптилностите на работата со модулите за менаџер на вредности (за константи) и модулите за збирки на записи (за регистри)?
- Кои се разликите помеѓу објектниот модул и модулот за менаџер? Кога треба да го користите второто?
Применливост
Написот ја разгледува платформата 1C:Enterprise 8.3.4.496. Материјалот е релевантен и за тековните изданија на платформата.
Модули во „1C: Enterprise 8.3“
Модули се оние објекти кои содржат програмски код.
Има доста голем број на типови на модули во Платформата, од кои секој има своја цел и карактеристики.
Секоја линија на код мора да биде во некој модул. Постојат модули за општа намена и објектни модули. Некои модули може да се компајлираат и на клиентот и на серверот, а некои само на серверот.
Модулот може да се состои од неколку делови. Делот за опис на променливата ги опишува локалните променливи на овој модул, кои последователно може да се користат во која било постапка.
Во рамките на секоја процедура, можете да пристапите до променливата на модулот. Дополнително, во самата процедура може да има друга декларација на променлива со исто име. Ова ќе биде локална променлива на оваа постапка.
И покрај истото име, ова се две различни променливи: едната се користи во одредена процедура, а другата се користи надвор од неа.
Во некои модули, променливите може да имаат локација за компилација (достапност) на серверот или клиентот. На пример:
Делот што ги опишува променливите е проследен со дел од процедури и функции, каде што се наведени локални методи на овој модул. Некои модули мора да специфицираат каде ќе се компајлира постапката или функцијата.
Во принцип, директивата за составување може да се изостави. Во овој случај, стандардната директива за компилација е Сервер. Сепак, за погодност за анализа на програмскиот код, се препорачува експлицитно да се наведе каде ќе се состави дадената постапка. Редоследот по кој се опишани процедурите не е важен.
На крајот од модулот, по опишувањето на сите процедури и функции, постои дел од главната програма, кој може да содржи некои оператори и да ги иницијализира локалните променливи на модулот за форма. Овој дел се извршува при пристап до модулот.
Така, на пример, кога се отвора форма на елемент, прво се извршува главниот програмски дел од модулот за форма.
Треба да се забележи дека делот за декларација на променлива и делот за главната програма не постојат за сите модули (т.е., овие делови не се валидни во некои модули). Дел за опишување процедури и функции може да постои во апсолутно секој модул.
Модул за апликација
Овој модул е дизајниран да се справи со настаните на стартување и завршување на апликацијата. На пример, кога ќе ја стартувате апликацијата, можете да преземете валутни стапки од Интернет. Кога прекинувате апликација, можете да потврдите со корисникот дека тој или таа има намера да се откаже.
Исто така, во модулот за апликација има специјални ракувачи кои ви дозволуваат да пресретнувате надворешни настани од опремата.
Тоа може да бидат настани од читач на магнетни картички или фискален регистратор. И овие настани може да се обработат на некој начин.
Ве молиме имајте предвид дека интерактивното стартување на системот се следи во модулот за апликација.
Модулот за апликација нема да работи ако програмата 1C се стартува, на пример, во режим на com конекција. Во овој случај, програмскиот прозорец не е креиран.
Треба да се напомене дека во платформата 8.3 постојат два различни апликативни модули: модулот за Управувана апликација и модулот за Редовна апликација. Настаните на модулот за управувана апликација се обработуваат кога ќе се стартуваат Управуваната апликација тенок и дебел клиент и веб-клиент.
Модул Редовна апликацијаработи кога работи Thick Client во режим Редовна апликација, кој го содржи вообичаениот команден интерфејс во формата Главно мени.
Ако апликацијата работи внатре Управувано, и во режим Редовна апликација, тогаш потребно е да се опишат процедурите на управувачот како за модулот Управувана апликација, и за модулот Редовна апликација.
Модул Управувана апликацијаможе да се избере од контекстното мени на јазолот за конфигурација на root.
Овој модул може да се отвори и од палетата на својства на елементот за конфигурација на root.
За да отворите модул Редовна апликација, треба да се повикате на поставките за конфигурација (команда Опциина менито Сервис).
Формуларот ќе се отвори Опции. На обележувачот Се честимора да биде наведен режимот за уредување на конфигурацијата Управувана апликацијаИ Редовна апликација.
Во овој случај модулот Редовна апликацијаќе може да се отвори и од својствата на коренскиот јазол.
Список на настани за кои може да се обработи УправуваноИ Редовна апликацијае исто.
Овој модул може да содржи дел за декларација на променлива, дел за опис на произволни процедури и функции и главен програмски дел. Но, покрај произволните процедури и функции, во модулот може да се лоцираат специјални ракувачи со настани.
Списокот на достапни ракувачи може да се прегледа со повикување на списокот на процедури и функции на тековниот модул кога модулот е отворен.
Прозорецот Процедури и функции што се отвора ги прикажува сите процедури и функции на овој модул, како и настани за кои сè уште не се креирани ракувачи.
Постојат два настани поврзани со почетокот на системот („пред“ и „на“). Два настани поврзани со исклучување на системот („пред“ и „на“). И, исто така, обработка на надворешни настани (на пример, настани на комерцијална опрема).
Кога е извршен управувач со настани пред, се смета дека дејството сè уште не е извршено. Кога ќе се изврши управувачот со настани „at“, дејството е веќе завршено.
Настан Пред да го стартувате системотсе случува во моментот кога е стартуван Enterprise 8.3, но самата апликација сè уште не се појавила на екранот. Овој настан го има следниов параметар: Одбивање.
Ако овој параметар ја земе вредноста Вистина, тогаш апликацијата нема да започне. Настан При стартување на системотпретпоставува дека дејството е веќе завршено, прозорецот е веќе креиран и во овој случај можеме, на пример, да прикажеме некоја посебна форма. Веќе не е можно да се одбие лансирањето.
Слично на тоа, пред да го исклучите системот, апликацијата е сè уште отворена и можете да одбиете да ја затворите. Кога системот ќе се исклучи, прозорецот на апликацијата е веќе затворен. Можно е само да се извршат дополнителни дејства, на пример, бришење на некои датотеки или испраќање е-пошта.
Во модулот Управувана апликацијаДирективите за компајлирање процедури и функции не се специфицирани, бидејќи модулот е целосно компајлиран на страната на клиентот. Тоа значи дека во процедурите и функциите на модулот нема да можеме директно да пристапиме, на пример, до референтни книги.
Ако од модул Управувана апликацијатреба да направите повик на серверот, тогаш за ова ќе треба да креирате специјални со знаме .
Во модулот Редовна апликацијаНема такви ограничувања, бидејќи овој модул ќе се компајлира при вчитување на Thick Client. Речиси сите видови податоци се достапни во Thick Client.
Процедурите, функциите и променливите на модулот за апликација може да се опишат како извоз.
Бидејќи модулот е целосно компајлиран на клиентот, тоа значи дека во процедурите на клиентот можеме да пристапиме до овој метод и овој имот.
На пример, можете да повикате постапка или функција на модул за апликација од модулот за форма на објект. Сепак, се препорачува да се користат заеднички модули за да се опишат општите алгоритми. Главната цел на модулот за апликација е да ја обработи почетната и крајната точка.
По аналогија со модул за апликација, овој модул е дизајниран да ги обработува настанот за отворање на програмата и настанот за исклучување.
За разлика од апликацискиот модул, кој се иницира во моментот на интерактивно стартување на апликацијата, модулот за надворешна конекција работи во режим на COM поврзување, т.е. кога објектот 1C:Enterprise 8 е креиран и поврзан со одредена база на податоци.
Овој модул има настани: При стартување на системотИ По исклучување на системот.
Модулот за надворешно поврзување може да се отвори со користење или на контекстното мени на ниво на објект за конфигурација на root, или на палетата на својства за коренскиот јазол.
Самиот процес на надворешно поврзување е процес на програмска работа со информациската база, а не интерактивна. Според тоа, во овој момент не можете да користите дијалози или да прикажувате предупредувачки пораки, бидејќи нема кориснички интерфејс.
Во Модулот за надворешна конекција, можно е да се опишат променливите за извоз и методите за извоз што ќе бидат достапни на страната каде што се јавува надворешниот повик до 1C:Enterprise 8.3.
Бидејќи нема кориснички интерфејс во надворешното спојување, модулот за надворешно спојување е целосно компајлиран на серверот.
Модул за сесија
Овој модул е потребен за иницијализирање на параметрите на сесијата. Параметрите на сесијата се брзи глобални променливи чии вредности се достапни насекаде во конфигурацијата.
Можете да го отворите Модулот за сесија или преку контекстното мени или преку палетата на својства на коренскиот јазол.
Модулот за сесија обезбедува настан SettingSessionParameters.
Кога ќе започне апликацијата, прво се повикува оваа постапка. Параметрите на сесијата се потребни за секоја операција на апликацијата: и кога се активираат интерактивно и кога се активираат во режим на надворешна врска.
Модулот за сесија опишува различни дејства за иницијализирање на параметрите на сесијата во зависност од различните услови.
Овој модул, по правило, опишува неколку постапки кои се повикуваат од постапката SettingSessionParameters. Затоа, сите овие постапки се поделени во посебен модул.
Модулот за сесија секогаш работи во привилегиран режим. Ова значи дека нема да се изврши проверка на дозволите при пристап до базата на податоци. Модулот за сесија е компајлиран на Серверот, т.е. Можно е да се пристапи до сите методи на серверот (вклучувајќи вредности за читање од базата на податоци).
Во Session Module можно е да се дефинираат само процедури и функции, т.е. нема дел за опис на променливата и нема главен програмски дел. Не можете да дефинирате методи за извоз во модул за сесија.
Ако при стартување на системот е неопходно да се извршат некои дејства на серверот, на пример, да се создаде елемент од директориумот, тогаш, како опција, можно е да се користи Session Module, бидејќи тој се компајлира на серверот и секогаш сигурно се извршува при стартување на системот. Сепак, треба да се земат предвид следниве точки:
- постапка SettingSessionParametersсе извршува не само при стартување на системот, туку и при пристап до неиницијализирани параметри на сесијата. Оние. управувачот SetSessionParameters може постојано да се повикува за време на работата на апликацијата;
- ако бројот на елементи во низата со параметри на сесијата е нула (низата барани параметри има податочен тип Undefined), тогаш ова е моментот кога апликацијата се стартува;
- бидејќи Модулот за сесија работи во привилегиран режим и нема да има проверка на правата за пристап, треба да работите многу внимателно со објектите на базата на податоци, бидејќи корисникот може да добие пристап до податоци што не треба да му се обезбедат;
- Кога ќе стартува системот, сè уште не е познато дали апликацијата ќе биде лансирана. Во овој случај, може да се извршат непотребни дејства во управувачот со настани SetSessionParameters.
Овие модули претставуваат опис на некои општи алгоритми, т.е. процедури и функции кои можат да се повикуваат од различни места.
Логично поврзаните методи може да се групираат во различни заеднички модули. Овие модули се креирани во гранката General.
Можете да додадете кој било број на споделени модули. За да се направат методите на Заеднички модул достапни на друго место во конфигурацијата, тие мора да се дефинираат со клучниот збор Извоз. Клиентските процедури на заедничките модули ќе бидат достапни на Клиентот, а серверот - на Серверот.
Во Општите модули, достапен е само делот што ги опишува процедурите и функциите. Оние. во Општиот модул не можете да опишете променливи и не можете да опишете дел од главната програма.
Ако е потребна глобална променлива, можете да користите или параметри за сесија или променливи за извоз на модул на апликацијата.
За општите модули, можете да поставите некои параметри кои ќе влијаат на однесувањето на овој модул. Ако својството Global е поставено за Општ модул, тогаш методите за извоз декларирани во овој модул ќе бидат достапни однадвор директно, без никакви дополнителни инструкции.
Оние. на Општ модулќе учествува во формирањето на глобалниот конфигурациски контекст.
Имотот Глобалназа општи модули може да биде корисно. Сепак, не треба да го користите насекаде за сите заеднички модули.
Оние , кои се означени со знакот Глобална, ќе се компајлира при стартување на системот. Колку повеќе такви модули, толку побавно ќе започне програмата.
Ако знамето ГлобалнаЗа Општ модулне е одредено, тогаш компилацијата на овој модул ќе се изврши во моментот на првиот повик до него (т.е. откако системот ќе започне).
Покрај тоа, употребата на глобални заеднички модули влијае на разбирањето на кодот. Методите на неглобален заеднички модул се нарекуваат преку името Општ модули името на методот, на пример:
Модул за пресметување на трошоците.DistributeIndirectCosts();
Во овој случај, имињата на Заедничките модули мора да ја одразуваат содржината на процедурите опишани во нив. Наведувањето на името на Заедничкиот модул при повикување постапка помага подобро да се разбере кодот.
За Општ модулВ Палета на својстваможете да го поставите имотот Привилегирани.
Привилегираниот модул не ги контролира правата за пристап. Ова е неопходно доколку Општ модулПотребно е да се изврши масовна обработка на податоци, добивање податоци од базата на податоци.
Контролирањето на правата за пристап го зголемува времето потребно за пристап до базата на податоци, а масовните алгоритми честопати треба да работат што е можно побрзо.
На пример, платниот список е операција која бара ресурси. Тоа треба да се направи што е можно побрзо. За да се постигне ова, алгоритмите кои пресметуваат плати се ставени во привилегирани .
Во исто време, сите процедури кои обезбедуваат комплетирање на документите за платен список се надвор од нив Заеднички модули. Токму во овие постапки се врши контрола на правата за пристап.
На овој начин може да се постигнат значителни подобрувања во перформансите. Ова е особено точно кога се користи механизам за контрола на пристапот ред до ред до записите од табелата.
Ако заедничкиот модул е привилегиран, тогаш процедурите на овој модул може да се компајлираат само на серверот.
Постојат ситуации кога некој објект треба да биде недостапен за корисникот, на пример, одреден директориум. Но, при спроведување на кој било документ, неопходно е упатување на оваа референтна книга.
Оние. Постои потреба привремено да се прошират корисничките права и потоа да се вратат во првобитната состојба. Овој ефект може да се добие со користење на привилегирани Заеднички модули.
За да го направите ова во привилегирана Општ модултреба да креирате процедура која пристапува до бараните податоци.
Оваа постапка ќе биде повикана од соодветниот документ. Оние. на корисникот всушност му се доделуваат продолжени права во моментот кога се повикува оваа постапка.
За Заеднички модулиМожно е да се одреди локацијата на компилацијата. Знамињата се користат за да се одреди дали заедничкиот модул ќе биде достапен на клиентот (управувана апликација), на серверот или во режимот за надворешна врска.
Дополнително, ако го префрлите режимот за уредување на конфигурацијата на Управувана апликација и редовна апликација, тогаш ќе биде возможен друг контекст на компилација - Клиент (редовна апликација).
Така, постојат четири опции за функционирање на програмата. Во зависност од апликацијата која работи, во зависност од работата на клиентот или на серверот, одредени заеднички модули ќе бидат достапни или недостапни.
Покрај можноста да се специфицираат знаменца за компилација, можно е да се специфицираат директиви за компилација за процедури и функции лоцирани во Заедничкиот модул.
Ако е одредена директива за компилација за метод, тогаш иако Заедничкиот модул е достапен во сите наведени контексти, достапноста на конкретниот метод ќе биде ограничена со директивата за составување.
Во овој случај, постапката не може да се пристапи во контекст што не е достапен за целиот модул.
Ако не наведете директива за компилација за процедура (функција), таа ќе биде составена во сите контексти дефинирани за модулот.
Оние. Во суштина, ќе се направат повеќе копии од постапката. Изборот на одредена компајлирана инстанца зависи од тоа каде се повикува постапката (по правилото за најблиско повикување). Треба да се земе предвид дека кодот на таквата постапка мора да биде напишан земајќи ја предвид неговата достапност во сите контексти дефинирани за модулот.
Генеричките модули кои се истовремено достапни во неколку различни контексти првенствено се дизајнирани да креираат процедури кои се достапни во повеќе контексти.
Кога креирате Заеднички модул, се смета за добра практика да не се специфицираат директиви за компилација. Оние. Достапноста на процедурите и функциите треба да биде одредена од својствата на самиот модул.
Со овој пристап, процедурите на клиентот ќе бидат лоцирани во посебни Заеднички модули, а процедурите на серверот ќе бидат лоцирани во посебни Заеднички модули.
Модулите кои имаат поставени неколку знамиња за компилација се користат исклучително ретко во пракса. Ова се некои вообичаени дејства достапни и на клиентот и на серверот. Обично ова се некои едноставни пресметки.
Важно! Можно е клиентот да пристапи до методите за извоз на серверот на заедничкиот модул, но само ако овој Заеднички модул е компајлиран само на серверот. Во овој случај, се обезбедува специјално знаменце за да се обезбеди пристап од Клиентот .
За неглобални заеднички модули, можно е да се кешираат вредностите вратени по функции. Оние. По првиот повик на функција, системот може да се сети на резултатот од неговото извршување. Ако оваа функција се повика повторно со истите параметри, системот ќе ја врати вредноста од кешот.
Целта на овој механизам е да ги забрза повторените повици. За да го конфигурирате ова однесување треба Палета на својствамодул, поставете ја соодветната вредност за својството Повторна употреба на повратните вредности.
Стандардно, ова својство е поставено на Не користете. Други можни вредности: кеш За време на повикот, или За времетраењето на седницата.
Ова својство има смисла да се користи само за оние функции чии резултати зависат исклучиво од влезните параметри. Овој механизам е достапен само за неглобални заеднички модули.
Ако се избере вредноста на соодветниот параметар За времетраењето на повикот, кешот ќе работи се додека трае постапката од која е повикан методот Општ модул. Ако е избрана вредноста За времетраење на сесијата, тогаш условно се претпоставува дека кешот ќе работи додека корисникот работи.
Сепак, постојат одредени временски ограничувања. Кешот се брише автоматски 20 минути откако вредноста ќе влезе во кешот.
Модул за формулари
Овој модул е дизајниран да ги обработува корисничките дејства. На пример, опишете го алгоритмот за тоа како програмата реагира кога ќе се притисне копче. Или, на пример, во моментот на внесување вредност во полето, веднаш проверете дали е точност.
Покрај настаните поврзани со контролите на формата (копчиња, полиња за внесување), има настани поврзани директно со самата форма.
На пример, можете да се справите со настанот за отворање на формуларот и да направите некоја почетна иницијализација. Може да се справите и со настанот за затворање на формуларот и да проверите дали корисникот внел сè правилно.
Постојат контролирани форми и редовни форми. Модулите на овие форми првенствено се разликуваат по тоа што модулот за управувана форма е јасно поделен на контекст. Секоја постапка (функција) мора да има директива за составување. Во нормална форма, целиот код се користи на клиентот.
Во модул за управувана форма, можете да декларирате процедури и функции, можете да декларирате променливи и можете да опишете дел од главната програма.
Програмскиот код на главната програма ќе се изврши во моментот на иницијализација на формуларот, т.е. кога корисникот ќе почне да го отвора. Сликата покажува листа на стандардни настани за управувана форма.
Списокот на настани на управувана форма е видлив и во списокот со својства директно за самата форма. Оваа листа се повикува во уредникот на управувани форми.
Во управувана форма, може да се справите со настанот за пишување на ставката. Овој настан е присутен само за обрасци на објекти (директориуми, документи и некои други). Ако формата не е врзана за одреден објект, тогаш нема настан за пишување.
За модул од редовна форма, листата на стандардни настани е нешто помала, бидејќи Во управувана форма, многу настани се направени да се спарат (еден се извршува на клиентот, а другиот на серверот). Во својата нормална форма, целиот код се извршува на клиентот.
Модул за објект
Овие модули се типични за именици, документи, планови за типови на пресметки, сметки и многу други објекти. Објектниот модул е дизајниран да се справува со стандардни настани. На пример, настан за внесување елемент на директориумот, настан за пишување елемент, бришење, објавување документ итн.
Во принцип, настанот за пишување постои и во Модулот за формулари. Но, настанот за пишување во Модулот за формулари се случува за време на процесот на интерактивно снимање, кога се работи со одредена форма.
Настанот за пишување во Модулот за објект ќе се изврши на кое било запишување од која било форма на дадениот објект. Дополнително, ако објектот е напишан програмски, настанот на модулот на објектот ќе се активира.
Во случајот за снимање на Модулот Објект, можете да ги вклучите сите проверки за точноста на податоците што се пишуваат, бидејќи оваа постапка ќе се изврши во моментот на апсолутно секое снимање.
Модулот на овој објект може да се повика преку контекстното мени, од палетата на својства на објекти и од прозорецот за уредување на објекти.
Сликата подолу покажува листа на достапни настани од модулот во директориумот.
Во Object Module можете да поставите дел за опишување променливи, опишување произволни функции кои можеби не се поврзани со настан, како и дел од главната програма.
Во главниот дел од програмата, можете, на пример, да иницијализирате локални променливи на даден модул. Овој програмски код ќе се изврши кога ќе се пристапи до овој објект Модул.
Треба да се напомене дека сите процедури на Object Module се компајлирани на Серверот. Според тоа, не се потребни директиви за компилација за процедури и функции на Модулот за објект. Некои конфигурациски објекти немаат Модули за објекти.
Ова се должи на карактеристиките на самите предмети. Таквите објекти вклучуваат КонстантиИ Регистри. За Постојананема објектен модул, но има многу сличен модул наречен Модул за менаџер на вредност.
ВО Модул за менаџер на вредностможете да се справите со пишување настани Константии пополнување верификација обработка.
Целиот контекст на модулот се извршува на серверот.
За регистри постои модул за записи.
Овој модул, исто така, има можност да ракува со пишување настани и да врши проверки на зафатеност.
Во Object Modules, Value Manager Modules (за константи) и Recordset Modules (за регистри) можете да опишете методи што може да се извезат, а овие методи ќе бидат достапни однадвор.
Оние. Покрај користењето на фиксните методи од класата на објекти, можете да креирате дополнителни методи за објект во Модулот за објект. Овој модул треба да ја опише соодветната процедура со клучниот збор Извоз.
Тогаш ќе може да се пристапи до оваа процедура однадвор. Покрај тоа, овој метод ќе се прикаже во советот за контекстуални алатки. Новите методи во советот за алатката за контекст се означени со син фонт (сина икона p()за постапки и f ()за функции).
Слично, можете да креирате нова сопственост со декларирање на променлива со клучниот збор Извоз. До овој имот може да се пристапи и однадвор.
На овој начин, можно е да се прошири функционалноста на објектите (да се дефинираат нови методи и нови својства). Сепак, својствата се динамични и не се зачувани во базата на податоци.
Ако треба да користите својство за објект што ќе се чува во базата на податоци, треба да креирате атрибут на објект.
Менаџерски модул
Овој модул постои за многу објекти (директориуми, документи, регистри итн.). Модулот се отвора или преку контекстното мени за објектот или преку Палета на својства, или преку прозорецот за уредување.
Во модулот Менаџер можете да отфрлите некои стандардни настани На пример, во Обработка Примање Избор податоци, кога некој елемент е избран од директориумот, може да се направи дополнително филтрирање или проверка.
Дополнително, можете да креирате дополнителни методи во модулот на менаџерот и да означите дека тие се методи за извоз. Во овој случај, можно е да се пристапи до овие методи однадвор.
За да се изврши овој повик, потребно е да се добие типот на податоци Директориум менаџер.
Разликата помеѓу методите за извоз на модулот менаџер и модулот за објекти е во тоа што за да пристапите до методот на Модулот за објекти, прво треба да го добиете самиот објект (односно, некако да добиете врска, а потоа да ја претворите оваа врска во објект) .
После ова, ќе бидат достапни променливите за извоз и методите на Модулот за објект. За модулот Менаџер повикот е поедноставен, на пример:
Директориуми.Counterparties.MethodName
Ова се два различни апели. Конвертирај од референца во објект (метод GetObject) е прилично сериозна акција за системот, бидејќи при примање на објект, се читаат апсолутно сите податоци од овој објект, што може да биде доста долготрајно.
Втората разлика е во тоа Модул за објектнаречен во контекст на одреден елемент. Соодветно на тоа, можеме да претпоставиме дека е применливо за даден елемент (во повеќето случаи, ова е токму логиката што се користи).
Што се однесува до Модулот Менаџер, тој опишува некоја заедничка акција за група или за сите елементи на директориумот или некој документ. На пример, ако треба да испечатите ставка од директориум, можете да го користите Модулот за објект.
Но, во модулот на менаџерот е можно да се создаде поуниверзален механизам кој ќе печати, меѓу другото, група елементи.
Дополнително, пристапот до објектот Модул е сè уште подолго дејство. Затоа, подобро е да се реши овој проблем во менаџерскиот модул.
Ова го завршува нашето запознавање со модулите во конфигурацијата на системот 1C: Enterprise. Ако накратко ги сумираме сите горенаведени, во крајна линија се следните заклучоци:
- Софтверски модул е дел од конфигурацијата што може да содржи само текст на вградениот јазик 1C
- Софтверските модули се класифицирани според типовите што ги разгледавме во оваа статија. Секој поглед се одредува според неговата поставеност и достапниот програмски контекст.
- Структурата на модулот се состои од неколку делови, кои се распоредени во одредена низа. Составот на деловите се одредува според типот на модулот.
Исто така, забележете дека намерно испуштивме еден тип на модул, имено командниот модул. Не е ништо извонредно и ве покануваме да се запознаете со неговата функционалност.
Досега, го разгледувавме целиот наш програмски код одделно од апликациското решение и, по правило, го пишувавме во некоја наша мала тест конфигурација. Дали сте свесни дека „не можете само да одите“ и да започнете со уредување на кодот на стандардна конфигурација? Не? Потоа во следната статија ќе објасниме се!
Авк 693 22.12.13 22:44 Моментално на тема
() Да почнеме со главната работа. Глупости и глупости се обид да се обојат изразите со емоции. Што е доста тешко да се направи преку епистоларниот жанр. Значи ова е израз на мое недоразбирање, а не обид за навреда. Убаво е да имаш работа со некој што го разбира ова. Ако те навредив, извини.
Аналогијата е едноставно несоодветна, поради природата на OOP. OOP е наследник на процедурално, модуларно програмирање. Тоа е исто како да ги споредувате таткото и синот, додека го држите синот како пример за таткото.
Тешко е да се расправа со изјавата. Но, значењето на оваа забелешка е слабо поврзано со пасусот коментиран во статијата.
Ова е поврзано со примерот даден во статијата. Таму, методот има директива за компилација и поради некоја причина клучниот збор „извоз“ е испуштен.
Само затоа што никогаш не морал да направи нешто не значи дека тоа не е релевантно или дека другите не го прават тоа.
Да. Не морав да менувам заеднички модули за надворешна обработка. Моравме да направиме различни верзии за различни конфигурации.
Во типична апликација, тие често се користат за решавање на чисто проблеми со интерфејсот:
Тоа е тоа, на вообичаен начин. Не ја предвидувам неговата смрт (многу добро и докажано решение), но трендовите се такви што 1C се движи сè подалеку кон дистрибуирано пресметување, со експлицитна распределба на кодот според местата каде што работи. Овде ретко функционира (ако воопшто функционира): „Сè е на клиентот, и ние ќе го сфатиме“ или „Ајде да го повлечеме серверот неколку пати - на крајот на краиштата, имаме гигабит“.
Мислам дека би било корисно да се прошири апстракцијата својствена за концептот на „GeneralModule“ и да се воведе во конфигурацијата
ентитети од нов тип, да речеме, „ExecutableModule“, слични на објектите на модулот од MS VBA.
„GeneralModules“ би бил посебен случај на објекти „ExecutableModule“, лоциран приближно
во ист однос како и објектите „Општа форма“ и едноставно „Форма“....
За почеток, би било убаво да се имплементираат имиња на простори и метаподатоци на модулите во 1C, а не како што е сега (цитат од асистентот за синтакса); „Недефинирано - затоа што не се очекува да работи од вградениот јазик“
Да претпоставиме дека бројот на состојби што се користат во формата е голем и да го претпоставиме тоа
при користење на формулар, веројатноста за реализација на одредена состојба е мала;
Во класичното веб-програмирање, ова се решава со можноста за вградување форми во форми и асинхрони повици (AJAX), за жал тоа беше игнорирано од 1C. Значи, остануваат три опции:
1. Користете различни форми
2. Префрлете ги сите потребни податоци на клиентот
3. Повлечете го серверот.
Општо земено, повиците на серверот надвор од контекст не се сметаат за лоша работа и треба да се избегнуваат.
- Во принцип, дури и постои мислење (со кое навистина не се согласувам) дека некој вид „екстра“ број
Контексните повици на серверот се помалото зло ако нивната оптимизација „исто така“ ја збунува „читливоста“ на кодот.
Повиците на серверот надвор од контекст се дизајнирани да го намалат сообраќајот при пренос на податоци од клиентот на серверот. Само така се разликуваат од контекстуалните.
Пример 1: треба да добиете договорна страна врз основа на документот.
клиентски сервер
1. форма за избор --> добивање форма
2. При менување<--
3. Добијте договорна страна --> DocumentBase[„Договорна страна“]
Во третиот чекор, нема смисла да се влече целата форма, со сите детали, до серверот. Затоа, препорачливо е да се користи OnServerWithoutContext.
Во вашата верзија можете едноставно да користите:
За методите на објектниот модул:
&OnServerWithout Context
Функција Something_with_something (ProcessingObject, ProcessingTypeString, параметри)
Врати FormDataValue(ProcessingObject, Type(ProcessingTypeString)).FunctionNeed(Параметри);
Крајна функција
За методите на менаџерскиот модул:
&OnServerWithout Context
Функција Something_with_something (Име, параметри)
Обработка на враќање[Име].FunctionWeNeed(Параметри);
Крајна функција
Прашање: Како можам да повикам функција од управувана форма содржана во модул на друг објект?
Како да повикате функција од управувана форма содржана во модул на друг објект?
Се трудам:
&На серверот
Процедура MyProcedure() Processing = Form AttributesValue("Record", Type("ProcessingObject.NecessaryProcessing")); Резултат = Processing.ExportProcedureInNecessaryProcessingModule("NecessaryParameter"); Грешка на крајот на постапката: неважечки параметар бр. 1
Одговор:И ова се однесува не само за обработка - туку воопшто, во принцип, дури и за какви било предмети.
Можете исто така да ги пополните деталите и другите глупости што се таму од една до друга обработка.
Здраво!
Ве молам дајте ми пример за код за тоа како можете програмски да повикате пополнет печатен формулар користејќи врска до објект,
На пример,
link=Documents.InvoiceIssued.FindByCode(...);
...
врска...Добијте податоци од формуларот за печатење...
и така натаму
Одговор:Повикајте ја командата од која се повикува печатењето на овој документ и во него има еден параметар - ова е вашиот документ.
Прашање: управувани обрасци во UPP 1.3
Добар ден Во конфигураторот создавам обработка со управувана форма (префрли го знамето на управувано). Во режим на претпријатие воопшто не се отвора. Кој наиде на тоа? како да се отвори креираната управувана форма?
Одговор:+() Класици на жанрот:
<<К сожалению, это невозможно. Свойство "Использовать управляемые формы в обычном приложении" не влияет на внешние обработки и отчёты. В обычном приложении можно открывать только обычные формы таких объектов, а в управляемом только управляемые. Это ограничение платформы.>>
Прашање: [РЕШЕНО] Повикување на процедура на модул за формулари од модул за формулари со управувана надворешна обработка
Почитувани експерти, ве молам кажете ми:
8.3.9.2170
Како да повикате процедура на модулот за формулари на овој документ од клиентска процедура на модул за надворешен формулар за обработка (EF) врзан за документ?
Ви благодарам
Одговор:
Добијте форма на документ и повикајте ја саканата функција за извоз во добиениот модул за формулари.
Прашање: Управувани формулари, како и дополнителни. детали за директориумот
Здраво!
Конечно почнав да работам со управувани форми, но и дополнителни. детали за директориумот што беа внесени во режим на претпријатие.
1C: Enterprise 8.3 (8.3.8.2054), 1C:Integrated Automation 2 (2.2.3.196).
За жал, наидов на проблем и не можев да гуглам решение.
Суштината е оваа - има надворешна обработка, во неа корисникот избира ставка, по што другите полиња од оваа обработка треба автоматски да се пополнат со дополнителни. детали за оваа номенклатура. Се сопнав на самиот почеток - се обидувам да ги добијам овие додатоци со барање. реквизити.
| 1C | ||
|
||
Прашања
"(ExternalProcessing.PrintLabels.Form.Form.Form(11)): Грешка при повикување на методот на контекст (RequestAdditionalDetails)
Дополнителни детали = Барање за дополнителни детали (Објект. Номенклатура);
поради:
Грешка во преносот на податоци помеѓу клиентот и серверот. Вредноста е од неважечки тип.
поради:
Грешка при конверзија на податоци XDTO:
HomeProperties: ret Форма: Тип на елемент: (http://www.w3.org/2001/XMLSchema)anyType
поради:
Тип грешка при мапирање:
Нема приказ за типот „(http://v8.1c.ru/8.1/data/core)ValueTable““
Ве молам, помогнете!
Додадено по 9 минути
Во редот 28 „Барање за резултат за враќање за дополнителни детали;“ се враќа табела со вредности. Се обидувам да ја назначам променливата „Дополнителни детали“ на клиентот како „Нова табела со вредности“ - програмата се жали дека не знае што е „Табела со вредности“. Се обидувам да го сменам контекстот од „NaClient“ во „NaServer“ - тогаш веќе не се жали, но дебагерот исто така престанува да работи.
Одговор:Фала за одговорот!
Ставете табеларен дел од слична структура на формуларот
Но, зошто на корисникот му е потребен овој табеларен дел? Само непотребен метеж на форми за обработка.
Додадено по 6 минути
Ќе се обидам едноставно да создадам таб. дел од обработката (без да го ставите на формуларот) и вчитајте го резултатот во него.
И така се случи! Ви благодарам!
Прашање: Работа со табела со вредности во управувана форма
Добар ден. Табелата на вредности никогаш не престанува да ме восхитува. Еве го вистинското прашање: Јас создавам надворешна обработка (контролирана форма). Создавам атрибут „TK“ со типот „Табела со вредности“. И го влечем на формуларот. Следно, во модулот за формулари, пишувам „TZ“, а по точката во паѓачката листа не го гледам својството „Колони“. Следно, креирам програмски:
и напишете „TZ“ во паѓачката листа постои имот „Колони“. Прашањето е зошто????????
Одговор:
Порака од Бриолин
И 1c треба да се направи за да биде напишано директно во конфигураторот дека атрибутот на формуларот има податочен тип DataFormsCollection!
Тогаш нема да биде јасно на кој објект на апликација може да се преведе ова
Прашање: Управувана форма (пристапност на елемент)
Користејќи ја платформата UTeshki 10.3.40.1 8.3.9.2033 Правам формулар за избор на производ на веб. Создадов нова улога и постепено почнав да отворам пристап до објекти за неа. Сè беше во ред додека не стигнав до директориумот Вредности на својствата на објектите. Јасно е дека во 10 нема управувани форми, сите се генерираат во процесот, но ако формуларот за избирање на истите „Својства на објектот“ се креира нормално, тогаш се креира формуларот за избор на „Вредности на својства на објекти“. со неактивни елементи... А што не сум пробал - права на Читање, гледајќи ги и референтната книга и Планот на видови карактеристики.Својства на предметите... ништо не помага. Каде да се копа? Опцијата да се направи посебен формулар и да се запише сè таму не треба да се понуди во случај причината да остане нејасна.
Одговор:Можеби пристапноста е поставена во самата форма според некој услов?
Прашање: Кога затворам формулар за управуван директориум, пишувам во регистарот за информации,
При затворање на формуларот за управуван директориум, пишувам во регистарот за информации,
Ако се креира нов запис во директориумот, тогаш грешката е што објектот на директориумот сè уште не е креиран. Не разбирам како да чекам да се креира објектот на директориумот.
На крајот на краиштата, јас го нарекувам при затворање на формата на директориумот?
&На серверот
Procedure When ClosingOnServer() Set=InformationRegisters.ContactInformation.CreateRecordSet(); Set.Select.Object.Set(current_.Object); Set.Selection.Type.Set(current_.type); Set.Selection.View.Set(current_.view);
Одговор:() Можеби ова е непотребно во неговото спроведување. () Мислам дека не се изрази правилно. Ова значеше изменети податоци. Нешто слично направи и кога ја воведе интернационализацијата, складирајќи низи со детали со англиски/шпански и други имиња. За да не правам реквизити за објектот за секој јазик, ставам се во регистарот. И снимањето се правеше паралелно со снимање на кој било именик, вака нешто.
Прашање: Структура на елементи на управувана форма. Како да го пронајдете саканиот елемент без да пребарувате низ елементите?
Треба да пронајдете поле за табела на управувана форма. Ова го правам со повторување на сите елементи на формата. Можеби постои некој друг начин да се најде саканиот елемент на управувана форма?
Пример за пребарување на брутална сила:
//******** FlFoundTablePart = Неточно; За секој El From _ThisForm.Elements Cycle If TypeValue(El)<>Внесете ("FormTable") Потоа Продолжи; крајАко; Ако El.DataPath = „Објект“. + _TablePartName Потоа FlFoundTabularPart = Точно; Прекини; крајАко; Краен циклус; //*****
Прашање: Напишете() во управувана форма
Ситуацијата е следна:
Имам ZUP 3.0. Постои документ „Промена на табелата за персонал“. Кадровските позиции во една организација може да се воведат привремено. За да го направите ова, користејќи го копчето, се креира документ од изворниот документ за избраните позиции за да се исклучат позициите. Треба да ја зачувам оваа врска. За да го направите ова, создадов атрибут со типот „Промени табела за персонал“.
Откако ќе го напишам документот програмски, ја пишувам врската во овој атрибут. Го повикувам методот за пишување од управувана форма со параметри... И тој го зема и го поставува режимот на снимање на Спроведување. Очигледно, го комплетирав оригиналниот документ! но треба да запишам 1 детаљ и НЕ повторно да го објавам оригиналниот документ. Како да не го виде мојот параметар. Кодот е подолу. Прашањето е што згрешив?
DisintegrationDocument.Write(DocumentWriteMode.Write);
Object.itr_DestructionDocument = DisassemblyDocument.Link; Параметри за запис = Нова структура(); RecordingParameters.Insert("RecordingMode",DocumentRecordingMode.Recording); ThisForm.Record(RecordParameters);
Одговор:Всушност, најдов како да го направам тоа... па ќе го споделам.
Треба програмски да примите објект за уредување и покрај фактот што формуларот е отворен, да го уредите и напишете на вообичаен начин, а потоа едноставно повторно да го прочитате формуларот.
