Вопросы про RunBase

[lev]

Цитата:

Сообщение от db

в замену одного числа в макросе/методе который это 255 определяет. Да и вероятность расширения енумов мала микроскопически

Дополнение. Имелся ввиду не макрос метод в каждом обработчике, а нечто одно на всю аксапту. Макрос который живет в AOT, статический метод, ф-ия в Global

Все равно мне кажется сомнительное решение. Использование констант в X++ не приветствуется.
На мой взгляд лучше подумать при создании enuma как он будет использоваться, в каких случаях по нему будут выполняться сравнительные действия, и уже продумать использовать в нем нулевой элемент, или нет.

Итого: на мой взгляд в Enum-параметрах лучше не использовать нулевой элемент.

[db]

Цитата:

Сообщение от lev

Использование констант в X++ не приветствуется.

Именно поэтому их и заворачивают в макросы/стат методы

Для тех кому 255 неприемлемо по религиозным соображениям - кошерная эмуляция NULL с помощью двух parm- методов

MySuperEnum parmMySuperEnum()
boolean parmUseMySuperEnum()

[lev]

Цитата:

Сообщение от db

Именно поэтому их и заворачивают в макросы/стат методы

Для тех кому 255 неприемлемо по религиозным соображениям - кошерная эмуляция NULL с помощью двух parm- методов

MySuperEnum parmMySuperEnum()
boolean parmUseMySuperEnum()

Все проще Используйте везде в своем коде элемент None (0) как пустой, и тогда не придется писать глобальные методы с цифирками, или эмуляторы NULL

P.S. наше обсуждение ушло немного в сторону от исходной темы, приношу свои извинения топикстартеру

[db]

Цитата:

Сообщение от lev

Все проще Используйте везде в своем коде элемент None (0) как пустой, и тогда не придется писать глобальные методы с цифирками, или эмуляторы NULL

P.S. наше обсуждение ушло немного в сторону от исходной темы, приношу свои извинения топикстартеру

Да я бы рад, только что делать с каким нибудь, например, SalesType?

[lev]

Цитата:

Сообщение от db

Да я бы рад, только что делать с каким нибудь, например, SalesType?

ждал этого вопроса
если вам нужно выполнить обработку по заказам, и эта обработка должна быть параметризирована, то я бы для обработки создал свой Enum, с помощью которого бы определялось, выполнять обработку по заказам с SalesType = Journal или Sales.
Конечно это более трудозатратно чем просто передать в параметре SalesType, но в случае с уже существующими (системными) enum-ами, где нулевой элемент несет смысловую нагрузку, это гарантирует что все проверки по параметру отработаю корректно, и все необходимые заказы будут обработаны. Вот как то так

[db]

Цитата:

Сообщение от lev

ждал этого вопроса
если вам нужно выполнить обработку по заказам, и эта обработка должна быть параметризирована, то я бы для обработки создал свой Enum, с помощью которого бы определялось, выполнять обработку по заказам с SalesType = Journal или Sales.
Конечно это более трудозатратно чем просто передать в параметре SalesType, но в случае с уже существующими (системными) enum-ами, где нулевой элемент несет смысловую нагрузку, это гарантирует что все проверки по параметру отработаю корректно, и все необходимые заказы будут обработаны. Вот как то так

Ну это и есть "вид сбоку" для кошерного варианта с двумя parm-методами. Доп parm метод или новый енум, объединяющий в себе и галку и собственно тип. Лично я все таки предпочту не засорять AOT одноразовыми енумами

Идеального универсального решения для этой задачи нет. Выбираем на свой вкус и пользуемся при необходимости. Вкусы можно менять в зависимости от ситуации

Предлагаю на этом закончить