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

[S.Kuskov]

Цитата:

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

Потому что проверка наличия буфера и его валидности традиционно выполняется в main или в конструкторе класса, вызываемого menuItemButton-ом

Про проверки в коде согласен. Но

Цитата:

Сообщение от S.Kuskov

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

Цитата:

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

Есть метод, который вызывается всегда - display - можно этим воспользоваться

titov, спасибо. Оно работает!

Цитата:

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

Потому что проверка наличия буфера и его валидности традиционно выполняется в main или в конструкторе класса, вызываемого menuItemButton-ом

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

Лишние контролы как-то уж совсем круто.
Я в подобных случаях запрещал отдельно лежащую на форме кнопку в executeQuery датасорса, а в active разрешал.
Если пользователь наложил такой фильтр что нет записей, то executeQuery сработает, а active нет.

[S.Kuskov]

Цитата:

Сообщение от Кирилл

Лишние контролы как-то уж совсем круто.
Я в подобных случаях запрещал кнопку в executeQuery датасорса, а в active разрешал.
Если пользователь наложил такой фильтр что нет записей, то executeQuery сработает, а active нет.

Всё верно, но для полного успокоения нужно ещё в delete проверить не последнюю ли строчку удалили, после этого ведь тоже грид пустеет, а также ещё возможно в linkActive (не помню вызывается ли executeQuery при смене родительского источника). В общем не просто всё это. Вариант от titov'а мне больше понравился

Цитата:

Сообщение от S.Kuskov

нужно ловить манипуляции с источником данных, прекрыть и executeQuery() и delete(), но это не спортивно . Вот было бы прекрасно если бы такое поведение кнопки регулировалось каким-нибудь стандартным свойством. Мне кажется в этом будет смысл. На мой взгляд, текущее положение вещей создаёт какую-никакую но всё-таки потенциальная угрозу ошибки, вдруг в каком-нибудь месте системы нет соответствующей проверки в коде.

А этот контрол нужно по всем закладкам рассовывать?
Если пользователь наложит фильтр, возвращающий пустой набор данных, находясь на закладке, где нет этого контрола, то display-методу по идее не будет причины быть вызванным?

[S.Kuskov]

Цитата:

Сообщение от Кирилл

А этот контрол нужно по всем закладкам рассовывать?
Если пользователь наложит фильтр, возвращающий пустой набор данных, находясь на закладке, где нет этого контрола, то display-методу по идее не будет причины быть вызванным?

Вспомогательный display-контрол лежит вне вкладок, в корне дизайна. Он не связан с конкретным исочником и реагирует на любое изменение формы

[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]

Заодно сразу предвосхищу любителей фразы "А вот потом у вас все это вылезет при апгрейде на следующую версию".
Любая следующая версия (если в ней только конечно не пару запятых поставлено) предполагает фактически перевнедрение. Нет смысла переходить (условно) с 4-ки на 2009-ю, сменив при этом только exe-шник (ну конечно - если нет чисто технологических ограничений, которые снимаются новым exe-шником). Нужно заново переосмыслять процессы, удалять лишнюю функциональность, которая уже появилась в стандарте и т.д. А учитывая как сейчас меняются версии - можно говорить смело - апгрейда не будет. Будет абсолютно новая версия с переобучением пользователей (что тоже деньги).

Т.е. вывод: нет смысла "закладываться на апгрейд", если все равно потом все переосмысливать (=переделывать) с нуля (ну или - скажем так - экономически необоснованно закладываться).

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