Перемикачі, звичайний додаток, керовані форми. Перемикачі, звичайна програма, керовані форми 1c проблеми з керованими формами
Платформа 1С: Підприємство дозволяє програмно додавати та змінювати елементи керованої форми. Розберемося для чого це може знадобитися.
Програмна модифікація форми може знадобитися в кількох випадках:
- При доопрацюванні типових конфігурацій для полегшення процедури подальшого оновлення. У цьому випадку буде змінено лише модуль форми. Модулі набагато простіше оновлювати, ніж форму.
- За реалізації деяких загальних алгоритмів. Наприклад, у підсистемі "Заборона редагування реквізитів об'єктів" для всіх підключених до підсистеми об'єктів передбачено програмне створення кнопки для включення можливості редагування реквізитів.
- За реалізації деяких специфічних алгоритмів. Наприклад, у довіднику Номенклатура створюються поля для редагування додаткових реквізитів.
У керованій формі можна програмно додати, змінити та видалити:
- реквізити;
- локальні команди;
- елементи.
Всі ці операції можливі лише на сервері.
Програмна зміна форми має обмеження:
- Видалити можна лише програмно додані реквізити/команди/елементи. Не можна програмно видалити об'єкти, створені у конфігураторі.
- Не можна призначити реквізит головним.
Зміна команд форми
Для керування складом команд у об'єкта КерованаФормає колекція Команди
Додати (< ИмяКоманды >)
Кількість ()
Знайти (< ИмяКоманды >)
видалити (< Команда >)
Колекція команди доступна як на клієнті, так і на сервері. Змінювати колекцію (методи Додати () та Видалити () ) можна лише на сервері. Шукати та отримувати кількість елементів (методи Знайти () та Кількість () ) можна як на клієнті, так і на сервері.
Як приклад роботи з командами форми створимо нову команду Історія Змін із заголовком «Історія змін…», яка буде викликати обробник ВідобразитиІсторію(). Створення виконується під час відкриття форми.
&На сервері
Процедура При створенні на сервері (Відмова, Стандартна Обробка)
Команда = Команди. Додати( "Історія змін");
Команда . Дія =;
Команда . Заголовок = "Історія змін…";
КінецьПроцедури
&На Клієнті
Процедура Підключається_ВідобразитиІсторію(Команда)
// дії команди
КінецьПроцедури
Обробник команди повинен розташовуватися у формі та мати директиву компіляції & На Клієнті.
Зміна реквізитів форми
Читання складу реквізитів форми виконується функцією ОтриматиРеквізити(< Путь >) , що повертає масив типу РеквізитФорми . Параметр функції вказує шлях до батьківського реквізиту (у вигляді рядка). Якщо параметр опущено або вказано порожній рядок, повертаються реквізити верхнього рівня.
Зміна реквізитів виконується методом ЗмінитиРеквізити(<Реквізити, що додаються>, <ВидаленіРеквізити>) об'єкта КерованаФорма. У параметри Реквізити, що додаютьсяі ВидаленіРеквізитипередаються масиви з елементами типу РеквізитФорми.
Увага!
Процес зміни складу реквізитів є досить ресурсомістким. Фактично виконується перестворення форми. У зв'язку з цим робота з реквізитами форми виконується пакетному режимі.
Створимо новий реквізит форми з ім'ям Покупець:
Реквізити, що додаються = Новий Масив;
Реквізити, що додаються. Додати(Новий РеквізитФорми(«Покупець», Новий Опис Типів («Довідник Посилання.Контрагенти»), «Клієнт»));// Зміни складу реквізитів
);
Зміна елементів форми
Для керування складом елементів у об'єкта КерованаФормає колекція Елементи. Колекція має кілька методів:
Вставити (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)
Додати (< Имя>, < ТипЭлемента>, < Родитель >)
Кількість ()
Знайти (< Имя >)
Перемістити(< Элемент>, < Родитель>, < МестоРасположения >)
видалити (< Элемент >)
Колекція Елементи доступні як на клієнті, так і на сервері. Змінювати колекцію (методи Вставити () , Додати () , Перемістити () та Видалити () ) можна лише на сервері. Шукати та отримувати кількість елементів (методи Знайти () та Кількість () ) можна як на клієнті, так і на сервері. Елементами колекції можуть бути:
- ГрупаФорми;
- ТаблицяФорми;
- ПолеФорми;
- КнопкаФорми.
Елементам форми можна програмно призначити обробники подій. Для цього призначений метод Встановити Дію (< ИмяСобытия>, < Действие >) .
Розглянемо кілька найпоширеніших практично прикладів роботи з командами, реквізитами і елементами форми.
Додавання команди та пов'язаної з нею кнопки:
// Створення команди
Команда = Команди. Додати( "Історія змін");
Команда . Дія = «Підключається_Відобразити Історію»; // У формі має бути процедура із зазначеним найменуванням
Команда . Заголовок = "Історія змін…";
// Створення кнопки та зв'язок її з командою
Елемент = Елементи. Додати( "Історія змін", Тип («КнопкаФорми»));
Елемент.Ім'яКоманди = "Історія змін";
Додавання реквізиту та пов'язаного з ним поля введення:
// Опис реквізитів, що додаються
Реквізити, що додаються = Новий Масив;
Реквізити, що додаються. Додати(Новий РеквізитФорми («Покупець» , Новий ОписТипів ( «ДовідникПосилання.Контрагенти»), «Клієнт»));
// Зміна складу реквізитів
ЗмінитиРеквізити(ДодаютьсяРеквізити));
// Створення поля введення та зв'язок з реквізитом
Елемент = Елементи. Додати («Покупець», Тип («ПолеФорми»));
Елемент . Вигляд = ВидПоляФорми. Поле введення;
Елемент . ШляхДаним= «Покупець»;
Призначення елемента форми обробника події:
ЕлементПокупець. Встановити Дію("При зміні" , «Підключається_ПокупецьПриЗміні»);
&На Клієнті
Процедура Підключається_ПокупецьПриЗміні(Елемент)
// Дії події
КінецьПроцедури
Увага!
Процедурам, які встановлюються як обробники подій з коду за допомогою методу Встановити Дію(), рекомендується задавати префікс Підключається_.
Увага!
Завантажити обробку з прикладами програмного пошуку та зміни реквізитів, команд та елементів керованої форми можна.
Data Transfer Object до структуризації коду, керованої форми в середовищі 1С 8.2.
Вступ
Почнемо з невеликого опису поняття «керована форма» та пов'язаних концепцій платформи 1С. Файли платформи можуть пропустити цей розділ.У 2008 році стала доступна нова версія платформи 1С: Підприємство 8.2 (далі Керований додаток), яка повністю змінює весь шар роботи з інтерфейсом. Сюди і командний інтерфейс, і форми, і віконна система. При цьому не тільки змінюється модель розробки інтерфейсу користувача в конфігурації, але і пропонується нова архітектура поділу функціональності між клієнтським додатком і сервером.
Керований додаток підтримує такі типи клієнтів:
- Товстий клієнт (звичайний та керований режим запуску)
- Тонкий клієнт
- Веб-клієнт
Основні відмінності керованих форм для розробника:
- Декларативний, а не «за пікселями» опис структури. Конкретне розміщення елементів виконується системою автоматично, коли відображається форма.
- Вся функціональність форми описується як реквізитіві команд. Реквізити – це дані, з якими працює форма, а команди – дії, що виконуються.
- Форма виконується і на сервері, і на клієнті.
- У контексті клієнта недоступні практично всі прикладні типи, і, відповідно, неможливо змінити дані в інформаційній базі.
- Для кожного методу або змінної форми обов'язково має бути вказано директива компіляції, визначальна, місце виконання (клієнт або сервер) та доступ до контексту форми.
- &На Клієнті
- &На сервері
- &На СерверіБезКонтексту
- &НаКлієнтіНаСерверіБезКонтексту
Всі подальші міркування будуть про праву частину ілюстрації, про те, як структурувати код модуля та які принципи дозволять реалізувати ефективну клієнт-серверну взаємодію.
Позначимо проблему
Пройшло вже кілька років, як нова версія платформи 1С активно використовується і випущено безліч рішень (конфігурацій) як фірмою 1С, так і її численними партнерами.Чи склалося за цей час у розробників єдине розуміння принципів клієнт-серверної взаємодії при створенні форм і чи змінився підхід до реалізації програмних модулів у нових архітектурних реаліях?
Розглянемо структуру коду (модуль форми) у кількох формах однієї типової конфігурації та спробуємо визначити закономірності.
Під структурою розумітимемо секції коду (найчастіше це блоки коментарів) виділені розробником для групування методів та директиви компіляції цих методів.
Приклад 1:
Секція обробників подій Метод - наклієнт Метод - насервер Метод - наклієнт Секція службових процедур та функцій Допоміжні функції управління введенням
Приклад 2:
Службові процедури та функції Документи оплати Цінності Обробники подій
Приклад 3:
Службові процедури на сервері Службові процедури на клієнті Службові процедури на сервері без контексту Обробники подій шапки Обробники подій команд
Приклад 4:
Процедури загального призначення Обробники подій форми Процедури підсистеми «контактна інформація»
По суті, структура коду відсутня, або, м'якше кажучи, вона аналогічна тому, що було у формах 8.1:
- Неінформативні слова "Загальні, Службові, Допоміжні".
- Неробкі спроби розділити клієнтські та серверні методи.
- Часто методи групуються за інтерфейсними елементами "Робота з табличною частиною Товари, Контактною інформацією".
- Довільне розташування методів та груп коду. Наприклад, обробники подій можуть бути в одній формі вгорі, в іншій внизу, в третій взагалі не виділені і т.д.
- І не забуватимемо, що це все в рамках однієї конфігурації.
- Так бувають конфігурації, в яких слова «Загальні, Службові, Допоміжні» завжди знаходяться на одних і тих же місцях, але…
Навіщо потрібна структура коду?
- Спрощення супроводу.
- Спрощення навчання.
- Фіксація загальних/важливих/вдалих принципів.
- …ваш варіант
Чому існуючий стандарт розробки фірми 1С не допомагає?
Подивимося опубліковані на дисках ІТС та в різних «Посібниках розробника…» принципи, що рекомендуються при написанні керованої форми.- Мінімізуйте кількість серверних дзвінків.
- Максимум обчислень на сервері.
- Неконтекстні виклики сервера швидше за контекстні.
- Програмуйте з урахуванням клієнт-серверної взаємодії.
- і т.п.
Шаблони проектування чи мудрість поколінь
Клієнт-серверна взаємодія використовується у різних програмних технологіях не один десяток років. Відповідь на зазначені у попередньому розділі питання давно відома та підсумовована у двох базових принципах.- Remote Facade(далі Інтерфейс віддаленого доступу)
- Data Transfer Object(далі Об'єкт перенесення даних)
- … кожен об'єкт, потенційно призначений для віддаленого доступу, повинен мати інтерфейс з низьким ступенем деталізації, що дозволить максимально зменшити кількість дзвінків, необхідних для виконання певної процедури. … Замість того, щоб запитувати рахунок та всі його пункти окремо, треба рахувати та оновити всі пункти рахунку за одне звернення. Це впливає на всю структуру об'єкта. Запам'ятайте: інтерфейс віддаленого доступу не містить логіки домену.
- …якби я був дбайливою мамою, то обов'язково сказав би своїй дитині: «Ніколи не пиши об'єкти перенесення даних!» У більшості випадків об'єкти перенесення даних є не більш ніж роздутий набір полів… Цінність цього огидного монстра полягає виключно у можливості передавати по мережі кілька елементів інформації за один дзвінок- Прийом, який має велике значення для розподілених систем.
Приклади шаблонів у платформі 1С
Прикладний програмний інтерфейс доступний розробнику при розробці керованої форми містить багато прикладів даних принципів.Наприклад, метод ВідкритиФорму(), типовий «огрублений» інтерфейс.
ПараметриВідкриття = Новий Структура("Параметр1, Параметр2, Параметр3", Значение1, Значение2, Значение3); Форма = Відкрити Форму (Ім'я Форми, Параметри Відкриття);
Порівняйте з прийнятим у v8.1 стилем.
Форма = ОтриматиФорму(Ім'яФорми); Форма.Параметр1 = Значення1; Форма.Параметр2 = Значення2; Форма.Відкрити();
У контексті керованої форми безліч "Об'єктів перенесення даних". Можна виділити системніі обумовлені розробником.
Системні моделюють на клієнті прикладний об'єкт у вигляді одного або декількох елементів даних форми. Створити їх поза прив'язкою до реквізитів форми не можна.
- ДаніФормиСтруктура
- ДаніФормиКолекція
- ДаніФормиСтруктураСколекцією
- ДаніФормиДерево
- ЗначенняДаніФорми()
- ДаніФормиЗначення()
- КопіюватиДаніФорми()
- ЗначенняВРеквізитФорми()
- РеквізитФормиЗначення()
Приклад 1С v8.1:
// на клієнта в контексті форми ЗаповнитиКеш Користувачів(Підрозділ Посилання)
Приклад 1С v8.2:
// на сервері в контексті форми Обробка Об'єкт = Реквізит ФормиЗначення ("Об'єкт"); ОбробкаОб'єкт.ЗаповнитиКешКористувачів(Підрозділ Посилання); ЗначенняВРеквізитФорми(ОбробкаОб'єкт, "Об'єкт");
Об'єкти перенесення даних, структура яких визначається розробником це невелике підмножина типів доступних і клієнта, і на сервері. Найчастіше як параметри і результати методів «огрубленого» інтерфейсу використовуються:
- Примітивні типи (рядок, число, булева)
- Структура
- Відповідність
- Масив
- Посилання на прикладні об'єкти (унікальний ідентифікатор та текстове подання)
&НаСерверіБезКонтексту Функція СерверЗмінитиСтатусЗамовлень(Замовлення, НовийСтатус) Помилки = Новий Відповідність(); // [замовлення][опис помилки] Для Кожного Замовлення Із Замовлення Цикл ПочатиТранзакцію(); Спроба ДокОб = Замовлення. Отримати Об'єкт (); …. інші дії, можливо не тільки із замовленням… Виняток Скасувати транзакцію(); Помилки.Вставити(Замовлення, ОписПомилки()); КінецьСпроби; КінецьЦикл; Повернення Помилки; КінецьФункції // СерверЗмінитиСтатусЗамовлень()
Структуруємо код
Головні цілі, які має відображати модуль керованої форми та підходи до вирішення.- Чіткий поділ клієнтського та серверного коду.Не забуватимемо, в момент виконання це два взаємодіючі процеси, у кожному з яких суттєво відрізняється доступний функціонал.
- Чітке виділення інтерфейсу віддаленого доступу, які методи сервера можна викликати з клієнта, а які не можна? Назви методів віддаленого інтерфейсу починаються з префіксу Сервер. Це дозволяє читати код відразу бачити перехід управління на сервер, і спрощує використання контекстної підказки. Зазначимо, що офіційна рекомендація (ІТС) пропонує називати методи з постфіксами, наприклад, так ЗмінитиСтатусЗамовленьНа Сервері(). Однак повторимо не всі серверні методи можна викликати з клієнта, і тому важливіша логічна доступність, а не місце компіляції. Тому префіксом «Сервер» відзначаємо лише методи доступні для клієнта, метод-приклад назвемо СерверЗмінитиСтатусЗамовлень().
- Зручність.Справа смаку, приймаємо порядок, коли модуль починається з процедур створення форми на сервері та методів віддаленого доступу.
- Супроводжуваність.Повинне бути однозначно визначено місце додавання нового коду. Важливий момент, автоматично створювані конфігуратором заготовки методів додаються до кінця модуля. Оскільки найчастіше автоматично створюються обробники подій елементів форми, то відповідний блок розташований останнім, щоб не перетягувати кожен оброблювач в інше місце модуля.
- Графічний варіант – наочно показує основний потік виконання.
- Текстовий варіант - це приклад оформлення шаблону для швидкої вставки структури новий модуль форми.
//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Дата=""/> // <Описание> // // //////////////////////////////////////////////////// ////////////////////////////// // ЗМІННІ МОДУЛЯ ///////////////// //////////////////////////////////////////////////// /////////////// // НА СЕРВЕРІ //******* ПОДІЇ НА СЕРВЕРІ ******* &НаСервері Процедура ПриСтворенніНаСервері(Відмова, СтандартнаОбробка) //Вставити вміст обробника КінецьПроцедури //******* ІНТЕРФЕЙС ВІДДАЛЕНОГО ДОСТУПУ ******* //******* БІЗНЕС-ЛОГІКА НА СЕРВЕРІ ******* ///////// //////////////////////////////////////////////////// ////////////////////// // ЗАГАЛЬНІ МЕТОДИ КЛІЄНТА І СЕРВЕРУ /////////////////////// //////////////////////////////////////////////////// //////// // НА КЛІЄНТІ //******* БІЗНЕС-ЛОГІКА НА КЛІЄНТІ ******* //******* КОМАНДИ ******* //******* ПОДІЇ НА КЛІЄНТІ ******* /////////////////////////////// //////////////////////////////////////////////////// / ОПЕРАТОРИ ОСНОВНОЇ ПРОГРАМИ
Пов'язані питання
На закінчення позначимо кілька напрямів, про які корисно подумати під час програмування клієнт-серверної взаємодії.- Варіанти реалізації інтерфейсу віддаленого доступу. Асинхронність, ступінь деталізації.
- Кешування.В 1С прийняли невдале архітектурне рішення, ввівши кешування лише на рівні виклику методів загальних модулів і не надавши можливості керування (час актуальності, скидання на вимогу).
- Неявні серверні дзвінки. Не забувайте про технологічні особливості, багато «нешкідливих» операцій на клієнті провокують платформу на звернення до сервера.
Формив 1С:Підприємстві призначені для відображення та редагування інформації, що міститься в базі даних. Форми можуть належати конкретним об'єктам конфігурації чи існувати окремо від нього і використовуватися всім прикладним рішенням загалом.
Наприклад, довідник Номенклатураможе мати кілька форм, які будуть використовуватися для певних цілей – редагування елемента довідника, відображення списку тощо:
Поруч із, можуть існувати загальні форми, які не належать конкретним об'єктам зміни - загальні форми.
Основні форми
Кожен конфігураційний об'єкт може використовуватися для виконання деяких стандартних дій. Наприклад, для будь-якого довідника може знадобитися відображати список його елементів, відображати окремі елементи довідника, відображати групу довідника, вибирати елементи та групи елементів з довідника. Для будь-якого документа список таких дій буде набагато меншим: перегляд списку документів, вибір зі списку документів та перегляд окремого документа.
Щоб забезпечити виконання таких стандартних дій з даними об'єктів прикладного рішення, для кожного існує набір основних форм, які будуть використовуватися при виконанні відповідних дій. Основний може бути призначена будь-яка із форм, підпорядкованих цьому об'єкту. Наприклад, у довідника Номенклатураможуть існувати такі основні форми:
А у документа Надходження товарів та послугсклад основних форм буде вже іншим:
Таким чином, якщо користувач захоче переглянути список довідника Номенклатураабо список документів Надходження товарів та послуг, система відкриє відповідну форму, призначену як форму списку для цих об'єктів.
Автогенеровані форми
Важливою особливістю системи 1С:Підприємство 8 є механізм автогенерованих форм. Цей механізм звільняє розробника необхідності створення всіх можливих форм кожному за об'єктів конфігурації. Розробнику достатньо додати новий об'єкт конфігурації, а система сама згенерує в потрібні моменти роботи користувача необхідні форми для відображення інформації, що міститься в цьому об'єкті.
Таким чином, розробнику потрібно створювати власні форми об'єктів прикладного рішення лише в тому випадку, якщо вони повинні мати відмінності (інший дизайн або специфічну поведінку) від форм, що автоматично генеруються системою.
Зв'язок форми з даними
Приналежність форми тому чи іншому об'єкту конфігурації не визначає склад даних, які у формі. Те, що форма належить, наприклад, довіднику Номенклатура, дозволяє призначити її однією з основних форм для цього довідника, але ніяк не визначає, які саме дані відображатиме ця форма, і якою буде її поведінка.
Щоб зв'язати форму з даними, використовуються реквізити форми, у яких вказується перелік даних, що відображаються формою. Усі форми, власними силами, мають однакову поведінку, незалежно від цього, які дані вони відображають. Однак один із реквізитів форми може бути призначений для неї основним (він виділяється жирним шрифтом), і в цьому випадку стандартна поведінка форми та її властивості будуть доповнені залежно від того, який тип має основний реквізит форми:
Наприклад, якщо в якості основного реквізиту форми буде призначено документ Надходження товарів та послуг, то при закритті форми система буде вимагати підтвердження запису та проведення цього документа. Якщо ж основним реквізитом форми призначити, скажімо, довідник Номенклатура, то подібного запиту підтвердження при закритті форми не виникатиме.
Структура форми
Основна особливість форм у тому, що де вони намальовані розробником детально, «по пікселям». Форма в конфігурації є логічним описом складу форми. А конкретне розміщення елементів виконується системою автоматично, коли відображається форма.
Частина форми, що відображається (видима користувачеві) описується як дерево, що включає елементи форми.
Елементи можуть бути поля введення, прапорці, перемикачі, кнопки і т. д. Крім того, елемент може бути групою, що включає інші елементи. Група може бути представлена як панель з рамкою, панель зі сторінками (закладками), власне сторінка, командна панель. Крім цього елемент може бути таблицею, яка теж включає елементи (колонки). Структура елементів описує, як виглядатиме форма.
Вся функціональність форми описується як реквізитів і команд. Реквізити – це дані, з якими працює форма, а команди – дії, що виконуються. Таким чином, розробник у редакторі форми повинен включити у форму необхідні реквізити і команди, створити елементи форми, що їх відображають, і, якщо необхідно, скомпонувати елементи в групи.
На основі цього логічного опису система автоматично формує зовнішній вигляд форми для відображення користувача. При цьому системою враховуються різні властивості даних, що відображаються (наприклад, тип), щоб максимально зручно для користувача розташувати елементи форми.
Розробник може проводити розташування елементів різними установками. Він може визначати порядок елементів, вказувати бажану ширину та висоту. Однак це лише деякою додатковою інформацією, що допомагає системі відобразити форму.
У формах розробник може використовувати як команди самої форми, а й глобальні команди, які у командному інтерфейсі всієї конфігурації. Крім того, реалізована можливість створення команд, що параметризуються, які відкриватимуть інші форми з урахуванням конкретних даних поточної форми. Наприклад, це може бути виклик звіту про залишки на тому складі, який обраний зараз у формі видаткової накладної.
Ми всі знаємо, що компанія "1С" мала багато різних версій платформи 1С, нас зараз цікавитимуть одні з останніх версій на момент написання цієї статті, це версії 1С 8.2 і 1С 8.3. Якщо Вам доводилося працювати в обох цих версіях, то Ви, швидше за все, помітили різницю в інтерфейсах даних версій, для користувачів вони відрізняються лише зовні. По суті, вибір звичайної або керованої програмикаже системі, які форми для відображення потрібно запускати, звичайні або керовані, а також який клієнт програми буде використовуватися за замовчуванням, товстий або тонкий. Більш детальну інформацію про клієнтів читайте у статті «Що таке товстий і тонкий клієнт у 1С, а також їх відмінності».
Звичайний додаток 1С (звичайні форми, звичайний інтерфейс, версія 1С 8.2)
У 1С 8.2 можлива робота тільки із звичайними формами, у режимі звичайного додатку. На зображенні нижче показано базу в режимі роботи "звичайний додаток 1С" (звичайні форми).
Керований додаток 1С (керовані форми, керований інтерфейс, версія 1С 8.3)
На платформі 1С 8.3 ми можемо працювати як із звичайними формами (у режимі сумісності), так і з керованими. Причому у керованих форм є два види відображення, це стандартний і таксі.. Приклад конфігурації 1С 8.3 зі стандартними керованими формами показаний нижче, а після нього показаний інтерфейс "Таксі".
Чим відрізняються звичайне та кероване додаток 1С?
Як ми вже з'ясували звичайний додаток та керований додаток це такі види запуску програми 1С. Причому залежно від значення виду запуску 1С ( звичайний або керований додаток), за замовчуванням завантажуватиметься певний інтерфейс ( звичайні чи керовані форми), звідси і стільки синонімів цього поняття. Хочемо відзначити, що відмінності в інтерфейсах досить суттєві, керований інтерфейс був повністю перероблений. У принципі, це і є всі відмінності, які бачать рядові користувачі програми 1С. Що стосується програмістів, то керований інтерфейс вимагає написання видозміненого коду, адже технологія вже ведеться в 1С 8.3, а не в 1С 8.2, звідси і всі наслідки. Код також має бути розділений на клієнтський та серверний, вказується це за допомогою відповідних директив у конфігураторі.
Клюєв В.В.
http://prof1c.kklab.ru
РОБОТА З ПЕРЕМИКАЧАМИ
Прошу врахувати всіх користувачів сервісу сайт - матеріали розміщую в розділі Початківцям!
8.2 Керовані форми
Під час вивчення поведінки керованих форм перед програмістами чи розробниками інтерфейсів постає питання - де перемикачі в керованих формах і як додати форму. Дрібниця, але неприємно багато часу витрачається на такі дрібниці, хоча цей час можна було б витратити на розробку та оптимізацію алгоритму, а не проектування форми.
Отже, давайте створимо порожню конфігурацію для розуміння питання або виберіть будь-яку типову.
Перейдіть на групу, яка містить довідники, і для експерименту додайте новий довідник. Хочу зауважити, що конфігурація повинна мати основний режим запуску - Керований додаток.
Отже, створимо новий довідник і додамо реквізит Реквізит1, з типом Булеве
Тепер перейдемо на вкладку Форми та додамо нову форму.
Отже, керована форма створена, тепер попрацюємо з формою і знайдемо все-таки, де перемикач.
Ось наша форма, і на ній ми бачимо наш реквізит, але у вигляді прапорця
То що ж ми зробили не так?
Давайте подивимося на властивості реквізиту, чи є там перемикання на вигляд елемента управління.
І бачимо, що Поле перемикача тут немає!(У чому ми помилилися?
Мабуть, що вид елемента управління формою - залежить від типу даних, повернемося до властивостей форми, саме до вкладці реквізити і змінимо властивості нашого реквізиту - саме його тип «Булево», на тип «Число».
Тепер повернемося знову до властивостей елемента управління і перевіримо, чи додався Вид елемента управління у його властивостях - - - І урра, ми бачимо там вид - Поле перемикача.
Тепер дивимося на форму, що ми бачимо:
Ми бачимо – 3 значення за замовчуванням, 3 перемикачі, але нам потрібно їх два, йдемо знову у властивості реквізиту, і дивимося там властивостей «Кількість колонок»
Для 2 – поставте Кількість колонок – 2.
Це могло б трохи зупинити втомленого програміста)), але тепер і він, і ми це знаємо!
8.2 Традиційні форми.
Занудство з перемикачами у типових формах.
Бувають такі моменти, а вони бувають) коли необхідно доопрацювати якусь готову форму, в якій вже є якісь перемикачі, і вам необхідно додати ще перемикачу на цю форму. Ось тут і виникає якесь занудство, яке забирає багато часу, причому часу не на програмування коду - а марна трата часу для того, щоб вивести для користувача ці перемикачі.
Отже, розглянемо приклад. Є такий документ коригування надходження до 1С УПП – він точно є. Нам одного разу знадобилося до нього додати перемикачі, щоб малювалися трохи різні проводки для бухгалтерського обліку. У чому проблема, здавалося б, треба значить треба, зробимо. Але в цій формі вже є 2 перемикачі.
Ось так виглядає форма, в яку нам потрібно приладнати ще перемикачі.
На вкладці додатково, ми хотіли б розмістити ще два перемикачі. Отже, першу дію сміливо додаємо новий елемент управління в необхідно нам місце його вставляємо.
Здавалося б просто. Створюємо новий реквізит, з типом - "Число" і вставляємо 2 перемикачі, один з яких матиме можливість записати дані в реквізит, а інший ні.
Додаємо новий елемент управління - Перемикач, у таблиці з кількістю та описом перемикачів додаємо Перемикач2, встановлюємо Перемикач1 першим у групі та натискаємо бл. Розміщуємо створені елементи управління формою. Оновлюємо конфігурацію бази даних (F7) та запускаємо на налагодження.
При виконанні (при створенні нового документа в режимі 1С:Підприємство) ми бачимо, що хоч би скільки ми намагалися натиснути на Перемикач2 - нічого не відбувається. Елементи не працюють, оскільки їм потрібно. Тут є одна фішка.
Поверніться до конфігуратора. Виберіть пункт у меню Форма -> Налаштування порядку обходу … (важливо, щоб форма була відкрита на екрані)
Для того, щоб наші Перемикачі запрацювали, необхідно порушити автоматичний порядок та погодитись на ручний. І у формі поставити так, щоб наші перемикачі йшли – один за одним по порядку.
ОК. Оновіть конфігурацію та спробуйте запустити на виконання.
Чудово. Все запрацювало.
Додатково - відео (без звуку, тож все зрозуміло)
