July 28th, 2007

nyaload

GUI, текст-боксы, нытьё

Ненавижу TextBoxы. Они одновременно и для ввода информации, и для вывода.
Когда в фокусе - то для ввода. Иначе - для вывода. Когда приходит обновлении информации для tex-box, а мы в него ещё пишем - то непонятно что делать. Ещё непонятней, когда диалог временно скрывается или деактивируется, и tex-box остаётся навечно в фокусе.

Еще ряд сюрпризов, когда в text-box изображается текстом не совсем та информация, которая внутри программы. Скажем, float с точностью до одного знака после запятой, а внутри программы - настоящее значение. Тогда щелчок по text-box без какого-либо ввода неожиданным образом изменяет этот float и эти же данные в других диалогах представленые другим образом начинает дёргать Пример - цвет в HSV и RGB, или scale экрана + textbox для ввода и просмотра этого scale.

Если кто-то знает какой-то сборник статей или книгу как программировать GUI, точнее как без гемороя сделать взаимодействие модели внутри программы и пользователя через GUI, буду рад ссылкам. Конкретней - тонкости фокуса, тонкости Model-View(s) взаимодействия. Брутальный Model-View описаный в GOF - не работает. Если на каждое движение мышки (изменяющее внутрений документ) втупую обновлять все сложные диалоговые окна, начинает жестоко тормозить. Или через цепочку событий об изменениях вводит в бесконечную рекурсию. Апдейт view зависит от того, было ли изменение из документа, или же спровоцировано из него самого. Вот тут Джоель немного пишет, но он пишет про "что", а не "как".
Хочется что-то промежуточное между "низкоуровневой" справкой MSDN с описанием отдельных методов и между описанием того, как будет удобно пользователю. Пишу на .NET Windows Forms, это скорее всего важно так как в каждом фреймворке - свои заморочки с событиями, последовательностью действий, с фокусом элементов, можно ли в Foo.OnChangeXXX менять Foo.XXX (а Foo.YYY ?).

Ещё каждый диалог должен уметь отображать данные не одного выделенного элемента, а мержить данные из сразу нескольких. Если данные разные - то показывать пустоту. Иначе проверить, что они одинаковые и отобразить. При вводе - не просто присвоить, а присвоить каждому элементу в выделении, соответсвенно каждое присваивание превращается в цикл и занимает в два-три раза больше места. Проверки "что оно всё одинковое" - ещё неприятней. Если выделение пустое - это отдельная ветка if, опустошить всё, задизейблить и не давать редактировать. Почти поддаётся формализации и реюзанью (пример - MS удалось сделать юзабельный, но неудобный для программиста Property Grid), но в каждом случае возникают свои тонкости...