Подсказка пользователю

При нажатии на кнопку Справка в диалоговом окне Гедымин пытается открыть страницу на Gedemin Wiki. Теперь добавилась возможность написать подсказку для пользователя и хранить ее в самой базе данных, а не в интернете. Текст справки можно привязать к классу окна или бизнес-объекта. Рассмотрим процесс на примере справки для класса Физическое лицо:

1. Откроем диалоговое окно. Кнопка Меню и далее -- Свойства... Смотрим имя класса и подтип -- TgdcContact (у данного класса подтипа нет, но, если бы он был, мы бы присоединили его к имени класса).
2. Идем Исследователь-Сервис-Файлы
3. Находим папку _Справка-_Классы-_Пользователь
4. Создаем в ней новый файл. Имя файла формируем как имя класса + подтип (без пробелов и подчеркиваний между ними, просто слияние двух строк). Расширение файла .TXT. Сохраняем.
5. В гриде дважды щелкаем по созданному файлу. Откроется программа для его редактирования. Если у вас открывается MS Word, что, согласитесь, несколько избыточно для простого текста, то в файле gedemin.ini, в секции [EXTERNAL EDITOR], можно указать любой другой редактор.
6. Вводим текст справки, сохраняем файл и закрываем внешний редактор.
7. Проверяем: в диалоговом окне Физ лица появилась вкладка Справка с текстом подсказки. Так же, при нажатии на кнопку Справка теперь откроется не браузер, а текстовый файл во внешнем редакторе.

Для чего нам две папки: _Система и _Пользователь? В первой будет находиться общая, стандартная справочная информация, поставляемая вместе с программой. Во второй -- справка, созданная настройщиком на конкретном предприятии. Если бы не было разделения на две папки, то очередное обновление пакета прикладных решений затерло бы сделанные изменения.

Порядок поиска справки идет от частного к общему:

1. По классу и подтипу формы в папке _Пользователь.
2. По классу и подтипу бизнес-объекта в папке _Пользователь.
3. По классу и подтипу формы в папке _Система.
4. По классу и подтипу бизнес-объекта в папке _Система.
5. По наименованию формы на сайте Gedemin Wiki.

По ключевому слову Гедымин rabota.by находит резюме 206 соискателей. Относительно недавно их было 4-5...

Вакансия специалиста по сопровождению ПО

Тяжелая, но интересная работа по внедрению и сопровождению экономического программного обеспечения. Главное требование к кандидату -- желание непрерывно развиваться и расти в профессиональном плане. Приветствуется наличие базовых знаний бухучета, экономики предприятия, основ программирования и реляционных баз данных.

Должностные обязанности:

• Установка программного обеспечения в сети предприятия.
• Организация и сопровождение процесса запуска в эксплуатацию и эксплуатации ПО.
• Ответы на вопросы пользователей.
• Работа с клиентом по доработке ПО (анализ, формулирование технического задания, тестирование).
• Доработка ПО под нужды конкретного заказчика, создание выходных форм (отчетов).

Общаясь с персоналом заказчика, вникая в суть бизнес-процессов многочисленных клиентов, специалист получает уникальную возможность на практике досконально освоить применение бухгалтерского учета в различных отраслях. Многие наши сотрудники по истечении двух-трех лет фактически достигают уровня аудитора.

Установка и поддержка программного обеспечения на компьютерах и в сетях различной конфигурации позволяет приобрести навыки системного администратора в части настройки операционной системы и сетевого оборудования.

Самостоятельная доработка программного обеспечения, начиная с простейших корректировок печатных форм и вплоть до создания законченных функциональных модулей, позволит освоить объектно-ориентированное и логическое программирование, получить квалификацию системного аналитика и архитектора реляционных баз данных.

Работа связана с разъездами по г. Минску и Беларуси. Командировки в основном на один день, изредка -- двух-трех дневные.

Начальное обучение основам технологической платформы Гедымин проводится за счет компании на постоянно действующих курсах или в индивидуальном порядке.

Дружный коллектив, ароматный кофе, крепкий чай, выделенный ноутбук для работы, походы на байдарках летом и настольный теннис зимой ждут вас.

Резюме направляйте на адрес job@gsbelarus.com

Фиксированные РУИДы для общих объектов

Объекты Гедымина за пределами файла базы данных идентифицируются РУИДом. РУИД присваивается при создании объекта под учетной записью Администратора или в момент записи в файл и состоит из ИД объекта и ИД базы. При перемещении объекта между базами его ИД изменится, а РУИД сохранится.

Для неотъемлемых частей платформы зарезервирован диапазон идентификаторов [0..147000000). ИД таких объектов одинаков во всех базах. При сериализации они получают РУИДы стандартного вида, где ИД базы равен 17.

Если для бизнес-класса существует натуральный потенциальный первичный ключ, то разработчик перекрывает функцию CheckTheSameStatement и возвращает запрос для отыскания объекта в БД. Для объекта, найденного в процессе загрузки из файла по потенциальному ключу, РУИД в базе данных заменяется на РУИД из файла.

Исторически так сложилось, что не всем объектам ядра платформы был присвоен фиксированный идентификатор. Кроме этого, фиксированные идентификаторы или РУИДы напрашиваются для общих элементов справочников: административно-территориальных единиц, валют, единиц измерения и т.п. Проблема была не столь заметна, пока разработка прикладных решений велась на единой базе данных. С переходом на пространства имен каждый разработчик может иметь автономную базу данных. Если не унифицировать РУИДы для общих объектов, то при каждой загрузке ПИ со сторонней базы данных они будут перезаписываться новыми значениями.

Какой выбор мы имеем на сегодняшний день:

1. Выявлять общие объекты и присваивать им фиксированные ИД. С помощью процедуры апгрейда структуры БД подменять ИД и РУИДы на существующих базах.
2. Выявлять общие объекты и включать их в ПИ нижнего уровня, от которых будут зависеть все прикладные решения. Для синхронизации РУИДов распространить ПИ с общими объектами на все базы разработчиков.
3. Реализовать механизм поддержки потенциальных ключей. Не формировать и не использовать РУИДы для объектов, которые могут быть идентифицированы через натуральный ключ.
4. Для объектов, идентифицируемых через натуральный ключ, вычислять РУИД с помощью хэш-функции.

Двум последним решениям с использованием натуральных ключей присущи все минусы натуральных ключей. Отклоняем.

Остается модифай или общие ПИ нижнего уровня. Первый вариант удобен тем, что даже у ленивого разработчика РУИДы обновятся после смены экзешника. Второй -- больше соответствует идеологии ПИ и совместной разработки ПО на платформе Гедымин. Не исключен и коомбинированный вариант.