Заблокировать menuItemButton если запись не выбрана

[sukhanchik]

У запрета доступности кнопки при всей скажем так неудобности (=дороговизне) реализации есть 2 существенных плюса:
- "МарьИванне станет хорошо", т.е. условно "непродвинутому" пользователю будет понятнее. Про это уже говорил Vadik. Хоть платит и не МарьИванна - но плательщику важно, чтобы смена системы не привела к необходимости увеличить расходы на содержание персонала (ну или он стремится минимизировать сие увеличение).
- будет облегчение на этапе обучения как новому функционалу так и новых сотрудников.

Соответственно - клиент, условно переплачивая за излишнее программирование, чтобы программист потратил лишних полчаса (а при грамотном подходе - больше и не требуется) - экономит впоследствии на обучении (МарьИванна быстрее обучится и новая НатальФедоровна тоже быстрее поймет) и на текущей работе (лишняя защита "от дурака" для низкоквалифицированных = дешевых пользователей). При этом (важно), что экономится двойное (пусть и неравное) время - как обучающего, так и обучаемого. Плюс - снижается риск сложности освоения системы (=экономия на времени=деньгах) в случае, если "все те кто знали это - давно уже ушли". Кстати - это касается как пользователей, так и программистов / администраторов / службы сопровождения / нового партнера.

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

Единственное - что - в этом случае - нужно "не перегнуть палку". Т.е. не нужно кидаться сломя голову все переделывать на "недоступную кнопку", равно как и переделывать на "ошибку после нажатия кнопки". Причем "неприкосновенность ядра" актуальна только для специалистов - которым привычнее (=быстрее разобраться) штатное поведение всех кнопок. В случае же каких новых кнопок - специалисту и пользователю одинаково нужно изучать их поведение.

Со своей стороны получилось так - что мне (как программисту) потребовалось изучить некоторое приложение (изрядно уже до меня модифицированное) в АХ, которое было построено по принципу - "недоступная кнопка" и "максимальное заполнение полей по умолчанию при условии единственного варианта заполнения". Я в нем разобрался достаточно быстро только потому, что у меня не было возможности "свернуть с истинного пути".
Вывод: Было сэкономлено мое время и время моего обучающего, а это деньги.

К сожалению - нельзя точно оценить в деньгах и сравнить экономию на обучение и дополнительное программирование по запрету кнопки.

Однако - доля смысла в приведении интерфейса под стиль "Джобса и Ко" (а точнее - под стиль, в котором легче проводится обучение) есть.