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

[titov]

S.Kuskov - спасибо за верные пояснения - все именно так.
Немного добавлю.
Форма может и не иметь источник данных (контролы table,list), тогда перечень методов перехвата резко возрастает.
В целом все методы, которые мы хотим перехватить вызывают метод перерисовки формы - вот она ключевая точка, но попасть туда можно только через дисплей метод (или по таймеру крутить свой метод - это второе более плохое решение, так как есть время, когда пользователь может успеть нажать кнопку). Итого - приходиться вот так "троянски" влезать туда, куда не пустили.

Насчет сообщений и фэншуйности - почему то поля с запретом редактирования сразу запрещают работу, а не сообщают потом, что "было оказываеться нельзя". Это даже не обсуждается.

По кнопкам же вопрос возникает. Потому, что большинство отдельных кнопок имеют такое поведение и считается, что так верно. Не так! Пример из самой Аксапты: пользователь не сможет разнести отгруженный заказ, так как кнопки не активны - там они активируются при нажатии на MenuButton - логика блокировки присутствует. Разница в чем? При отдельной кнопке просто возникает технический момент поиска метода, подобного MenuButton.clicked(), но не на конкретное нажатие, а на действия на форме, изменяющих блокировку. Набор действий (методов) в каждом случае разный, разнообразный и при этом плохо! контролируется программистом - вот причина отказа от блокирования - лучше сообщение, чем непонятные мерцания. А по логике надо сделать "аналогично" форме заказов.

[Vadik]

Цитата:

Пользователю приятно, когда система ведет себя как хочет S.Kuskov.
У него ощущение фэншуйности происходящего и заботы со стороны системы возникает. А ругательные окошечки никто не любит

Давайте сразу расставим точки на И
Я рассуждаю с точки зрения разработчика на стороне партнера или вендора, от которого требуется а) относительно быстро (читай - недорого) и б) надежно (лучше - гарантированно) решить простую задачу. Быстро - потому что реально сложных и нужных "уже вчера" задач и так хватает. Недорого - потому что платить за мои экзерсисы клиент как правило не хочет и постоянно норовит продемонстрировать, что понимает, сколько стоит "добавить поле в таблицу" и "добавить кнопку на форму" (пусть даже переделывать за ним дороже чем сделать самому).
С точки зрения фэншуйности я вообще могу быть апологетом дизайна пользовательских интерфейсов от Джобса & Co, но работаю в том, что выдали и не жужжу

Цитата:

Насчет сообщений и фэншуйности - почему то поля с запретом редактирования сразу запрещают работу, а не сообщают потом, что "было оказываеться нельзя". Это даже не обсуждается

Потому что это - фича ядра. Один раз написано, используется везде. За это уже "уплочено"

Цитата:

Пример из самой Аксапты: пользователь не сможет разнести отгруженный заказ, так как кнопки не активны - там они активируются при нажатии на MenuButton - логика блокировки присутствует..
..
А по логике надо сделать "аналогично" форме заказов

Потому что "простота" этих проверок и блокировок обернута некислым количеством классов и объемом кода на этапе дизайна. Я это знаю и при разработке с нуля чего-то с непонятными перспективами тиражирования точно "аналогично форме заказов" делать не буду, потому что долго и дорого, а клиент "знает" (см. выше).
И напоследок относительно "надежно". Мне хотелось бы, чтобы эта функциональность работала бы откуда бы ее ни вызывали и не ломалась от того, что кто-то что-то на форме добавит, переместит или перекроет (или забудет перекрыть). Так же хотелось бы избежать ненужного неконтролируемого трафика (иногда - платного) между AOS-ом и клиентом, равно как и между клиентом и терминальным сервером (чего в случае перекрытого display метода не избежать). В общем, работая на партнере хочется "быстро, недорого, надежно".
Я понимаю, при работе "на клиенте" критерии могут меняться на, например, "чтобы МарьИванне стало хорошо". Это нормально, если МарьИванна платит. Главное, чтобы понимала - сколько и за что

[gl00mie]

Цитата:

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

Мне хотелось бы, чтобы эта функциональность работала бы откуда бы ее ни вызывали и не ломалась от того, что кто-то что-то на форме добавит, переместит или перекроет (или забудет перекрыть). Так же хотелось бы избежать ненужного неконтролируемого трафика (иногда - платного) между AOS-ом и клиентом, равно как и между клиентом и терминальным сервером (чего в случае перекрытого display метода не избежать).

К слову, да, тут как-то упустили то, что запрет выполнения какой-то функции при отсутствии записей должен быть в первую очередь зашит в бизнес-логику, а уже во вторую или десятую - в презентационную. Потому что если у вас возможность выполнения какого-то действия будет зависеть от доступности кнопки, то мне вас искренне жаль: завтра вместо форм в толстом клиенте начнется использование business connector'а, которому пофиг на все эти кнопки и который в теории может дергать ваш код с совершенно произвольными параметрами; послезавтра начнется использование EP, и какой-нить умник с помощью локальной прокси научится подсовывать своему браузеру странички, где кнопки ни разу не заблокированы... С этой точки зрения проверка записи в main() или validate() вызываемого класса (при том что запись выбирается по ключу, а не берется табличный буфер с формы - во избежание срабатывания dynalink в самый неподходящий момент), может, не столь привлекательна для конечного пользователя, но зато наиболее близка к уровню бизнес-логики, которому должно быть безразлично, откуда он дергается: с формы ли, со странички ли портала или из другого приложения посредством business connector'а.

[sukhanchik]

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

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

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

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

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

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

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