Создаем Win Form в C/SIDE

Р’ данной статье РЅР° примере работы СЃ пространством имен System.Windows.Forms РїСЂСЏРјРѕ РІ C/SIDE реализуем формочку, напоминающую форму статистики РІ заказах продажи, РїРѕРєСѓРїРєРё, учтенных счетах Рё С‚.Рґ. Рё С‚.Рї…

РќР° самом деле, РєРѕРіРґР° этот пример только реализовывался, хотелось сделать действительно полноценную форму статистики СЃ возможностью изменять СЃСѓРјРјСѓ СЃРєРёРґРєРё РїРѕ счету Рё СЃСѓРјРјСѓ без НДС РїСЂСЏРјРѕ РІ полях Win Form. Как следствие, могли Р±С‹ динамически расчитываться остальные поля: НДС,В СЃСѓРјРјР° СЃ учетом НДС, прибыль Рё РґСЂСѓРіРёРµ…

pic1.png

В 

Однако, сделать этого РЅРµ удалось Рё РЅР° выходе получилась статическая форма.В Рћ причинах, РѕС‚ нас РЅРµ зависящих,В - РІ самом конце статьи…

Р?так… Для того, чтобы создать Win Form, нам понадобится:

  • 1 CodeunitВ (РѕСЃРЅРѕРІРЅРѕР№ объект, РІ котором проектируем РІРёРЅ форму);
  • 1 Page (небольшая кастомизация 42-РіРѕ Пейджа РІ РІРёРґРµ создания РѕРґРЅРѕРіРѕ единственного Action’a);
  • 1 дополнительный Action РІ Page;
  • пара функций Рё РјРЅРѕРіРѕ-РјРЅРѕРіРѕ DotNet переменных, определенных РІ кодэюните. :)

Первое, что мы сделаем - скопируем функционал расчета статистической информации из формы/пейджа 402, и вставим его в виде функции CalcStatistics в наш кодэюнит. Функция CalcStatistics практически полностью повторяет код OnAfterGetRecord() триггера на 402 форме. Будем вызывать эту функцию из нового Action, размещенного на 42 Page Sales Order:

pic2.png

Р’ Action’Рµ, РІРѕ-первых, вызываем стандартную функцию CalcInvDiscForHeader 36-Р№ таблицы, Р° далее - вызываем функцию CalcStatistics РІ нашем кодэюните:

pic3.png

На этом работа с Page закончена, дальше будем иметь дело только с кодэюнитом (CalcStatToOpenDotNetForm).

В функцию CalcStatistics кодэюнита передаем по ссылке текущий Rec, расчитывая всю необходимую статистическую информацию о заказе продажи:

4.png

На предыдущей картинке показан фрагмент функции CalcStatistics, которая, впоследствии, делает последовательный вызов 3 функций:

  • InitializeComponents (инициализация DotNet - переменных, вызов конструкторов);
  • FillDataGridView (заполнение РіСЂРёРґР° данными);
  • OpenStatisticsForm (непосредственно, открытие Win Form).

Чтобы не было сложностей в восприятии, сразу приведу итоговый результат, которого необходимо добиться:

5.png

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

6.png

Р’Рѕ-первых, большое количество объявленных переменных объясняется потребностью РІ большом количестве контролов (лэйблы, текстбоксы, РіСЂРёРґС‹) РЅР° форме. Если РІС‹ сделаете макет РїРѕРґРѕР±РЅРѕР№ формы РІ Студии, результат будет таким же. Только РІ Студии РІСЃРµ гораздо быстрее…

Р’Рѕ-вторых, каждую ДотНет-переменную надо объявлять как RunOnClient. РќРµ пробовал работать СЃ .NET Interop РІ случае, РєРѕРіРґР° РєРѕРґ исполняется РЅР° Application сервере. Р’ документации Рє R2 СЏРІРЅРѕ Рѕ данной возможности ничего РЅРµ написано…

Р?так, РІ функции InitializeComponents РїСЂРѕРёСЃС…РѕРґРёС‚ вызов процедуры CallConstructors(), производящей создание экземпляров соответствующих DotNet-переменных:

7.png

8.png

Все элементарно: как в Студии.

Далее, РІ функции InitializeComponents определяем основные свойства всех необходимых контролов, связываем Табы СЃ ТабКонтролом, добавляем РІ РіСЂРёРґ колонки, располагаем лейблы Рё текстбоксы…

9.png

10.png

После того, как макет формы готов необходимые лэйблы, текстбоксы и табы размещены на форме, наполняем данными грид, в котором будет храниться информация по строке НДС:

11.png

Р?, наконец, открытие формы производится вызовом функции ShowDialog формы: MyForm.ShowDialog.

Если говорить о трудозатратах, то, безусловно, в данном конкретном случае .NET Interop на порядок уступает разработке адд инов: интеллисенса нет, нормальной среды разработки нет (C/SIDE), ООП программирования как такового, естественно нет - все на C/AL.

Р?Р· гигантских недостатков - отсутствие возможности использовать событийное программирование: РєРЅРѕРїРѕРє РЅРµ сделать, контролов “живых” тоже РЅРµ создать…

Несмотря на то, что хэндлеры в C/SIDE создать можно, перехватывать нечего: события не поддерживаются и перехватить то или иное действие невозможно в принципе. Здесь проблема очевидна: C/SIDE в принципе не может поддерживать таких возможностей и вряд ли будет их поддерживать в будущем.

Но плюсов, конечно же, больше: прежде всего интеграционные возможности. Найдя минусы там, где они априори должны быть из-за слабого языка и среды разработки, уже сейчас очевидно - .NET Interop с легкостью придет на смену динозаврам вроде Датапортов и XML-портов. Учитывая выход CRM-коннектора для NAV, возможности интеграции NAV и CRM возрастают еще более значительно с наличием .NET Interoperability.

Также возможность работы с веб-сервисами напрямую из C/SIDE (предварительно создав прокси-класс для вызова методов сервиса, и создании собственной сборки) - выглядит весьма заманчивой.

Метки: ,



Оставьте свой отзыв!