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

Цитата:

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

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

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

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

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

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

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

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

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

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

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

[sukhanchik]

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

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

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

[S.Kuskov]

Проверки в коде - это хорошо, это правильно, без них не обойтись, это даже не обсуждается. Ещё раз процетирую себя

Цитата:

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

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

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

Вопрос, почему в системе этого не предусмотрено? Много ли смысла в передаче пустого курсор из формы (нормальной аксаптовской формы) в код? Т.е. создавая menuItemButton и связывая его с конкретным источником данных, разве мы не подразумеваем использование этой кнопки только в контексте какой-то (одной или нескольких в случае мультиселекта) записи?

P.S.: Cам я несколько раз использовал возможность передачи пустого курсора в различных целях. Например, для получения ссылки на временую таблицу (в результате обработки в неё добавлялись записи), либо для доступа через полученный курсор к связанному с ним источнику данных (в этом случае вообще было не важно есть ли в курсоре данные или нет). Но не думаю что, использовать для этого args.record() оправдано, в таких случаях вполне можно обойтись и без него. И честно говоря в первый раз был удивлён когда данная комбинация сработала. Не было это... интуитивно понятным что ли.

[sukhanchik]

Цитата:

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

Вопрос, почему в системе этого не предусмотрено? Много ли смысла в передаче пустого курсор из формы (нормальной аксаптовской формы) в код? Т.е. создавая menuItemButton и связывая его с конкретным источником данных, разве мы не подразумеваем использование этой кнопки только в контексте какой-то (одной или нескольких в случае мультиселекта) записи?

Ядро ж как и приложение - писали люди. Наверняка воспользовались принципом 80% / 20%. Или что-то еще сыграло - сие науке неизвестно. Но МС, купив АХ явно не стал себе ставить задачу по устранению данного неудобства в качестве приоритетной

[gl00mie]

Цитата:

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

Много ли смысла в передаче пустого курсор из формы (нормальной аксаптовской формы) в код? Т.е. создавая menuItemButton и связывая его с конкретным источником данных, разве мы не подразумеваем использование этой кнопки только в контексте какой-то (одной или нескольких в случае мультиселекта) записи?

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