Большие объемы сучше, естественно, отображать в привычном виде — таблица и ее вариации. Но вот что делать с небольшими справочниками (так они, кажется, называются). Тот же грид использовать не хотелось — желательно было запихнуть все в диалог, не раздувая последний на весь экран. И вот какой мне вариант придумался:
Визард-лайк полосу сверху не пинать . Как оно вам, уважаемая общественность?
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
Н>Большие объемы сучше, естественно, отображать в привычном виде — таблица и ее вариации. Но вот что делать с небольшими справочниками (так они, кажется, называются). Тот же грид использовать не хотелось — желательно было запихнуть все в диалог, не раздувая последний на весь экран. И вот какой мне вариант придумался:
Н>
Н>Визард-лайк полосу сверху не пинать . Как оно вам, уважаемая общественность?
Мне нравится, а можно сделать разную высоту для выбранных и невыбранных элементов списка? Тогда по вертикали займет меньше места и соответственно меньше скроллинга.
Здравствуйте, henson, Вы писали:
H>Мне нравится, а можно сделать разную высоту для выбранных и невыбранных элементов списка? Тогда по вертикали займет меньше места и соответственно меньше скроллинга.
Тоже так хотел, но это subclassed list box, а там wm_measureitem приходит так, что такой вариант не пройдет. Хотя можно еще разок попробовать.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
Н>Большие объемы сучше, естественно, отображать в привычном виде — таблица и ее вариации. Но вот что делать с небольшими справочниками (так они, кажется, называются). Тот же грид использовать не хотелось — желательно было запихнуть все в диалог, не раздувая последний на весь экран. И вот какой мне вариант придумался:
[...]
Н>Визард-лайк полосу сверху не пинать . Как оно вам, уважаемая общественность?
Симпатично.
Где-то видел что-то похожее... Здесь, кажется.
А инлайн редактирование предполагается, или это уже слишком?
Здравствуйте, Spidola, Вы писали:
S>Где-то видел что-то похожее... Здесь, кажется. S>А инлайн редактирование предполагается, или это уже слишком?
Не то чтоб _слишком_, но такого нет. Неинтуитивно будет, имхо. Как тогда, к примеру, отмену изменений реализовать (по сравнению с "Отмена" в диалоге редактирования)?
HgLab: Mercurial Server and Repository Management for Windows
H>Мне нравится, а можно сделать разную высоту для выбранных и невыбранных элементов списка? Тогда по вертикали займет меньше места и соответственно меньше скроллинга.
ИМХО, лучше не надо. Изменяемая высота сделана в Add/Remove Programs в винде и там она периодически нервирует, особенно у краев списка, когда один элемент встает на место другого
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, Spidola, Вы писали:
S>>Где-то видел что-то похожее... Здесь, кажется. S>>А инлайн редактирование предполагается, или это уже слишком?
Н>Не то чтоб _слишком_, но такого нет. Неинтуитивно будет, имхо. Как тогда, к примеру, отмену изменений реализовать (по сравнению с "Отмена" в диалоге редактирования)?
А кнопки прямо в место, где редактируется встроить можно (если возможно, конечно). Т.е. нажал "Редактировать", все тексты превратились в поля ввода и появились две кнопки в правом нижнем углу прямоугольника (к примеру) — Ok и Cancel.
Здравствуйте, Spidola, Вы писали:
S>Здравствуйте, Нахлобуч, Вы писали:
Н>>Здравствуйте, Spidola, Вы писали:
S>>>Где-то видел что-то похожее... Здесь, кажется. S>>>А инлайн редактирование предполагается, или это уже слишком?
Н>>Не то чтоб _слишком_, но такого нет. Неинтуитивно будет, имхо. Как тогда, к примеру, отмену изменений реализовать (по сравнению с "Отмена" в диалоге редактирования)?
S>А кнопки прямо в место, где редактируется встроить можно (если возможно, конечно). Т.е. нажал "Редактировать", все тексты превратились в поля ввода и появились две кнопки в правом нижнем углу прямоугольника (к примеру) — Ok и Cancel.
Здравствуйте, Mamut, Вы писали:
H>>Мне нравится, а можно сделать разную высоту для выбранных и невыбранных элементов списка? Тогда по вертикали займет меньше места и соответственно меньше скроллинга.
M>ИМХО, лучше не надо. Изменяемая высота сделана в Add/Remove Programs в винде и там она периодически нервирует, особенно у краев списка, когда один элемент встает на место другого
Там реализовано не очень удачно. Список перед тем как принять конечный вид может перерисоваться несколько раз меняя при этом размер.
Но если записей в списке много, то показывать все поля расточительно, да и заполнение из БД займет бОльше времени. А вот получить недостающие поля записи из БД по выбору элемента можно довольно быстро.
M>>ИМХО, лучше не надо. Изменяемая высота сделана в Add/Remove Programs в винде и там она периодически нервирует, особенно у краев списка, когда один элемент встает на место другого
H>Там реализовано не очень удачно. Список перед тем как принять конечный вид может перерисоваться несколько раз меняя при этом размер. H>Но если записей в списке много, то показывать все поля расточительно, да и заполнение из БД займет бОльше времени. А вот получить недостающие поля записи из БД по выбору элемента можно довольно быстро.
Тоже верно. Я, в принципе, не против изменяемой высоты, но по-человечски ее сделать — это
Здравствуйте, henson, Вы писали:
H>Мне нравится, а можно сделать разную высоту для выбранных и невыбранных элементов списка?
Ты когда-нибудь пользовался таким списком активно? От того что элементы ниже выбранного постоянно прыгают вверх-вниз удобство мягко говоря не возрастает.
Во-первых, почему дублирование? Доллар США
Валюта: Доллар США
Во-вторых, строка форматирования не катит. Она выведена в виде понятном только программистам.
Если её вводят, как строку форматирования для функции printf, то это простой способ разрушить программу, неправильным вводом.
Надо выводить не строку форматирования, а примеры форматирования, а вводить формат через элементы управления диалога, а не строку формата.
В-третьих, нет выравнивания значений.
В-четвётых, фраза "Управление валютами" в заголовке и верхней панели два раза, зато пояснение почему-то по английски написано.
В-пятых, static'и над и под списком лишние.
В-шестых, кнопки управления списком убрать спустить вниз
В-седьмых, кнопки управления списком вообще не воспринимаются как кнопки. Более того на одном диалоге сразу два вида кнопок — очень плохо.
В-восьмых, иконки у кнопок "редактировать" и "обновить" не очень понятные. Лучше их вообще убрать, а кнопки сделать нормальными, выпуклыми.
В-девятых, иконка $EF слева от элементов смысловой нагрузки не несёт, а место занимает. Лучше там крупным шрифтом нарисовать обозначение валюты (если есть), а строку символ убрать.
В-десятых, фон у иконки в верхней панели надо бы убрать. Оттенки похожие, но не одинаковые.
Короче говоря, я бы сделал как-то так (набросок сделанный в графигеском редакторе, если что-то нарисованно не так, как оно обычно бывает, сильно не пинать )
+ открывать редактирование по двойному щелчку по элементу
+ поддерживать контекстное меню с пунктами "редактировать, удалить, обновить" для элемента списка и "добавить, обновить" для пустого места.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Spidola, Вы писали:
S>>А кнопки прямо в место, где редактируется встроить можно
A>Можно, но не нужно.
Ещё бы согласился, что необходимости в этом нет, если бы не следующая фраза, аргументирующая ненужность...
A>Получается пока я не нажал на элемент списка я не могу узнать что с ним делать.
Не "не нажал", а пока не выполнил стартовое действие.
То, что вы можете сделать с элементом списка (в контексте первого исходного скриншота), у вас написано вверху (Добавить, редактировать, удалить...). Поскольку эти действия вынесены вверх, то предполагается что они типичны для каждого элемента списка.
Появление кнопок Ok (Save) и Cancel является следствием нажатия кнопки "Редактировать", к примеру. И пользователю не нужно показывать все цепочки действий, которые он может совершить с элементом, поскольку последующие действия (Ok и Cancel) являются обязательным следствием предыдущего осознанно выбранного действия (редактировать). Вот кнопки, которые показаны пользователю вверху — это достаточный набор для выбора осознанного действия.
Появление кнопок в геометрических рамках самого элемента списка — вопрос, насчёт которого можно дискутировать и оценивать данный вариант с различных точек зрения. Например, с точки зрения концентрации внимания пользователя в одной зоне экрана для выполнения каких либо связанных действий, на мой взгляд, является аргументом в пользу размещенищения кнопок Ok и Cancel в указанное место.
Это я ещё не говорю о варианте, когда элементы списка подразумевают инвариантное редактирование с различным поведением при редактировании (кстати, как простой пример — всё та же "Установка и удаление программ" в Windows, где набор контролов меняется в зависимости от свойств элементов списка).
Здравствуйте, Spidola, Вы писали:
A>>Получается пока я не нажал на элемент списка я не могу узнать что с ним делать. S>Не "не нажал", а пока не выполнил стартовое действие.
То есть чтобы понять что я в принципе могу сделать мне надо совершить какие-то движения, потому что изначально список моих дейсвий нигде не виден.
S>То, что вы можете сделать с элементом списка (в контексте первого исходного скриншота), у вас написано вверху (Добавить, редактировать, удалить...). Поскольку эти действия вынесены вверх, то предполагается что они типичны для каждого элемента списка.
да
S>Появление кнопок Ok (Save) и Cancel является следствием нажатия кнопки "Редактировать", к примеру.
Нет, OK/Cancel относятся ко всему списку целиком. Я могу долго редактировать весь список: добавлять и удалять элементы, но потом нажать Cancel и весь список не изменится. Кнопки OK и Cancel относящиеся к конкретному элементу будут в диалоге который откроется при надатии на "Добавить" или "Редактировать"
S>И пользователю не нужно показывать все цепочки действий, которые он может совершить с элементом, поскольку последующие действия (Ok и Cancel) являются обязательным следствием предыдущего осознанно выбранного действия (редактировать). Вот кнопки, которые показаны пользователю вверху — это достаточный набор для выбора осознанного действия.
Тогда это неправильный подход. Если дейсвия предполагается показывать по мере необходимости, то надо писать Мастер (Wizard), а если элементы управления будут появлятся на плоском диалоге в зависимости от моих действий как грибы после дождя, то это очень плохо.
S>Появление кнопок в геометрических рамках самого элемента списка — вопрос, насчёт которого можно дискутировать и оценивать данный вариант с различных точек зрения. Например, с точки зрения концентрации внимания пользователя в одной зоне экрана для выполнения каких либо связанных действий, на мой взгляд, является аргументом в пользу размещенищения кнопок Ok и Cancel в указанное место.
Ну, во-первых, сам диалог не очень-то и большой, чтоб внимание рассеивалось.
Во-вторых, однотипные кнопки придётся размещать в разных местах. "Добавить" вне списка, "Редактировать" и "Удалить" в списке. Вышел беспорядок: действия для однотипных операций: добавления и удаления элемента, не однотипны.
S>Это я ещё не говорю о варианте, когда элементы списка подразумевают инвариантное редактирование с различным поведением при редактировании (кстати, как простой пример — всё та же "Установка и удаление программ" в Windows, где набор контролов меняется в зависимости от свойств элементов списка).
Кстати говоря диалог "Установка и удаление программ" один из хороших примеров того как не надо делать диавлоги.
Во-первых, не никакой визуальной связи между выделением слева и списком справа. Мне интуитивно не понятно что именно изменится, если нажать на "нечто" слева. Именно "нечто", потому что по внешнему виду это кнопки на панели инструментов, а по поведению неизвестно что. Первые две и четвёртая ведут себя как закладки TabControl меняя содержимое справа, а вот третья открывает новый диалог.
Для вывода данных используется таблица, но заголовка у таблицы нету. И следовательно сортировка беднее (нет сортировки в обратном порядке) и неудобно настраивается.
Есть данные (частота вызова, последний вызов), которые фигурируют но не отображаются в таблице.
подразумевалось, что кнопки Ok и Cancel принадлежат конкретному элементу списка, а не всем элементам. Т.е. каждый элемент списка управляется самостоятельно.
A>Здравствуйте, Spidola, Вы писали:
A>>>Получается пока я не нажал на элемент списка я не могу узнать что с ним делать. S>>Не "не нажал", а пока не выполнил стартовое действие.
A>То есть чтобы понять что я в принципе могу сделать мне надо совершить какие-то движения, потому что изначально список моих дейсвий нигде не виден.
Нет, не то. Имеется ввиду, что если вы хотите отредактировать запись, то система в обязательном порядке предложит вам либо сохранить отредактированные данные, либо отменить исправления. Знание о том, что можно сделать с записью после перехода к редактированию пользователь всё равно получит после перехода к редактированию. Наличие на экране недоступных кнопок, демонстрирующих часть свойств другого состояния записи не только не даст полной картины того, что можно сделать с записью, а ещё может запутать пользователя, который не обязательно должен понимать, что указанные кнопки относятся к другому состоянию.
S>>То, что вы можете сделать с элементом списка (в контексте первого исходного скриншота), у вас написано вверху (Добавить, редактировать, удалить...). Поскольку эти действия вынесены вверх, то предполагается что они типичны для каждого элемента списка.
A>да
S>>Появление кнопок Ok (Save) и Cancel является следствием нажатия кнопки "Редактировать", к примеру.
A>Нет, OK/Cancel относятся ко всему списку целиком. Я могу долго редактировать весь список: добавлять и удалять элементы, но потом нажать Cancel и весь список не изменится. Кнопки OK и Cancel относящиеся к конкретному элементу будут в диалоге который откроется при надатии на "Добавить" или "Редактировать"
Я имел ввиду, что Ok и Cancel относятся к каждому элементу списка и каждый элемент редактируется отдельно в рамках собственной "транзакции".
S>>И пользователю не нужно показывать все цепочки действий, которые он может совершить с элементом, поскольку последующие действия (Ok и Cancel) являются обязательным следствием предыдущего осознанно выбранного действия (редактировать). Вот кнопки, которые показаны пользователю вверху — это достаточный набор для выбора осознанного действия.
A>Тогда это неправильный подход. Если дейсвия предполагается показывать по мере необходимости, то надо писать Мастер (Wizard), а если элементы управления будут появлятся на плоском диалоге в зависимости от моих действий как грибы после дождя, то это очень плохо.
Microsoft с этим не согласен
S>>Появление кнопок в геометрических рамках самого элемента списка — вопрос, насчёт которого можно дискутировать и оценивать данный вариант с различных точек зрения. Например, с точки зрения концентрации внимания пользователя в одной зоне экрана для выполнения каких либо связанных действий, на мой взгляд, является аргументом в пользу размещенищения кнопок Ok и Cancel в указанное место.
A>Ну, во-первых, сам диалог не очень-то и большой, чтоб внимание рассеивалось.
В конкретном случае да, согласен. Если автор не разрешит окно растягивать
A>Во-вторых, однотипные кнопки придётся размещать в разных местах. "Добавить" вне списка, "Редактировать" и "Удалить" в списке. Вышел беспорядок: действия для однотипных операций: добавления и удаления элемента, не однотипны.
Не согласен Действия "Добавить" и "удалить" относятся к списку (добавить в список, удалить из списка, редактировать элемент в списке), а Ok и Cancel относятся к конкретному элементу.
S>>Это я ещё не говорю о варианте, когда элементы списка подразумевают инвариантное редактирование с различным поведением при редактировании (кстати, как простой пример — всё та же "Установка и удаление программ" в Windows, где набор контролов меняется в зависимости от свойств элементов списка).
A>Кстати говоря диалог "Установка и удаление программ" один из хороших примеров того как не надо делать диавлоги.
A>Во-первых, не никакой визуальной связи между выделением слева и списком справа. Мне интуитивно не понятно что именно изменится, если нажать на "нечто" слева. Именно "нечто", потому что по внешнему виду это кнопки на панели инструментов, а по поведению неизвестно что. Первые две и четвёртая ведут себя как закладки TabControl меняя содержимое справа, а вот третья открывает новый диалог.
A>Для вывода данных используется таблица, но заголовка у таблицы нету. И следовательно сортировка беднее (нет сортировки в обратном порядке) и неудобно настраивается.
A>Есть данные (частота вызова, последний вызов), которые фигурируют но не отображаются в таблице.
A>Короче пример того как не надо делать диалоги.
Согласен, мне тоже не очень нравится, однако ИМХО это уже не совсем диалог.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Spidola, Вы писали:
S>>Вот вроде всё правильно написано, а смотрится ИМХО как-то похуже оригинала... Чего-то не хватает...
A>Список и остальгой диалог в разных стилях, от того и визуальное отторжение
В вашем варианте диалога я не очень понял, что будет происходить, когда пользователь будет нажимать кнопку "Редактировать" и как он потом будет возвращаться в текущее нарисованное состояние...
полосу сверху не пинать 
. Как оно вам, уважаемая общественность?
)
