Заголовок у флажка справа
По умолчанию платформа ставит заголовок у флажка слева, как у обычных полей. Хотя общепринятый стандарт, что заголовок у такого элемент устанавливается справа.
Поэтому при добавлении флажка на форму стоит вручную устанавливать заголовок справа, чтобы элемент выглядел узнаваемо для пользователя.
Полезные советы по Флажкам можно еще подсмотреть у КонтурГайды - https://guides.kontur.ru/components/selection-elements/checkbox/
#Design
По умолчанию платформа ставит заголовок у флажка слева, как у обычных полей. Хотя общепринятый стандарт, что заголовок у такого элемент устанавливается справа.
Поэтому при добавлении флажка на форму стоит вручную устанавливать заголовок справа, чтобы элемент выглядел узнаваемо для пользователя.
Полезные советы по Флажкам можно еще подсмотреть у КонтурГайды - https://guides.kontur.ru/components/selection-elements/checkbox/
#Design
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