Серые кнопки. Изначально неверное решение.

[S.Kuskov]

В каком-то смысле текстовый терминал с командной строкой - это идеальный вариант для реализации диалога между пользователем и системой. Пользователь волен в любой момент набрать абсолютно любую команду (нажать на любую кнопку), и система имеет возможность дать пользователю адекватный ответ, с подробным описанием почему эта команда не допустима в текущем контексте. Единый фокус ввода/вывода - панацея от серых кнопок!

[sukhanchik]

Выскажусь с позиции человека, которому в силу своей работы постоянно приходится изучать новый функционал.
Серые кнопки - это ОЧЕНЬ удобно. Я плююсь, когда кнопки оставляют доступными, но при их нажатии выскакивает та или иная ошибка.
Т.е. тыркаясь в новый функционал без наличия под рукой идеальных инструкций мне очень удобно тыркаться в ограниченное количество кнопок и не гадать в какую кнопку надо тыкать.
Особенно это касается процессов, которые нужно проходить последовательно, например сначала подтвердить заказ на покупку, а затем его разнести.

Конечно бывают ошибки и кнопка / поле остаются недоступными когда не надо.
Конечно бывают ошибки и кнопка / поле остаются доступными когда не надо.
Но какие бы ни были классными инструкции - объективно пользователям низкого уровня нужно давать доступ к минимальному количеству кнопок и полей для исключения ошибок. Причина банальна и проста... как правило чем ниже уровень зарплаты - тем больше текучка кадров. И получается, что либо систему не спускать на низкий уровень, либо сделать на низком уровне интерфейс, максимально не позволяющий отклониться от процесса. Обычно руководство выбирает вариант удобного интерфейса.

Производительность... Ну так если на Active делать джойны InventTrans с InventSettlement без фильтрации, да еще добавлять туда GeneralJournal-таблицы (а ранее LedgerTrans) - то понятно, что система умрет сразу на открытии формы. Всегда можно придумать либо дополнительные таблицы, либо кеширование в памяти, что сильно ускорит вопросы производительности и скорость перерисовки не скажется на работе пользователей.
Опять-таки - систему пишут люди и никто не идеален - даже разработчики Microsoft - всегда могут быть ошибки, в т.ч. связанные с производительностью
А по факту - пользователи систему всегда изучают, если в режиме текущей работы выполняются те или иные разработки, потому что система постоянно меняется.
Поэтому чем меньше "свободы" у пользователей при изучении системы - тем им проще с ней работать.
Ну и конечно уменьшение "свободы" должно уменьшать количество кликов, т.е. пользователь сразу должен видеть места, в которые ему щелкать запрещено (вариант - их не видеть совсем, но в этом случае Аксапта перегруппировывает расположение объектов на форме и это визуально тяжелее воспринимается, когда у тебя нужное тебе поле то в одном, то в другом углу экрана)

[vmoskalenko]

Цитата:

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

Пользователь волен в любой момент набрать абсолютно любую команду (нажать на любую кнопку), и система имеет возможность дать пользователю адекватный ответ, с подробным описанием почему эта команда не допустима в текущем контексте. Единый фокус ввода/вывода - панацея от серых кнопок!

А если всё выполнилось успешно, то

• UNIX-style, Пользователь получит на консоль ничего/пусто
• DOS-style, Пользователь получит на консоль как минимум ОК, а как максимум Лог.
• PowerShell-style, Пользователь получит на консоль от пусто до детального лога в зависимости от параметров -Verbose -Debug

Поэтому я бы не уходил в восторг от работы с консолью.

[db]

Тема навеяла воспоминания об собственных идеях "идеально правильной системы" Там то же были мысли о том как бы я сделал отображение причины запрета операции

Согласен, серая кнопка и хелп-текст с подсказкой почему нельзя нажать были бы прекрасны

Но в данной системе такое не принято. Принято просто делать серым. Поэтому не выЁЖиваемся и делаем ровно так как принято. Единообразно, серо, безобразно и надо нажиать ф5 - пофигу. Здесь это стандарт, ему и следуем. Локальные прекрасности будут вызывать много никому не нужных вопросов

[pitersky]

Не стоит забывать, что серые кнопки крайне толерантны к мультивыбору))))) и есть опасность запустить в обработку то, что не следует, именно потому что оно выбрано, но не последнее в списке. ну и наоборот - если из 10 выбранных журналов 1 (последний выбранный) запрещён, то обработать не получится ни один из десяти

[ta_and]

Цитата:

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

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

Да. И эту ошибку нужно сразу же закрыть. Не читая. И плюнуть. В монитор.
Зачем какая-то глупая информация?!
Какая тупая система! Не может сделать мне только одну большую доступную кнопку на стуле, на которую я могу прийти и в начале работы сесть. И все должно работать.
А я буду смотреть на монитор и гонять пасьянс.
Вообще идиоты эти яйцеголовые придумали какую-то хрень с кнопками... Лучше бы на бумажке крыжики ставили... Вот это было удобно.

[Logger]

Цитата:

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

Коллеги, ну зачем же так сурово? можно же всё проще сделать существующими механизмами:
1) написать нужную проверку, которая возвращает true/false (последнее - в виде checkFailed)
2) в строчке на active эту проверку вызывать. если false - рисовать в отдельном поле красный квадратик (как при разноске складских журналов)
3) по нажатию кнопки - делать эту же проверку, но выводить false-результат в инфолог

Будет наглядно без всяких серых кнопок

Ваш вариант мне нравится и кажется весьма удачным.
По счастью весь самописный код у нас написан в стиле
а. Проверка (метод check) можно ли запустить функцию с выводом в инфолог checkFailed
б. если в п.а все ок, то выполняем функцию.

Тогда можно не запрещать на самописных кнопках нажатие (не использовать button.enable()) а всегда разрешать нажать кнопку, так как если кнопку нажимать было нельзя то проверка сама скажет о себе в инфолог почему нельзя (да, многие юзеры его не читают, но зато читает первая линия техподдержки и консультанты, т.е. цепочка задействованных специалистов все равно будет короче - Profit !). Документацию подробно можно при этом не вести. Все равно она быстро устаревает и зачастую не до конца соответствует тому как все работает в реальности (как следствие регулярно возникают проблемы которые эскалируются до консультантов, они не могут сами посмотреть и в итоге по цепочке доходит до программистов, время у всех тратится напрасно, юзеры по итогу напрягаются - аксапта плохая - специалисты по ней еще хуже).

Т.е. при такой схеме, мы автоматом получаем актуальное сообщение почему нажатие кнопки невозможно. Удобно и экономно в поддержке.

Правда при этом все же хотелось бы просигнализировать пользователю что кнопку нажимать не следует.
Можно вызывать на active метод проверки из пункта а. с подавлением вывода в инфолог.
А если метод вернул false, то как-то визуально помечать невозможность нажатия кнопки.
Например :
1. Делать шрифт на кнопке серым (как будто кнопка засерена, но тем не менее нажимается. Нелучший вариант, так как скорее всего никто и не попытается нажать)
2. Или курсивом
3. Или дорисовывать на кнопке иконку со специальным запретным значком (красная иконка с знаком "проезд запрещен" или что-то в этом духе. Если таких кнопок будет много, то может рябить в глазах поэтому что-то нейтральное лучше поставить)