This media is not supported in your browser
VIEW IN TELEGRAM
Работа с git
Очень понравилась картинка - ярко характеризуют работу с гитом, когда всегда что-то идет не так.
В принципе даже сейчас в EDT порой git себя ведет странно, например, cherry-pick я так и не научился в нем делать. В консоли или GitLab это удается сделать сильно проще и быстрее.
#git
Очень понравилась картинка - ярко характеризуют работу с гитом, когда всегда что-то идет не так.
В принципе даже сейчас в EDT порой git себя ведет странно, например, cherry-pick я так и не научился в нем делать. В консоли или GitLab это удается сделать сильно проще и быстрее.
#git
😁4
Что должно получить в конце?
Практически любую задачу лучше начинать с конца. А именно с понимания и проговаривания того, что должно получиться в результате выполнения задачи. Причем не просто сказать - у нас будет новый инструмент. А найти ответ зачем этот инструмент нужен? Как этим инструментом будут пользоваться? Кто этим инструментом будет пользоваться?
Ответы на эти вопросы могут как отменить эту задачу полностью, так и поменять подход к решению. Причем отмена задачи - это очень даже хорошо! Это можно сказать - экономическая необходимость. Ведь в этом случае мы сможем высвобожденные ресурсы направить на другие задачи.
Очень плохо, когда мы что-то сделали, а затем начинаем думать а кому это нужно и как это можно использовать. Это потраченное время зря.
И продумывать интерфейс и проект тоже можно с конца. Если мы знаем, что у нас должно получиться в итоге, то можно понять - а что нам для этого нужно собрать.
Например, у нас сразу есть формат интеграции с банками по самозанятым. Отсюда смотрим, а что нам нужно чтобы эти данные собрать. Думаем, что заполним сами, а что спросим у пользователя. Такой подход позволил не тащить в документ лишние реквизиты, например, нам не нужны договоры с самозанятыми, не нужно подразделение, даже банковский счет наш изначально не нужен. Таким образом, документ сделан исключительно для конкретной цели понятной с самого начала.
#Разработка
Практически любую задачу лучше начинать с конца. А именно с понимания и проговаривания того, что должно получиться в результате выполнения задачи. Причем не просто сказать - у нас будет новый инструмент. А найти ответ зачем этот инструмент нужен? Как этим инструментом будут пользоваться? Кто этим инструментом будет пользоваться?
Ответы на эти вопросы могут как отменить эту задачу полностью, так и поменять подход к решению. Причем отмена задачи - это очень даже хорошо! Это можно сказать - экономическая необходимость. Ведь в этом случае мы сможем высвобожденные ресурсы направить на другие задачи.
Очень плохо, когда мы что-то сделали, а затем начинаем думать а кому это нужно и как это можно использовать. Это потраченное время зря.
И продумывать интерфейс и проект тоже можно с конца. Если мы знаем, что у нас должно получиться в итоге, то можно понять - а что нам для этого нужно собрать.
Например, у нас сразу есть формат интеграции с банками по самозанятым. Отсюда смотрим, а что нам нужно чтобы эти данные собрать. Думаем, что заполним сами, а что спросим у пользователя. Такой подход позволил не тащить в документ лишние реквизиты, например, нам не нужны договоры с самозанятыми, не нужно подразделение, даже банковский счет наш изначально не нужен. Таким образом, документ сделан исключительно для конкретной цели понятной с самого начала.
#Разработка
👍5
Дефектодни
У нас много ошибок в конфигурации. Но все эти ошибки разные: есть просто опечатки, есть некорректные проводки, а есть ошибки для которых потребуется выпускать новую редакцию.
И срок жизни у таких ошибок тоже разный. Какие-то ошибки родились вместе с конфигурацией, а какие-то новые или их только что нашли.
И чтобы побудить разработчиков исправлять застарелые ошибки, которые предположительно больше мешают пользователям, была введена метрика - Дефектодни.
Она считается так - складываются все дни существования по каждой ошибке. Например, одна ошибка существует 10 дней, другая - 150 дней, а третья - 1000, то дефектодни на будут 10 + 150 + 1000 = 1160.
И если исправить одну ошибку застарелую, то можно нехило понизить график с этими дефектоднями.
И если исправить 1 старую ошибку - мы сразу бухнем график вниз.
Но во вложении метрика дефектодней за большой период. На нем видны небольшие снижения, начиная с ноября 2022 год, но существенных изменений, к сожалению, нет.
#Разработка
У нас много ошибок в конфигурации. Но все эти ошибки разные: есть просто опечатки, есть некорректные проводки, а есть ошибки для которых потребуется выпускать новую редакцию.
И срок жизни у таких ошибок тоже разный. Какие-то ошибки родились вместе с конфигурацией, а какие-то новые или их только что нашли.
И чтобы побудить разработчиков исправлять застарелые ошибки, которые предположительно больше мешают пользователям, была введена метрика - Дефектодни.
Она считается так - складываются все дни существования по каждой ошибке. Например, одна ошибка существует 10 дней, другая - 150 дней, а третья - 1000, то дефектодни на будут 10 + 150 + 1000 = 1160.
И если исправить одну ошибку застарелую, то можно нехило понизить график с этими дефектоднями.
И если исправить 1 старую ошибку - мы сразу бухнем график вниз.
Но во вложении метрика дефектодней за большой период. На нем видны небольшие снижения, начиная с ноября 2022 год, но существенных изменений, к сожалению, нет.
#Разработка
Для наглядности график вместе с количеством ошибок. Видно, что в этот период было массовое исправление ошибок. Но график дефектодней не так сильно колеблется. Можно предположить, что исправлялись в основном свежие ошибки.
#Разработка
#Разработка
Media is too big
VIEW IN TELEGRAM
Стол настоящего программиста
Все знают, что 1Сники - не настоящие программисты. Они вместо написания кода разговаривают с клиентами и долго выясняют кто перезакрыл месяц в закрытом периоде. А когда пишут код, то делают это на русском языке, используя непонятные слова - БСП, СКД, сальдо, субконто, ЗУП и ЕРП.
А есть настоящие программисты, которые стройными рядами сидят в кофейнях с макбуками. Прищуром левого глаза определяют сложность алгоритма O(n), а правым глазом, мгновенно рассчитывают и потребление памяти. Любой их код соответствует принципам SOLID, DRY и KISS.
И среди них есть настоящая элита. Это те, у кого дома широкий изогнутый монитор во всю стену, огромное кресло и стол с регулировкой высоты. Вместе с этим столом они поднимаются просто на недосягаемую высоту.
Чтобы этим настоящим программистам там было не одиноко без 1Сников, я вот решил себе тоже такой стол приобрести. Теперь у меня есть стол настоящего программиста. Теперь будем брать эту недосягаемую высоту :)
Все знают, что 1Сники - не настоящие программисты. Они вместо написания кода разговаривают с клиентами и долго выясняют кто перезакрыл месяц в закрытом периоде. А когда пишут код, то делают это на русском языке, используя непонятные слова - БСП, СКД, сальдо, субконто, ЗУП и ЕРП.
А есть настоящие программисты, которые стройными рядами сидят в кофейнях с макбуками. Прищуром левого глаза определяют сложность алгоритма O(n), а правым глазом, мгновенно рассчитывают и потребление памяти. Любой их код соответствует принципам SOLID, DRY и KISS.
И среди них есть настоящая элита. Это те, у кого дома широкий изогнутый монитор во всю стену, огромное кресло и стол с регулировкой высоты. Вместе с этим столом они поднимаются просто на недосягаемую высоту.
Чтобы этим настоящим программистам там было не одиноко без 1Сников, я вот решил себе тоже такой стол приобрести. Теперь у меня есть стол настоящего программиста. Теперь будем брать эту недосягаемую высоту :)
👍6🔥2🙈2
Слабое и обычное отображение групп
У группы есть свойство - Отображение, которое может выделить элементы группы на форме.
И если с Сильным выделением все понятно, то вот разницу между слабым и обычным выделением заметить сложно. На картинке они выглядят практически одинаково.
Отличие в том, что у группы с Обычным выделением отступ вокруг становится больше. Она как бы «отпихивает» от себя остальные элементы и делается заметнее.
Разницу можно увидеть если менять свойство в EDT (смотри гифку).
Вот как это свойство используется в Бухгалтерия предприятия:
1. Сильное выделение встречается в 86 формах
2. Обычное выделение - 609 формах
3. Слабое выделение - 1595 формах. Причем большинство - это формы списка и выбора и группа СписокКомпоновщикНастроекПользовательскиеНастройки
#Design
У группы есть свойство - Отображение, которое может выделить элементы группы на форме.
И если с Сильным выделением все понятно, то вот разницу между слабым и обычным выделением заметить сложно. На картинке они выглядят практически одинаково.
Отличие в том, что у группы с Обычным выделением отступ вокруг становится больше. Она как бы «отпихивает» от себя остальные элементы и делается заметнее.
Разницу можно увидеть если менять свойство в EDT (смотри гифку).
Вот как это свойство используется в Бухгалтерия предприятия:
1. Сильное выделение встречается в 86 формах
2. Обычное выделение - 609 формах
3. Слабое выделение - 1595 формах. Причем большинство - это формы списка и выбора и группа СписокКомпоновщикНастроекПользовательскиеНастройки
#Design
На выходных меня познакомили с нейросетью Suno, в которой можно писать песни, как например вот эта - https://suno.com/song/945c8ca9-e029-447d-9a67-d777ca893983
Песня получилась огонь! Даже не ожидал. Причем просто вводишь простой промт и можешь выбрать жанры - клик - 30 секунд и полностью готовая песня.
Ну и раз речь зашла про нейросети, то поделюсь еще одной находкой - https://app.khoj.dev
Это бесплатная штука и в ней есть различные агенты-собеседники. Например, техлид, который помогал мне проработать архитектуру для нового проекта.
Есть еще агент Марвин - депрессивный робот, но с ним лучше познакомиться самим :)
#AI
Песня получилась огонь! Даже не ожидал. Причем просто вводишь простой промт и можешь выбрать жанры - клик - 30 секунд и полностью готовая песня.
Ну и раз речь зашла про нейросети, то поделюсь еще одной находкой - https://app.khoj.dev
Это бесплатная штука и в ней есть различные агенты-собеседники. Например, техлид, который помогал мне проработать архитектуру для нового проекта.
Есть еще агент Марвин - депрессивный робот, но с ним лучше познакомиться самим :)
#AI
👍3❤2
Эволюция доверия
Нашел вот эту потрясающую игру-иллюстрацию эволюции или кризиса доверия - https://notdotteam.github.io/trust/
Она займет минут 30, но очень рекомендую ее посмотреть.
Игра в ненавязчивой форме рассказывает и иллюстрирует стоит или не стоит доверять людям в долгосрочной перспективе. Единственное, что там придется относительно много читать.
А так это вариация на тему Дилеммы заключенных, которая очень подробно рассматривается в Теории игр.
Нашел вот эту потрясающую игру-иллюстрацию эволюции или кризиса доверия - https://notdotteam.github.io/trust/
Она займет минут 30, но очень рекомендую ее посмотреть.
Игра в ненавязчивой форме рассказывает и иллюстрирует стоит или не стоит доверять людям в долгосрочной перспективе. Единственное, что там придется относительно много читать.
А так это вариация на тему Дилеммы заключенных, которая очень подробно рассматривается в Теории игр.
notdotteam.github.io
Эволюция доверия
интерактивное руководство теории игр о том, зачем и как мы доверяем друг другу
🔥2
Оформление табличной части
Правила оформления табличной части на форме:
1. Заголовок колонки размещайте так же как содержимое.
Делайте это для реквизитов с типом Число, потому что по умолчанию для всех полей заголовок устанавливается слева, а цифровые значения отображаются справа.
2. Заголовок формы делайте не больше 1 строки.
В случае если заголовок многоэтажный, то переработайте строку и добавьте колонки с описанием. Иногда помогает объединение близких колонок по смыслу, например, Услуга и Содержание услуги. В этом случае укажите подсказку ввода для каждой колонки.
3. В конце табличной части добавьте пустую колонку с растягиванием.
Эта колонка сделает табличную часть компактной и не будет растягивать форму на широких мониторах. У колонки установите свойство ТолькоПросмотр и отключите отображение заголовка (ну или задайте заголовок из одного пробела).
4. Для табличной части с одной колонкой не отображайте шапку.
Такая табличная часть будет выглядеть как список элементов и ей достаточно сделать описание с помощью декорации.
5. Если колонок много, то зафиксируйте часть важных колонок слева.
При прокручивании списка по горизонтали они останутся и будут идентифицировать строку табличной части.
Еще некоторые пункты оформления описаны в стандарте для проектирования интерфейсов - https://its.1c.ru/db/v8std/content/717/hdoc
#Design
Правила оформления табличной части на форме:
1. Заголовок колонки размещайте так же как содержимое.
Делайте это для реквизитов с типом Число, потому что по умолчанию для всех полей заголовок устанавливается слева, а цифровые значения отображаются справа.
2. Заголовок формы делайте не больше 1 строки.
В случае если заголовок многоэтажный, то переработайте строку и добавьте колонки с описанием. Иногда помогает объединение близких колонок по смыслу, например, Услуга и Содержание услуги. В этом случае укажите подсказку ввода для каждой колонки.
3. В конце табличной части добавьте пустую колонку с растягиванием.
Эта колонка сделает табличную часть компактной и не будет растягивать форму на широких мониторах. У колонки установите свойство ТолькоПросмотр и отключите отображение заголовка (ну или задайте заголовок из одного пробела).
4. Для табличной части с одной колонкой не отображайте шапку.
Такая табличная часть будет выглядеть как список элементов и ей достаточно сделать описание с помощью декорации.
5. Если колонок много, то зафиксируйте часть важных колонок слева.
При прокручивании списка по горизонтали они останутся и будут идентифицировать строку табличной части.
Еще некоторые пункты оформления описаны в стандарте для проектирования интерфейсов - https://its.1c.ru/db/v8std/content/717/hdoc
#Design
👍8🔥2
⬆️⬆️⬆️
Для отображения заголовка в строке используйте событие ПриНачалеРедактирования с вот таким кодом:
А также не забудьте заполнить уже существующие строки ПриЧтенииНаСервере:
У этих полей установите Только просмотр, Шрифт текста - Наклонный и Цвет текста - RGB(128, 122, 89) и снимите флаг Отображать в шапке
Обратите внимание, что такие поля добавляются как реквизит табличной части на форме, а не объекте.
#Design
Для отображения заголовка в строке используйте событие ПриНачалеРедактирования с вот таким кодом:
Если НоваяСтрока Тогда
ТекущиеДанные = Элемент.ТекущиеДанные;
ТекущиеДанные.ЗаголовокСумма = "Руб";
ТекущиеДанные.ЗаголовокСуммаВВалюте = "USD";
КонецЕсли;
А также не забудьте заполнить уже существующие строки ПриЧтенииНаСервере:
Для Каждого Строка Из ТабличнаяЧасть Цикл
Строка.ЗаголовокСумма = "Руб";
Строка.ЗаголовокСуммаВВалюте = "USD";
КонецЦикла;
У этих полей установите Только просмотр, Шрифт текста - Наклонный и Цвет текста - RGB(128, 122, 89) и снимите флаг Отображать в шапке
Обратите внимание, что такие поля добавляются как реквизит табличной части на форме, а не объекте.
#Design
👍2🔥1
Методика постепенного перехода на EDT
Методика постепенного перехода на разработку в 1С:EDT - https://its.1c.ru/db/edtdoc#content:10219:hdoc
Суть методики: хранилище конфигурации выгружается в git с помощью Гитконвертера (или других инструментов) и разработчик может вести проект в EDT или Конфигураторе.
Этой методикой мы пользуемся с 2017 года - это уже 7 лет. Вот такой о-о-очень постепенный переход получается.
Причем первые года 3-4 мы даже не разрабатывали в EDT. Выгрузку в git использовали только для работы сторонних инструментов типа SonarQube и Crucible. Чуть позже начали разрабатывать свои проверки конфигурации, так как с файлами работать гораздо проще, чем с хранилищем. Об этом расскажу позже.
Затем потихоньку начали переключаться на работу в EDT, но шло это не просто. До сих пор остаются сложности даже у тех, кто полностью работает в этой среде. Причем мы не были пионерами в этой области, а сейчас держимся крепкими середнячками в сравнении с другими отделами фирмы «1С».
Лишь часть команд в нашем отделе работают в EDT, а остальные либо не хотят, либо сомневаются. Расстановка сил подчиняется Правилу 3-4-3, где из 10 человек трое За, трое Против, а четверо Не определились и ждут в какую сторону качнутся весы.
Но даже те, кто не спешит переходить с удовольствием используют возможности гита: сборку патчей, git blame, git merge, SonarQube и Crucible.
Наш семилетний путь по переходу на EDT не завершается. Мы планируем поддерживать и хранилище, и git. За это приходится платить администрированием Гитконвертера, но это уже понятная и привычная цена.
#git #EDT
Методика постепенного перехода на разработку в 1С:EDT - https://its.1c.ru/db/edtdoc#content:10219:hdoc
Суть методики: хранилище конфигурации выгружается в git с помощью Гитконвертера (или других инструментов) и разработчик может вести проект в EDT или Конфигураторе.
Этой методикой мы пользуемся с 2017 года - это уже 7 лет. Вот такой о-о-очень постепенный переход получается.
Причем первые года 3-4 мы даже не разрабатывали в EDT. Выгрузку в git использовали только для работы сторонних инструментов типа SonarQube и Crucible. Чуть позже начали разрабатывать свои проверки конфигурации, так как с файлами работать гораздо проще, чем с хранилищем. Об этом расскажу позже.
Затем потихоньку начали переключаться на работу в EDT, но шло это не просто. До сих пор остаются сложности даже у тех, кто полностью работает в этой среде. Причем мы не были пионерами в этой области, а сейчас держимся крепкими середнячками в сравнении с другими отделами фирмы «1С».
Лишь часть команд в нашем отделе работают в EDT, а остальные либо не хотят, либо сомневаются. Расстановка сил подчиняется Правилу 3-4-3, где из 10 человек трое За, трое Против, а четверо Не определились и ждут в какую сторону качнутся весы.
Но даже те, кто не спешит переходить с удовольствием используют возможности гита: сборку патчей, git blame, git merge, SonarQube и Crucible.
Наш семилетний путь по переходу на EDT не завершается. Мы планируем поддерживать и хранилище, и git. За это приходится платить администрированием Гитконвертера, но это уже понятная и привычная цена.
#git #EDT
its.1c.ru
1C:Enterprise Development Tools Руководство разработчика
👍6
git merge
Помимо смешных пятничных картинок хотел поделиться болью при использовании git merge в промышленной разработке.
У нас технические проекты тоже выгружаются в git, хотя разработку в них ведут в Конфигураторе. При этом релизы в основной ветке выходят примерно раз в две недели, но разработка задачи часто превышает этот период.
Поэтому проекты переодически актуализируются на новую версию конфигурации.
И вот здесь появляется проблема при использовании ГитКонвертера.
При сравнении и объединении с новой конфигурации поставщика должен происходить git merge. Но ГитКонвертер об этом ничего не знает и при выгрузке делает очередной коммит, в котором появятся все изменения из новой конфигурации поставщика. На картинке - это первая пунктирная линия. То есть должен быть git merge, но его нет.
Когда такой проект нужно отправить на код-ревью, с помощью Pull/Merge request, то разница между основной и веткой проекта получается большой. Это происходит из-за того, что родительским коммитом будет момент открытия, а не актуализации. То есть в изменениях будут все коммиты сделанные в проекте, в том числе и наш коммит с актуализацией проекта. И именно он привносит с собой много лишних изменений. На картинке - это вторая (красная) пунктирная линия.
В понедельник расскажу как мы боремся с этой проблемой.
#git #EDT
Помимо смешных пятничных картинок хотел поделиться болью при использовании git merge в промышленной разработке.
У нас технические проекты тоже выгружаются в git, хотя разработку в них ведут в Конфигураторе. При этом релизы в основной ветке выходят примерно раз в две недели, но разработка задачи часто превышает этот период.
Поэтому проекты переодически актуализируются на новую версию конфигурации.
И вот здесь появляется проблема при использовании ГитКонвертера.
При сравнении и объединении с новой конфигурации поставщика должен происходить git merge. Но ГитКонвертер об этом ничего не знает и при выгрузке делает очередной коммит, в котором появятся все изменения из новой конфигурации поставщика. На картинке - это первая пунктирная линия. То есть должен быть git merge, но его нет.
Когда такой проект нужно отправить на код-ревью, с помощью Pull/Merge request, то разница между основной и веткой проекта получается большой. Это происходит из-за того, что родительским коммитом будет момент открытия, а не актуализации. То есть в изменениях будут все коммиты сделанные в проекте, в том числе и наш коммит с актуализацией проекта. И именно он привносит с собой много лишних изменений. На картинке - это вторая (красная) пунктирная линия.
В понедельник расскажу как мы боремся с этой проблемой.
#git #EDT
👍9
Проблема git merge
Итак на картинке отображена наша исходная ситуация и проблема.
Коротко суть:
1. Есть основное хранилище, которое выгружается в git
2. Есть проектное хранилище, которое выгружается в git
3. Ветка для проектного хранилища создана с родительским коммитом от мастера
4. Актуализация с основным хранилищем происходит в Конфигураторе и в гите отображается как обычный коммит
Проблема:
При попытке сделать мердж или пулл реквест показываются лишние изменения
Причина проблемы:
Актуализация не имеет связи с основной веткой и поэтому для гита - это всего лишь очередной коммит.
Решение:
Пересоздать ветку от мастера после актуализации и настроить новую выгрузку в Гитконвертере.
Порядок действий:
Все решение выполняются на стороне Гитконвертера, в хранилище разработчика ничего не делаем.
1. В локальном репозитории переключитесь на ветку main на коммит, с которым происходила актуализация. В нашем случае это 3.0.154.
2. Создайте ветку от этого коммита. Мы называем такую ветку с постфиксом _2.
3. В Гитконвертере укажите эту ветку как целевую
4. В Гитконвертере укажите версию с которой выполняется конвертация та, которая соответствует 3.0.154
5. Готово! Поздравляю, Вы сэмулировали git rebase
#git #EDT
Итак на картинке отображена наша исходная ситуация и проблема.
Коротко суть:
1. Есть основное хранилище, которое выгружается в git
2. Есть проектное хранилище, которое выгружается в git
3. Ветка для проектного хранилища создана с родительским коммитом от мастера
4. Актуализация с основным хранилищем происходит в Конфигураторе и в гите отображается как обычный коммит
Проблема:
При попытке сделать мердж или пулл реквест показываются лишние изменения
Причина проблемы:
Актуализация не имеет связи с основной веткой и поэтому для гита - это всего лишь очередной коммит.
Решение:
Пересоздать ветку от мастера после актуализации и настроить новую выгрузку в Гитконвертере.
Порядок действий:
Все решение выполняются на стороне Гитконвертера, в хранилище разработчика ничего не делаем.
1. В локальном репозитории переключитесь на ветку main на коммит, с которым происходила актуализация. В нашем случае это 3.0.154.
2. Создайте ветку от этого коммита. Мы называем такую ветку с постфиксом _2.
3. В Гитконвертере укажите эту ветку как целевую
4. В Гитконвертере укажите версию с которой выполняется конвертация та, которая соответствует 3.0.154
5. Готово! Поздравляю, Вы сэмулировали git rebase
#git #EDT
🤯3👍2
Почему это произошло и что будет дальше?
В новой ветке с префиксом _2 первым будет коммит, который полностью соответствует типовой конфигурации из основного хранилища. Как будто никаких проектных изменений не было.
При этом в проектном хранилище все изменения остаются, то есть конфигурация будет Типовая конфигурация + все проектные изменения.
Следующий коммит, который будет выгружен с помощью Гитконвертера будет содержать помимо изменений этого коммита еще и все изменения, которые были сделаны раньше.
Поэтому мы в таких случаях, чтобы проверить, что все хорошо обычно просто делаем закладку в хранилище только с подъемом версии. Тогда будет четко видно, что помимо подъема версии еще приехали и все старые изменения.
В итоге получаем красивый merge или pull request в git.
Да, здесь требуются действия по администрированию в Гитконвертер, но это уже привычные и понятные действия.
#git #EDT
В новой ветке с префиксом _2 первым будет коммит, который полностью соответствует типовой конфигурации из основного хранилища. Как будто никаких проектных изменений не было.
При этом в проектном хранилище все изменения остаются, то есть конфигурация будет Типовая конфигурация + все проектные изменения.
Следующий коммит, который будет выгружен с помощью Гитконвертера будет содержать помимо изменений этого коммита еще и все изменения, которые были сделаны раньше.
Поэтому мы в таких случаях, чтобы проверить, что все хорошо обычно просто делаем закладку в хранилище только с подъемом версии. Тогда будет четко видно, что помимо подъема версии еще приехали и все старые изменения.
В итоге получаем красивый merge или pull request в git.
Да, здесь требуются действия по администрированию в Гитконвертер, но это уже привычные и понятные действия.
#git #EDT
Управление размером формы (ключ сохранение положения окна)
Бывают ситуации когда форма открывается не в том размере, который ожидаешь и появляются скроллы слева и справа. Чтобы восстановить положение нужно поработать мышкой или нажать волшебное сочетание клавиш - Alt + Shift + R (восстановить положение окна).
Это происходит из-за того, что форма по умолчанию запоминает свои размеры при закрытии и восстанавливает их при открытии. Но, например, в пошаговых помощниках конечное состояние формы сильно отличается от начального. На таких формах часто используют Страницы и на каждой странице набор реквизитов разный.
При создании формы размер подстраивается под видимые в текущий момент реквизиты. Если позже эти реквизиты изменятся, например, ПриОткрытии или ПриЗагрузкеПользовательскихДанных, то форма в каких-то случаях оставляет свой старый размер и реквизиты не помещаются. С простыми формами платформа справляется хорошо. А вот на сложных такой эффект проявляется и форма открывается либо меньше, либо больше чем нужно.
Чтобы этого избежать, следует управлять специальным свойством формы - КлючСохраненияПоложенияОкна. В разрезе этих ключей хранится размер и положение окна. При управлении формой следует менять этот реквизит.
Форма в этом случае будет восстанавливать (или устанавливать новый) размер под текущий набор реквизитов для этого ключа. Затем при открытии формы мы укажем нужный нам ключ и форма построится корректно.
КлючСохраненияПоложенияОкна - это свойство со строковым типом значения. Можно записать в него имя страницы, которая отображается. Если форма сложная, например, на странице будут отображаться или скрываться крупные блоки, то описание о них также стоит добавить в реквизит. После изменения этого свойства форма сама перестроится, никаких дополнительных методов вызывать не требуется.
Пример кода:
Обратить внимание следует на:
Форма.КлючСохраненияПоложенияОкна = СтрШаблон("СостояниеФормыШаг%1", Шаг);
#Design
Бывают ситуации когда форма открывается не в том размере, который ожидаешь и появляются скроллы слева и справа. Чтобы восстановить положение нужно поработать мышкой или нажать волшебное сочетание клавиш - Alt + Shift + R (восстановить положение окна).
Это происходит из-за того, что форма по умолчанию запоминает свои размеры при закрытии и восстанавливает их при открытии. Но, например, в пошаговых помощниках конечное состояние формы сильно отличается от начального. На таких формах часто используют Страницы и на каждой странице набор реквизитов разный.
При создании формы размер подстраивается под видимые в текущий момент реквизиты. Если позже эти реквизиты изменятся, например, ПриОткрытии или ПриЗагрузкеПользовательскихДанных, то форма в каких-то случаях оставляет свой старый размер и реквизиты не помещаются. С простыми формами платформа справляется хорошо. А вот на сложных такой эффект проявляется и форма открывается либо меньше, либо больше чем нужно.
Чтобы этого избежать, следует управлять специальным свойством формы - КлючСохраненияПоложенияОкна. В разрезе этих ключей хранится размер и положение окна. При управлении формой следует менять этот реквизит.
Форма в этом случае будет восстанавливать (или устанавливать новый) размер под текущий набор реквизитов для этого ключа. Затем при открытии формы мы укажем нужный нам ключ и форма построится корректно.
КлючСохраненияПоложенияОкна - это свойство со строковым типом значения. Можно записать в него имя страницы, которая отображается. Если форма сложная, например, на странице будут отображаться или скрываться крупные блоки, то описание о них также стоит добавить в реквизит. После изменения этого свойства форма сама перестроится, никаких дополнительных методов вызывать не требуется.
Пример кода:
&НаКлиентеНаСервереБезКонтекста
Процедура УправлениеФормой(Форма, Шаг)
Элементы = Форма.Элементы;
Если Шаг = 1 Тогда
Элементы.ГруппаСтраницы.ТекущаяСтраница = Элементы.СтраницаВход;
Элементы.СтраницаВход.Видимость = Истина;
Элементы.СтраницаРеквизиты.Видимость = Ложь;
Элементы.СтраницаУспешно.Видимость = Ложь;
ИначеЕсли Шаг = 2 Тогда
Элементы.ГруппаСтраницы.ТекущаяСтраница = Элементы.СтраницаРеквизиты;
Элементы.СтраницаВход.Видимость = Ложь;
Элементы.СтраницаРеквизиты.Видимость = Истина;
Элементы.СтраницаУспешно.Видимость = Ложь;
Иначе
Элементы.ГруппаСтраницы.ТекущаяСтраница = Элементы.СтраницаУспешно;
Элементы.СтраницаВход.Видимость = Ложь;
Элементы.СтраницаРеквизиты.Видимость = Ложь;
Элементы.СтраницаУспешно.Видимость = Истина;
КонецЕсли;
Форма.КлючСохраненияПоложенияОкна = СтрШаблон("СостояниеФормыШаг%1", Шаг);
КонецПроцедуры
Обратить внимание следует на:
#Design
👍12🔥2
Сценарии_отображения_кнопки_без_фигуры.mp4
13.1 MB
Когда нужны кнопки без отображения фигуры?
У кнопки на форме есть свойство "Отображение фигуры" со значениями "Всегда", "При активности" и "Нет". Пожалуйста, не путайте это свойство с просто "Отображение", которое управляет выводом картинки.
По умолчанию кнопка всегда отображает вокруг себя контур. Это привычное нам отображение кнопки по умолчанию. Но если установить "При активности" или "Нет", то контур кнопки скрывается, делая ее менее заметной и выразительной.
Когда это может быть полезно?
Сценарий 1:
Нам нужно вести пользователя по нашему сценарий вперед в пошаговых помощниках. Кнопка "Вперед" делается яркой и заметной, а кнопка "Назад" наоборот максимально скрывается. Показываем ее только при активизации. У пользователя остается возможность найти сценарий вернуться назад, но это скорее редкий сценарий.
Сценарий 2:
Нам нужно отговорить пользователя от выполнения действия. В этом случае в работу идет все - от угроз "Не рекомендуется" до скрытия кнопки. То есть мы всячески показываем пользователю, что этот сценарий возможен, но совсем не желателен.
Сценарий 3:
Нам нужна кнопка, которая будет открывать служебные возможности формы. Например, разработчику полезно видеть какие-то скрытые или служебные реквизиты объекта. В этом случае рекомендуется спрятать кнопку от пользователя и установить Отображение фигуры Нет. При нажатии на кнопку управляем видимостью служебных реквизитов.
#Design
У кнопки на форме есть свойство "Отображение фигуры" со значениями "Всегда", "При активности" и "Нет". Пожалуйста, не путайте это свойство с просто "Отображение", которое управляет выводом картинки.
По умолчанию кнопка всегда отображает вокруг себя контур. Это привычное нам отображение кнопки по умолчанию. Но если установить "При активности" или "Нет", то контур кнопки скрывается, делая ее менее заметной и выразительной.
Когда это может быть полезно?
Сценарий 1:
Нам нужно вести пользователя по нашему сценарий вперед в пошаговых помощниках. Кнопка "Вперед" делается яркой и заметной, а кнопка "Назад" наоборот максимально скрывается. Показываем ее только при активизации. У пользователя остается возможность найти сценарий вернуться назад, но это скорее редкий сценарий.
Сценарий 2:
Нам нужно отговорить пользователя от выполнения действия. В этом случае в работу идет все - от угроз "Не рекомендуется" до скрытия кнопки. То есть мы всячески показываем пользователю, что этот сценарий возможен, но совсем не желателен.
Сценарий 3:
Нам нужна кнопка, которая будет открывать служебные возможности формы. Например, разработчику полезно видеть какие-то скрытые или служебные реквизиты объекта. В этом случае рекомендуется спрятать кнопку от пользователя и установить Отображение фигуры Нет. При нажатии на кнопку управляем видимостью служебных реквизитов.
#Design
👍12🔥3