Несколько предложений по юзабилити №2

Модератор: motyara

Аватара пользователя
Qwertiy
Охотник за багами
Сообщения: 1199
Зарегистрирован: Вс янв 31, 2010 12:12 am

Сообщение Qwertiy » Пн май 10, 2010 2:58 am

Fuhrer писал(а):Обычно, в диалогах, где присутствует элементы с памятью (радиобаттоны, чекбоксы) есть одна кнопка, которая реагирует на Enter. И тогда, как и положено, она подсвечивается жирным контуром. Она же и нажимается при двойном щелчке на радиобаттоне, если это какой-нибудь всплывающий диалог с вариантами ответа.
А кто мешает изметять свойство DefaultButton в соответствии в активным переключателем? И подсветка будет.
Fuhrer писал(а):
Qwertiy писал(а):Tab - лишнее. Стрелки влево и вправо его заменяют.
Ага! То есть программа-пример в этом плане не отражает задумку автора? Если так, тогда пользование диалогом действительно приобретает смысл. Правда, нестандартная обработка нажатий на стрелки ([<--],[-->]) потребует привыкания к ней со стороны пользователя, что не есть хорошо. Да и нагромождение элементов пугает не меньше моих микрокнопок. Но уже какой-тто смысл есть. Поехали дальше.
Я уже несколько раз писал, что обработка клавиатуры не доделана... Даже, что именно в ней не доделано...
По задумке Влево=Shift+Tab, Вправо=Tab. Но сочетания с Tab (теоретически) тоже должны поддерживаться.
Fuhrer писал(а):
Qwertiy писал(а):И Shift почти не нужен.
Да, Shift - это слабое место. Есть смысл в том, чтобы пользователь нажимал Enter без лишних условий. Но только в случае неувеличения количества действий до нажатия Enter.
Для этого к основным вариантам и добавлен пункт "Все".
Fuhrer писал(а):Ну а что сложнее для попадания - моя кнопка или Ваш радиобаттон - спорить не буду, ибо кому как. Наверно, кнопка сложнее. Ну на то она и более ответственна. Уменьшенная вероятность случайно заменить все файлы в очереди вместо одного - скорее фича, чем баг.
Это только у Вас. Во всех других диалогах (Проводник, TC, 7Zip и т. д.) эти кнопки одинакового размера.
Кстати, для переключателей используется свойство Dock, а их высота определяется автоматически, чтобы текст помещался.
Fuhrer писал(а):Это чрезвычайно полезная функция. Почти всегда, если у файлов разное содержимое, то и некоторые из их атрибутов отличны. И наоборот: если все атрибуты одинаковы, то одинаково и содержимое. Это относится ко всем архивам, видеофайлам, как правило и к текстовым файлам.
Идея хорошая, хотя по содержимому надёжнее... Вообще, когда мне нужна эта функция, то я бы предпочёл именно содержимое, но, наверное, здесь возможны варианты...
Fuhrer писал(а):Я считаю очень неправильным вынесение настроек "При совпадении имён и размеров сравнивать по содержимому" и "При совпадении по содержимому считать файл перемещённым" за пределы диалога. ... Кроме того, возможен бездиалоговый запуск копирования (у меня Drag`n`Drop так работает, например), когда копирование начинается вообще без лишних переспрашиваний.
1. Как я писал, эта настройка приоритетна над выбором в диалоге. Т. е. пользователь ставит оба флажка, потом, на паре несовпадающих файлов выбирает "Пропустить все". Результат: все файлы, для которых в папке назначения существуют дубликаты, удалены; остальные файлы, для которых в папке назначения есть одноимённые, пропущены, а все остальные перемещены. Вы действительно считаете, что такую опцию следует помещать именно в диалог? А что будет, если разные файлы попадутся раньше, чем совпадающие?
2. У меня при drag-n-drop'е получается стандартный диалог, что меня вполне устраивает...
Fuhrer писал(а):А насчёт условий... Мне кажется, есть смысл рассматривать три варианта:
1. У файлов одинаковые имена. Содержимое никого не интересует.
2. Одинаковые имена и все атрибуты. Под атрибутами я понимаю всю информацию о файле, не включая его путь, права, и содержимое. То есть это его даты (создания, изменения), размер, и собственно, файловые атрибуты в понимании FAT/NTFS. Если эти данные совпадают (а их можно мгновенно получить для файла любого размера), тогда можно с большой долей вероятности делать вывод о том, что файлы одинаковы.
3. Сравнение по содержимому.

Все три варианта нужно чётко указать пользователю, чтобы он хорошо понимал на основании какого из трёх сравнений программа принимает решение о действии. Что самое сложное, эти же три вида сравнения можно применить не только для удаления исходника, но и для других операций (замена, пропуск, дописывание). Правда, не во всех случаях это рационально, нужно продумать возможные применимые в жизни варианты и дать пользователю возможность их выбрать.
Это конечно хорошо, но даже я считаю такое количество настроек перебором... В таких случаях есть синхронизация... Наверное...
Fuhrer писал(а):Изображение
На этой картинке - ничем! А в диалоге - другое дело!
1. Если Вы добавляете кнопку, то как её выбрать? Если рассматривать переключение с помощью стрелок, то как Вы объясните, почему кнопка "Пропустить файл" выбирается с помощью стрелок влево/вправо, а кнопка "Пропустить все" только с помощью стрелок вверх/вниз при активной кнопке "Пропустить файл"? Догадываетесь, что пользователь подумает о таком диалоге? Если включить кнопку в последовательность кнопок, то это увеличит максимальное количество необходимых клавиш до 7 (как минимум), что уже много.
2. Единство интерфейса. В каждой группе есть возможность выбрать вариант одного действия и подтвердить его.
3. Возможность сохранения выбранного ранее варианта для каждого из основных действий в отдельности. Высока вероятность, что он же будет выбран снова. В таком случае, это экономит одно действие.
И ещё, пользуясь Вашей логикой, можно все переключатели заменить на кнопки. И что тогда будет?

Аватара пользователя
Max Diesel
Автор программы
Сообщения: 3125
Зарегистрирован: Пт окт 12, 2007 9:00 pm
Контактная информация:

Сообщение Max Diesel » Пн май 10, 2010 4:04 am

Qwertiy писал(а):И я, и Fuhrer считаем её полезной и нужной. Да и Вы раньше не были против (https://forum.unrealcommander.net/viewto ... 5314#p5314). Что касается побайтового сравнения, то в моём варианте оно возможно... Кроме того, я просил добавить соответствующую опцию (https://forum.unrealcommander.net/viewto ... 5303#p5303).
Вообще-то "раньше" я сказал что "В некотором плане это действительно рационально" и еще сказал что "подумаю над этим". Так вот подумав я и пришел к выводу что "считать перемещенным" - функция нерациональная, а вот флаг автоматического сравнения рациональное зерно все-таки имеет.
Qwertiy писал(а):PS: Всё-таки посмотрите предложенный мной диалог.
Посмотрел, но не могу сказать что его идея мне нравится. На первый взгляд мне показалось что к этому диалогу должен прилагаться иллюстрированный мануал чтобы начинающий пользователь смог разобраться в нем (впрочем начинающие пользователи и не используют Unreal Commander, им зачастую как-то удается находиться в блаженном неведении о сущестовании файлов как таковых). При вторичном просмотре (после перезагрузки, вызванной тем что функция "Открыть" сумела уронить W7 при всей его защищенности) я заметил что идея диалога состоит лишь в группировании действий по сути операции - подозреваю что это не несет больших улучшений в плане восприятия диалога или в плане его удобства.

Информация для размышления: по части информатики со времени обучения мне запомнилась такая мысль - "чем меньше положений у переключателя, тем стабильнее его работа и тем меньше вероятность выхода его из строя", из нее следовало что именно потому количество битов было принято равным двум, а не трем-четырем-пяти... В связи с этим принципом реализована логика диалога замены в TC - каждой кнопке отдельное значение, я же использовал модифицированную логику (как мне кажется, более рациональную), при которой "общий множитель" (то есть пункт "для всех") был вынесен за скобки и его можно указать в виде флага нажатием средней/правой мыши, либо Shift/Ctrl. В этой теме можно заметить что у каждого здесь есть свое мнение по поводу вида диалога замены - мой вариант с вынесением "общего множителя", Fuhrer предложил вариант без вынесения общего множителя но с волшебным превращением кнопок, Qwertiy предложил вариант с множеством радиобаттонов и разделением по категориям, ironx предложил некий вариант "а-ля TC"... определенно не хватает чтобы появились еще несколько "авторов диалогов", которые предложили бы вот такие варианты:
  • круговая циклическая последовательность изображенных графически вариантов выбора (так было организовано меню в телефонах Samsung лет 5-ть назад, кроме того на некоторых сайтах меню выполнено в таком виде),
  • совокупность вариантов выбора, расположенных в виде круговой диаграммы (это нередко встречается в компьютерных играх в качестве меню выбора оружия),
  • варианты выбора в списке ComboBox,
  • варианты выбора в иерархической структуре (в виде дерева)
И я уверен что каждому его вариант будет казаться самым лучшим, максимально удобным. Если сделать плагины, то потом при изменении набора "входных данных" всем авторам диалогов придется переделывать свои диалоги на новый лад, плюс ко всему такие диалоги будут предполагать только лишь заложенные в наборе входных данных функции (то есть полет фантазии не будет безграничным, нельзя будет вызвать например расчет хэша обоих файлов если конечно функции хэширования не будут заложены в самом файле диалога). Причем плагины все-таки должны были бы быть не только для режима тестирования, а общественного использования (соответственно проблема с локализацией и тд). [/color]

Аватара пользователя
Qwertiy
Охотник за багами
Сообщения: 1199
Зарегистрирован: Вс янв 31, 2010 12:12 am

Сообщение Qwertiy » Пн май 10, 2010 12:26 pm

Max Diesel писал(а):Вообще-то "раньше" я сказал что "В некотором плане это действительно рационально" и еще сказал что "подумаю над этим". Так вот подумав я и пришел к выводу что "считать перемещенным" - функция нерациональная, а вот флаг автоматического сравнения рациональное зерно все-таки имеет.
Я и не говорил, что Вы были за, я сказал "Не были против"...
Max Diesel писал(а):И я уверен что каждому его вариант будет казаться самым лучшим, максимально удобным. Если сделать плагины, то потом при изменении набора "входных данных" всем авторам диалогов придется переделывать свои диалоги на новый лад, плюс ко всему такие диалоги будут предполагать только лишь заложенные в наборе входных данных функции (то есть полет фантазии не будет безграничным, нельзя будет вызвать например расчет хэша обоих файлов если конечно функции хэширования не будут заложены в самом файле диалога). Причем плагины все-таки должны были бы быть не только для режима тестирования, а общественного использования (соответственно проблема с локализацией и тд).
Такое ощущение, что Вы не прочитали
Qwertiy писал(а):Просто опишу простой алгоритм, позволяющий использовать разные диалоги с разными возможностями.
1. Для каждой новой очереди (перед копированием/перемещением) создаётся свой чистый экземпляр диалога, или используется метод Clear() уже существующего.
2. Каждый раз при возникновении конфликта вызывается метод ShowDialog(Source, Dest), который возвращает одно из следующих значений: ЗаменитьПриёмник, УдалитьИсточник, ПропуститьИсточник, Дописать, Переименовать, ПереименоватьИсточник, ПереименоватьПриёмник, ПереименоватьИсточникВ, ПереименоватьПриёмникВ, Отмена.
3. В случае возврата значений ПереименоватьИсточникВ и ПереименоватьПриёмникВ с помощью метода GetNewName() получить новое имя файла.
4. В случае возврата других видов переименования - показать диалог переименования.
5. Также диалог должен предоставлять возможность проверить, установлено ли переименовать все, для случая автоматического переименования средствами UC, а не диалога.
Собственно, это всё. Пункты "Более старые", "Более мелкие" и т. д., а также флажок "Применить ко всем" обрабатываюся самим диалогом и он сам решает, что после "Применить ко всем", ему надо не отображаться, а сразу просчитать, что надо сделать и вернуть соответствующее значение.
Можно диалогу предоставить больше возможных возвращаемых значений, но в любом случае, этих достаточно для полноценной реализации как имеющихся, так и дополнительных возможностей.
Т. е. все диалоги возвращают только необходимое действие для данной пары файлов. Вся логика обработки возможностей - в реализации самих диалогов.
Правда, я решил внести сюда небольшую поправку: чтобы уменьшить число багов в реализации диалогов, кроме перечисленных значений, надо разрешить диалогам возвращать все значения, поддерживаемые UC.

Аватара пользователя
Qwertiy
Охотник за багами
Сообщения: 1199
Зарегистрирован: Вс янв 31, 2010 12:12 am

Сообщение Qwertiy » Пн май 10, 2010 12:39 pm

Max Diesel писал(а):Причем плагины все-таки должны были бы быть не только для режима тестирования, а общественного использования (соответственно проблема с локализацией и тд).
1. Про это я тоже писал. В каждой стране найдутся разработчики, которые сделают плагин на своём языке.
2. Под фразой "разрешить использование", я имел в виду именно "разрешить", а не "заставлять", т. е. Вы сами знаете свои файлы локализации, поэтому Ваш модуль может их использовать. А если нужен другой диалог - то ищи на устраивающем языке... Ещё, как вариант, каждому диалогу - свой языковой файл от разработчика диалога.

PS: Пришла в голову мысль... Правда, Вы её не поддержите, да и я сам считаю, что этого в ближайшее время не надо... Но всё же скажу. Поддержка макросов в UC.

Аватара пользователя
Fuhrer
Охотник за багами
Сообщения: 127
Зарегистрирован: Ср мар 03, 2010 12:51 am

Re: Несколько предложений по юзабилити №2

Сообщение Fuhrer » Пн май 10, 2010 1:32 pm

Qwertiy писал(а):А кто мешает изметять свойство DefaultButton в соответствии в активным переключателем? И подсветка будет.
Будет. Но это не типичное поведения DefaultButton в диалогах. Попытайтесь вспомнить хоть пару программ, где DefaultButton скачет в зависимости от положения курсора на RadioButton'е. Это просто нигде не встречается. Таким образом, Вы предлагаете довольно нетипичное поведение интерфейса, что уже значительно затруднит многих пользователей. Нет, конечно же, никто боятся ничего не будет. Просто значительная часть пользователей не будут нажимать Enter, так как им не будет очевидна его деятельность. Они будут тянутся к мыши, в чём и выражается неудобство диалога. Понимаете, диалог нужно проектировать так, чтобы он был понятен "среднему уму", а не только "продвинутым".
Qwertiy писал(а):По задумке Влево=Shift+Tab, Вправо=Tab. Но сочетания с Tab (теоретически) тоже должны поддерживаться.
Вот-вот-вот. Это уже второе нестандартное поведение элементов в диалоге. В отличии от первого, его несложно понять эмпирически, но всё же оно требует и привыкания в плане управления. То есть пользователю нужно переучить себя, что в одном отдельно взятом диалоге стрелки влево/вправо ведут себя не так, как во всех остальных диалогах. Это проблема, на самом деле.
Вы решили две инженерные задачи по проектированию одного диалога, а каждому пользователю добавили по проблеме - привыкнуть к нестандартному поведению этого диалога и запомнить, что только этот диалог ведёт себя так.
Qwertiy писал(а): Вы действительно считаете, что такую опцию следует помещать именно в диалог? А что будет, если разные файлы попадутся раньше, чем совпадающие?
Тогда в диалоге должна быть видна и возможность сравнить (по содержимому или только по внешним признакам), и возможность принять решение, не сравнивая. Не лишайте пользователя возможности принять решение тогда, когда его ещё не поздно принять. Не заставляйте его продумать всё заранее на 10 шагов вперёд.
Qwertiy писал(а):Это конечно хорошо, но даже я считаю такое количество настроек перебором... В таких случаях есть синхронизация... Наверное...
Вот о чём я и говорю. Нужно обдумать какая функциональность уместна в этом диалоге, а какую лучше оставить на синхронизацию. Я бы так и сделал. Поскольку с синхронизацией работают более "продвинутые" пользователи, им можно и посложнее диалог предложить. А для рутинной работы с файлами нужен максимально простой вариант. Ну или возможность выбора, конечно же.
Qwertiy писал(а):1. Если Вы добавляете кнопку, то как её выбрать? Если рассматривать переключение с помощью стрелок, то как Вы объясните, почему кнопка "Пропустить файл" выбирается с помощью стрелок влево/вправо, а кнопка "Пропустить все" только с помощью стрелок вверх/вниз при активной кнопке "Пропустить файл"? Догадываетесь, что пользователь подумает о таком диалоге? Если включить кнопку в последовательность кнопок, то это увеличит максимальное количество необходимых клавиш до 7 (как минимум), что уже много.
По-моему, если кнопки будут сгруппированы в группы так же, как и сейчас, то и поведение на стрелки будет так же логично (нелогично) как и сейчас (задумано). Даже более того: при радиобаттонах стрелки влево-вправо обязаны циклично выбирать соседние элементы в группе, а вот прыгание курсора по кнопкам как раз логично видеть в порядке "по смыслу". Короче, будь там кнопки - хуже не будет, имхо.
Qwertiy писал(а):2. Единство интерфейса. В каждой группе есть возможность выбрать вариант одного действия и подтвердить его.
С кнопками то же самое. Даже ещё "единственнее". Не будет диссонанса с кнопками группы "Другое".
Qwertiy писал(а):3. Возможность сохранения выбранного ранее варианта для каждого из основных действий в отдельности. Высока вероятность, что он же будет выбран снова. В таком случае, это экономит одно действие.
Увы, эта отмазка "не канает". Это работало бы, если бы у диалога была одна единственная DefaultButton. Тогда, после появления диалога пользователь не глядя нажимал бы Enter, зная, что выберется нужный пункт. А сейчас он не знает что нажмётся, ведь DefaultButton зависит от группы. Получается так: Пользователь нажал "Пропустить файл", а при следующем появлении окна, не думая, жмёт Enter, и получает.... "Заменить файл", или что-то другое из группы "Заменить".
Если же Вы сделаете запоминание элемента с последующим установлением на него курсора (так, чтобы и DefaultButton менялся), то такое и с кнопками сделать не проблема.
Qwertiy писал(а):И ещё, пользуясь Вашей логикой, можно все переключатели заменить на кнопки. И что тогда будет?
Переключатели нужны там, где:
1. Выбор переключателя устанавливает одно значение их множества.
2. Выбор с прошлого раза должен отобразится при следующем показе диалога.
3. Выбор переключателя не обязательно является последним действием в диалоге. То есть диалог не закрывается и пользователь может ещё наслаждаться (пользоваться) результатом своего выбора.
4. Даже после выбора пользователь должен видеть какой пункт он выбрал.
Как Вы понимаете, это не наш случай. В нашем варианте можно заменить все переключатели кнопками, сэкономив при этом пользователю половину даблклика, а программисту - несколько строк кода.

Вот типичный пример, где переключатели кнопками заменить нельзя:
Типичное применение переключателей.png
Здесь переключатели кнопками заменить нельзя.

Хух, я устал. Следующие сообщения откоментирую позже.

Аватара пользователя
Qwertiy
Охотник за багами
Сообщения: 1199
Зарегистрирован: Вс янв 31, 2010 12:12 am

Сообщение Qwertiy » Пн май 10, 2010 2:29 pm

Fuhrer писал(а):Но это не типичное поведения DefaultButton в диалогах. Попытайтесь вспомнить хоть пару программ, где DefaultButton скачет в зависимости от положения курсора на RadioButton'е.
Да, но если активна кнопка, то DefaultButton просто игнорируется и используется она. К тому же, на мой взгляд, очевидно, что Enter должен подтверждать выбранный пункт.
Fuhrer писал(а):Вот-вот-вот. Это уже второе нестандартное поведение элементов в диалоге.
На этом форуме уже просили поменять обработку клавиш в этом диалоге (https://forum.unrealcommander.net/viewto ... =261#p3357). Моя этому сообщению соответствует. Радиобаттоны расположены столбцом, поэтому перемещение по ним с помощью Вверх/Вниз. А группы - рядом, поэтому Tab и Вправо/влево. Что касается других диалогов, то я просил поменять обработку кнопок в диалоге удаления (https://forum.unrealcommander.net/viewto ... t=15#p5124), правда мне отказали. Так что я такое поведение считаю в первую очередь удобным и логичным, а не нестанлартным.
Fuhrer писал(а):
Qwertiy писал(а): Вы действительно считаете, что такую опцию следует помещать именно в диалог? А что будет, если разные файлы попадутся раньше, чем совпадающие?
Тогда в диалоге должна быть видна и возможность сравнить (по содержимому или только по внешним признакам), и возможность принять решение, не сравнивая. Не лишайте пользователя возможности принять решение тогда, когда его ещё не поздно принять. Не заставляйте его продумать всё заранее на 10 шагов вперёд.
Конструктивное предложение по добавлению пункта есть? Я не против, но вот хороших идей в этом плане у меня нет...
Fuhrer писал(а):А для рутинной работы с файлами нужен максимально простой вариант. Ну или возможность выбора, конечно же.
Хотите контекстное меню к кнопке "Заменить" вместо кнопки "Другие действия"?
Fuhrer писал(а):1. По-моему, если кнопки будут сгруппированы в группы так же, как и сейчас, то и поведение на стрелки будет так же логично (нелогично) как и сейчас (задумано).
2. С кнопками то же самое. Даже ещё "единственнее". Не будет диссонанса с кнопками группы "Другое".
В группе "Другое" расположены кнопки, т. к. это не разновидности одного действия. Кроме того, они должны выбираться обоими способами Вверх/Вниз и Вправо/Влево. Так что Ваша кнопочка создаст огромное противоречие, как единственная кнопка, которую нельзя выбрать с помощью Вверх/Вниз.
Fuhrer писал(а):Если же Вы сделаете запоминание элемента с последующим установлением на него курсора (так, чтобы и DefaultButton менялся), то такое и с кнопками сделать не проблема.
Именно так. Кстати, это есть и сейчас. Обратите внимание, что курсор стоит на последнем выбранном пункте и выбор всех переключателей сохранён. Про кнопки уже писал. К тому же фокус один, а групп с переключателями много. Здесь речь об индивидуальном сохранении по категориям, а не об одном последнем действии.
Fuhrer писал(а):
Qwertiy писал(а):И ещё, пользуясь Вашей логикой, можно все переключатели заменить на кнопки. И что тогда будет?
Переключатели нужны там, где:
Ну зачем же так? Понятно же, что я имел в виду именно в этом диалоге, а не все переключатели во всех программах.

Аватара пользователя
Fuhrer
Охотник за багами
Сообщения: 127
Зарегистрирован: Ср мар 03, 2010 12:51 am

Сообщение Fuhrer » Пн май 10, 2010 11:23 pm

Max Diesel писал(а):В связи с этим принципом реализована логика диалога замены в TC - каждой кнопке отдельное значение, я же использовал модифицированную логику (как мне кажется, более рациональную), при которой "общий множитель" (то есть пункт "для всех") был вынесен за скобки и его можно указать в виде флага нажатием средней/правой мыши, либо Shift/Ctrl.
Это важный момент Вы затронули. Насчёт рациональности. Я, может быть уже всем надоел, но хочу повторить: рациональнее диалог стал с точки зрения программиста, ведь использовано меньше элементов. С точки зрения пользователя он вряд ли стал рациональнее, ведь элементы получили новые, несвойственные им функции, которые приходится изучать (неизвестно откуда) и запоминать. Плох тот интерфейс, для изучения которого нужно читать отдельные мануалы. При этом интерфейс этот не даёт значительных преимуществ ни в удобстве, ни в скорости.
Max Diesel писал(а):Fuhrer предложил вариант без вынесения общего множителя но с волшебным превращением кнопок
По сути, у меня тот же общий множитель остался только для клавиатурного управления. Для мыши я действительно от него избавился как от несущего лишние неудобства. А "прыгание" кнопок можно убрать, от этого суть диалога и функциональность не изменится. Как вариант, можно кнопки оставлять исходного размера, просто менять их надписи. Такая практика вполне встречается, думаю она никого пугать не будет.
Max Diesel писал(а):определенно не хватает чтобы появились еще несколько "авторов диалогов", которые предложили бы...
А что же здесь плохого? Я понимаю, большинство идей - действительно шелуха, которая рано или поздно отлетит. Но будут ведь и умные мысли? Что Вы-то теряете? В худшем случае - все поймут, что нынешний вариант - наилучший, в лучшем - появятся его усовершенствованные версии, или что-то радикально иное и не менее хорошее. При минимуме затрат Вы получаете площадку генерации идей, которые можете использовать как по прямому назначению, так и в других местах программы (программ), если это уместно. Все в выигрыше - Вы, проект, и пользователи.

Насчёт сложностей в реализации... конечно, Вам виднее. Но мне, как и Qwertiy, кажется это вполне реальным.
Языковый баръер проблемой не считаю. Нет проблемы в том, что один диалог будет непереводим до тех пор, пока не станет востребованным на других языках. Та и вообще, идею этого плагина я рассматриваю всё-таки скорее как удобный полигон для разработки, чем как end-user функцию.

Аватара пользователя
Qwertiy
Охотник за багами
Сообщения: 1199
Зарегистрирован: Вс янв 31, 2010 12:12 am

Сообщение Qwertiy » Пн май 10, 2010 11:35 pm

Fuhrer писал(а):Та и вообще, идею этого плагина я рассматриваю всё-таки скорее как удобный полигон для разработки, чем как end-user функцию.
А я именно за использование. Каждому свой диалог - почему бы и нет? Особенно, если у диалогов будут и функциональные отличия (как сделать это возможным, я уже писал).

Аватара пользователя
Fuhrer
Охотник за багами
Сообщения: 127
Зарегистрирован: Ср мар 03, 2010 12:51 am

Re: Несколько предложений по юзабилити №2

Сообщение Fuhrer » Вт май 11, 2010 12:48 am

Qwertiy писал(а):PS: Пришла в голову мысль... Правда, Вы её не поддержите, да и я сам считаю, что этого в ближайшее время не надо... Но всё же скажу. Поддержка макросов в UC.
Да-да-да. Как-нибудь позже, наверное. Иногда это очень нужная вещь.
Qwertiy писал(а):К тому же, на мой взгляд, очевидно, что Enter должен подтверждать выбранный пункт.
Если хорошо подумать, то да. Беда в том, что хороший интерфейс должен быть понятен без хорошего обдумывания, интуитивно. Здесь этого нет.
Мне, например, очевидно, что где-то возле кнопки "Отмена" (которая срабатывает на нажатие Escape) должна находится кнопка, котрая срабатывает на нажатие Enter. Это стандартное поведение, оно встречается повсеместно. Только не найдя этой кнопки (предположительно, "ОК"), я начинаю обдумывать как оно работает, и если внимательно понаблюдаю, найду кнопку по умолчанию. Если я буду наблюдать дальше, я, может быть, обнаружу, что эта кнопка по умолчанию меняется. Но могу и не заметить. Вряд ли средний пользователь уделит так много времени на изучение такого непринципиального диалога. Ведь суть диалога - это просто ответ на просто вопрос, не более. Проще дотянутся до мыши, чем понять логику автора касательно клавиатуры.
Qwertiy писал(а):На этом форуме уже просили поменять обработку клавиш в этом диалоге (https://forum.unrealcommander.net/viewto ... =261#p3357). Моя этому сообщению соответствует.
Едва ли. Там просили сделать так, чтобы при нажатии вниз, курсор прыгал вниз. А у вас при нажатии влево курсор прыгнет вниз, а может и вверх. Это не так уж и критично, можно разобраться. Но требует от пользователя дополнительного изучения.
Qwertiy писал(а):Так что я такое поведение считаю в первую очередь удобным и логичным, а не нестанлартным.
Одно другому не мешает. Нестандартное - поэтому требует изучения. Логичное - поэтому изучение окупится удобством пользования. Хотя я всё же не считаю переключатели здесь правильным выбором в плане удобства.
Qwertiy писал(а):Конструктивное предложение по добавлению пункта есть? Я не против, но вот хороших идей в этом плане у меня нет...
У меня конструктивные предложения вообще редко бывают, я скорее просто треплюсь. Редко бывает настроение подумать. Когда будут идеи, я их обязательно озвучу.
Qwertiy писал(а):Хотите контекстное меню к кнопке "Заменить" вместо кнопки "Другие действия"?
Ага. Одна большая кнопка "Заменить" на весь диалог, и контекстное меню для остальных действий с древовидной структурой вариантов, которое (меню) вызывается тройным щелчком средней кнопкой мыши по бордюру этой кнопки. Чтобы случайно не нажимали. :lol:
Qwertiy писал(а):Так что Ваша кнопочка создаст огромное противоречие, как единственная кнопка, которую нельзя выбрать с помощью Вверх/Вниз.
Вы наверное, неправильно меня поняли. Я предлагаю просто заменить Ваши RadioButton`ы на простые Button`ы с теми же размерами и управлением курсором.
Qwertiy писал(а):Именно так. Кстати, это есть и сейчас. Обратите внимание, что курсор стоит на последнем выбранном пункте и выбор всех переключателей сохранён. Про кнопки уже писал. К тому же фокус один, а групп с переключателями много. Здесь речь об индивидуальном сохранении по категориям, а не об одном последнем действии.
Посмотрел. Действительно, так и есть. Скажу чесно, это жутковато - вглядываться каждый раз в кнопки, пытаясь разглядеть ту единственную, которая выделена жирным, которая и является "по умолчанию". Не могу представить, что это удобно. Впрочем, не попробовав, не поймёшь.
Qwertiy писал(а):
Fuhrer писал(а):
Qwertiy писал(а):И ещё, пользуясь Вашей логикой, можно все переключатели заменить на кнопки. И что тогда будет?
Переключатели нужны там, где:
Ну зачем же так? Понятно же, что я имел в виду именно в этом диалоге, а не все переключатели во всех программах.
Ой! А тут я Вас... одним словом misunderstood. Действительно, пользуясь моей логикой, я именно и советовал заменить все переключатели в Вашем диалоге на кнопки. Элементов поубавится, выбор станет легче, щелчки сэкономятся.
Qwertiy писал(а):
Fuhrer писал(а):Та и вообще, идею этого плагина я рассматриваю всё-таки скорее как удобный полигон для разработки, чем как end-user функцию.
А я именно за использование. Каждому свой диалог - почему бы и нет? Особенно, если у диалогов будут и функциональные отличия (как сделать это возможным, я уже писал).
Я думаю, затраты по поиску, установке, и настройке плагина не оправдают выигрыша по функциональности. Но пока об этом говорить рано - кто знает, может такие плагины смогли бы быть реально функциональны и полезны. Пока что для меня это способ развить интерфейс и, возможно, изучить необходимость внесение в него некоторых полезных функций.

Аватара пользователя
Qwertiy
Охотник за багами
Сообщения: 1199
Зарегистрирован: Вс янв 31, 2010 12:12 am

Сообщение Qwertiy » Вт май 11, 2010 2:02 am

Fuhrer писал(а):Мне, например, очевидно, что где-то возле кнопки "Отмена" (которая срабатывает на нажатие Escape) должна находится кнопка, котрая срабатывает на нажатие Enter.
А кто говорил что-то про Esc? Я вовсе не собирался её никак обрабатывать и, тем более, связывать с кнопкой "Отмена". Тут и рушатся Ваши доводы про Ok.
Fuhrer писал(а):
Qwertiy писал(а):Так что я такое поведение считаю в первую очередь удобным и логичным, а не нестанлартным.
Одно другому не мешает. Нестандартное - поэтому требует изучения. Логичное - поэтому изучение окупится удобством пользования. Хотя я всё же не считаю переключатели здесь правильным выбором в плане удобства.
Согласен, что не мешает. Но если окупится удобством, то нестандартное лучше. Хотя лично мне оно интуитивно понятно. Просьба про диалог удаления возникла именно из-за того, что он работал стандартно, а не так как я ждал. И я нажимал эту стрелку вниз, получал активную кнопку "Отмена", после чего задумывася, а что нажать дальше.
Fuhrer писал(а):
Qwertiy писал(а):Так что Ваша кнопочка создаст огромное противоречие, как единственная кнопка, которую нельзя выбрать с помощью Вверх/Вниз.
Вы наверное, неправильно меня поняли. Я предлагаю просто заменить Ваши RadioButton`ы на простые Button`ы с теми же размерами и управлением курсором.
Именно так я и понял. Прочитайте ещё раз про управление курсором... Кстати, стандартная высота кнопки 23, а переключателя 18 (кажется). Суть в том, что бордюр кнопки тоже занимает место, так что "с теми же размерами" не получится.
Fuhrer писал(а):Посмотрел. Действительно, так и есть. Скажу чесно, это жутковато - вглядываться каждый раз в кнопки, пытаясь разглядеть ту единственную, которая выделена жирным, которая и является "по умолчанию". Не могу представить, что это удобно. Впрочем, не попробовав, не поймёшь.
А мне кажется, вероятность одного и того же выбора велика, поэтому жмём Enter не читая, если нам надо то же действие, что и в прошлый раз. А если другое, то, скорее всего, хватит выбора кнопки и переключатели не понадобятся. Быстро и просто.
Fuhrer писал(а):Действительно, пользуясь моей логикой, я именно и советовал заменить все переключатели в Вашем диалоге на кнопки. Элементов поубавится, выбор станет легче, щелчки сэкономятся.
Только вот очевидность выбора с клавиатуры тоже поубавится причём в разы...
Fuhrer писал(а):Я думаю, затраты по поиску, установке, и настройке плагина не оправдают выигрыша по функциональности. Но пока об этом говорить рано - кто знает, может такие плагины смогли бы быть реально функциональны и полезны. Пока что для меня это способ развить интерфейс и, возможно, изучить необходимость внесение в него некоторых полезных функций.
Нет смысла поддерживать две версии программы - с плагинным диалогом и без него. А если будет возможность, то уж желающие ей воспользоваться найдутся...

Аватара пользователя
Fuhrer
Охотник за багами
Сообщения: 127
Зарегистрирован: Ср мар 03, 2010 12:51 am

Re: Несколько предложений по юзабилити №2

Сообщение Fuhrer » Вт май 11, 2010 1:48 pm

Qwertiy писал(а):А кто говорил что-то про Esc? Я вовсе не собирался её никак обрабатывать и, тем более, связывать с кнопкой "Отмена". Тут и рушатся Ваши доводы про Ok.
А никуда они не рушатся. Просто ещё и эта кнопка работает не так, как ожидается, поэтому требует отдельного привыкания.
Qwertiy писал(а):Просьба про диалог удаления возникла именно из-за того, что он работал стандартно, а не так как я ждал. И я нажимал эту стрелку вниз, получал активную кнопку "Отмена", после чего задумывася, а что нажать дальше.
Эта просьба была вполне правомерна и соответствовала интуитивному представлению того, как оно должно работать. И никакой особенной обработки там делать не нужно - просто курсор при создании диалога должен стоять на своём месте - на активном переключателе. Если это будет сделано - диалог будет работатьь как Вам надо безо всяких дополнительных обработок нажатий.
В Вашем же диалоге предусмотрено именно нестандартное поведение стрелок. Ладно, чего спорить. Будет плагин - сможем проверить. На словах можно чего угодно представлять, важно как оно в жизни будет.
Qwertiy писал(а):
Fuhrer писал(а):
Qwertiy писал(а):Так что Ваша кнопочка создаст огромное противоречие, как единственная кнопка, которую нельзя выбрать с помощью Вверх/Вниз.
Вы наверное, неправильно меня поняли. Я предлагаю просто заменить Ваши RadioButton`ы на простые Button`ы с теми же размерами и управлением курсором.
Именно так я и понял. Прочитайте ещё раз про управление курсором...
Где именно прочитать? Ни где не вижу доказательства того, что если переключатели заменить на кнопки, то что-то станет невозможно выбрать. Процитируйте, если не сложно.
Qwertiy писал(а):Кстати, стандартная высота кнопки 23, а переключателя 18 (кажется). Суть в том, что бордюр кнопки тоже занимает место, так что "с теми же размерами" не получится.
Ну так сделайте кнопки не стандартными! Как бы там ни было, легкость попадания мышью зависит от размеров элемента, а не его вида. А что касается размеров в высоту - может и не нужны такие низкие элементы? Может даже удобнее будет, если они будут выше?
Qwertiy писал(а):А мне кажется, вероятность одного и того же выбора велика, поэтому жмём Enter не читая, если нам надо то же действие, что и в прошлый раз.
Только вот помнить нужно.
Qwertiy писал(а):
Fuhrer писал(а):Действительно, пользуясь моей логикой, я именно и советовал заменить все переключатели в Вашем диалоге на кнопки. Элементов поубавится, выбор станет легче, щелчки сэкономятся.
Только вот очевидность выбора с клавиатуры тоже поубавится причём в разы...
Это почему же? Что в кнопках такого неочевидного?
Qwertiy писал(а):Нет смысла поддерживать две версии программы - с плагинным диалогом и без него.
Да, согласен. Я с этим молчаливо согласился ещё на прошлой странице. Но это при условии, что программа с поддержкой плагинов не будет значительно в чём-то уступать нынешней.

Аватара пользователя
Qwertiy
Охотник за багами
Сообщения: 1199
Зарегистрирован: Вс янв 31, 2010 12:12 am

Сообщение Qwertiy » Вт май 11, 2010 5:22 pm

Fuhrer писал(а):А никуда они не рушатся. Просто ещё и эта кнопка работает не так, как ожидается, поэтому требует отдельного привыкания.
Часть пользователей нажимает Esc или крестик по принципу "Я ничего не выбрал, значит ничего не случится", поэтому логично на Esc назначить "Пропустить все". Однако, это будет очень неожиданно для всех, кто думает перед тем, как что-то сделать. Поэтому я не считаю нужным обрабатывать нажатие Esc. Хотя, конечно, можно добавить настройку типа "Действие при нажатии Esc", но для того, чтобы ей кто-то воспользовался надо её запрашивать при установке или первом запуске, а это уже бред.
Fuhrer писал(а):И никакой особенной обработки там делать не нужно - просто курсор при создании диалога должен стоять на своём месте - на активном переключателе. Если это будет сделано - диалог будет работать как Вам надо безо всяких дополнительных обработок нажатий.
Для основного действия ваш вариант подойдёт, но вот для отмены... Предположим, я нажал Shift+Delete. Курсор стоит на втором переключателе. Я нажимаю Вправо и Enter... И Wipe-стирание вместо Отмены! Нет. Я просил именно разделить функционал клавиш, а не передвинуть точку отсчёта.
Fuhrer писал(а):Ну так сделайте кнопки не стандартными! Как бы там ни было, легкость попадания мышью зависит от размеров элемента, а не его вида. А что касается размеров в высоту - может и не нужны такие низкие элементы? Может даже удобнее будет, если они будут выше?
Нестандартные кнопки... Не ожидал - Вам же так хочется всего стандартного :).
Не поместятся просто. Или ещё диалог увеличить?
Fuhrer писал(а):
Qwertiy писал(а):А мне кажется, вероятность одного и того же выбора велика, поэтому жмём Enter не читая, если нам надо то же действие, что и в прошлый раз.
Только вот помнить нужно.
В течение одного сеанса - не проблема. Я же не предлагаю хранить настройки где-то в ini-файле (хотя над этим надо подумать). Обычная реализация с Hide() вместо Close(). Причём Hide() нужно ещё и для обращения к диалогу и сохранения в нём параметра "Для всех" (не флажка, а автовозврата последнего значения).
Fuhrer писал(а):Но это при условии, что программа с поддержкой плагинов не будет значительно в чём-то уступать нынешней.
А с чего ей вообще в чём-то уступать? Диалог вполне можно встроить в последнюю версию программы.
Fuhrer писал(а):
Qwertiy писал(а):
Fuhrer писал(а):Действительно, пользуясь моей логикой, я именно и советовал заменить все переключатели в Вашем диалоге на кнопки. Элементов поубавится, выбор станет легче, щелчки сэкономятся.
Только вот очевидность выбора с клавиатуры тоже поубавится причём в разы...
Это почему же? Что в кнопках такого неочевидного?
Fuhrer писал(а):
Qwertiy писал(а):Прочитайте ещё раз про управление курсором...
Где именно прочитать? Ни где не вижу доказательства того, что если переключатели заменить на кнопки, то что-то станет невозможно выбрать. Процитируйте, если не сложно.
Везде, но понемногу... Ладно.
1. Деление переключатель/кнопка и Вверх-Вниз/Влево-Вправо однозначно задаёт логику перемещения по элементам.
2. Если заменить все переключатели на кнопки, после чего все кнопки включить в последовательность выбора, то выбирать что либо с клавиатуры будет очень долго.
3. Если заменить все переключатели на кнопки, но сохранить принцип групп, то далеко не очевидно, какая из кнопок должна быть главной и выбираться в группе с помощью Влево-Вправо, а какая с помощью Вверх-Вниз.
4. Большое число переключателей привычно, поэтому человек сразу замечает их группировку. Немного позже - то, что под каждой группой переключателей (а точнее внизу неё) есть кнопка для подтверждения. А вот при 14 кнопках, расположенных в 3 столбца рамка вокруг некоторых из них в глаза уже не бросится и первая мысль "А что это? Что за хаос?", после чего придётся прочитать надписи на всех кнопках и понять то, что по сути пара кнопок из разных групп отличается первым словом, а внутри группы вторым. С какого раза Вы поняли, о чём я написал в этом предложении? Диалог с 14 кнопками вызовет не меньше раздумий.
5-а. Сохранение последнего выбранного пункта. Но это будет работать и при всех кнопках.
5-б. В каждой из групп сохраняется последний выбор переключателя. Например, если пользователь слишком осторожен и используюет только пункты "Заменить" и "Пропустить все", причём в зависимости от того, что конкретно он копирует, то ему будет достаточно выбирать между двумя кнопками "Заменить" и "Пропустить", не трогая при этом переключатели. Более реалистичный пример - Заменить/Пропустить или Заменить все/Пропустить все. В варианте с 14 кнопками эта удобная возможность теряется. А если попытаться её реализовать (что теоретически возмоно), то непредсказуемость перехода по стрелке сделает этот диалог абсолютно непригодным для выбора с клавиатуры (за исключением 5-а).
Надеюсь, что всё вспомнил - мне тоже искать лень...

Аватара пользователя
Fuhrer
Охотник за багами
Сообщения: 127
Зарегистрирован: Ср мар 03, 2010 12:51 am

Re: Несколько предложений по юзабилити №2

Сообщение Fuhrer » Ср май 12, 2010 10:07 am

Qwertiy писал(а):Часть пользователей нажимает Esc или крестик по принципу "Я ничего не выбрал, значит ничего не случится", поэтому логично на Esc назначить "Пропустить все".
Нет, ну на эту категорию блондинок ориентироваться вообще нельзя. Это ж так придётся доупрощаться до трёх кнопок. И те будут отличаться только цветом.
А вообще, если потакать такой логике - тогда вообще непонятно что делать. И прерывание операции, замена, и пропуск - все эти три варианта могут приводить к потере информации в определённых случаях. Как по мне, это недостаточно веский аргумент, чтобы отказывать остальным в удобном шорткате. Хотя и функция-то не шибко нужна, как по мне. Не часто есть смысл отменять операцию только из-за того, что там появились дублирующиеся имена.
Qwertiy писал(а):Я нажимаю Вправо и Enter... И Wipe-стирание вместо Отмены!
Ну, это уж Ваши проблемы. Вы понадеялись на нестандартную обработку и поплатились за это. Кто же виноват? У Вас были все исходные для принятия правильного решения: позиция курсора известна, действие Enter - тоже. В этом диалоге можно вообще не пускать курсор на кнопки: для подтверждения есть Enter, для отмены - Esc. Это стандартные хоткеи и никого они путать не будут.
Qwertiy писал(а):Не поместятся просто. Или ещё диалог увеличить?
Может и поместятся. Смотря какой вид кнопок для Вас приемлим.
Можно и кнопки.png
Можно и кнопки.png (6.74 КБ) 2516 просмотров
Qwertiy писал(а):В течение одного сеанса - не проблема.
Я уже заметил у Вас некоторые повышенные умственные и мыслительные способности. Поверьте, для некоторых - проблема. И это что, помнить сеансы? А если идёт две параллельных операции (открыто две программы)? Для меня, например, это будет проблемой. Я предпочитаю быть уверенным в поведении программы, чем надеяться на память и то, что это тот экземпляр, который я помню.
Qwertiy писал(а):3. Если заменить все переключатели на кнопки, но сохранить принцип групп, то далеко не очевидно, какая из кнопок должна быть главной и выбираться в группе с помощью Влево-Вправо, а какая с помощью Вверх-Вниз.
Вот это ключевой момент. В группе первой выбирается кнопка "Файл". Остальные случаи предполагают массовость, и после них диалог уже не появляется, потому и запоминать их нет смысла. Выбор кнопки - Вверх-Вниз, группы - Влево-Вправо. Что здесь отличается от Вашего варианта?
Qwertiy писал(а):4. Большое число переключателей привычно, поэтому человек сразу замечает их группировку...
Да, много кнопок пугает больше. И это их главный минус.
Qwertiy писал(а):5-б. В каждой из групп сохраняется последний выбор переключателя. Например, если пользователь слишком осторожен и используюет только пункты "Заменить" и "Пропустить все", причём в зависимости от того, что конкретно он копирует, то ему будет достаточно выбирать между двумя кнопками "Заменить" и "Пропустить", не трогая при этом переключатели.
Не буду спорить, но мне это кажется скверной идеей. Помнить весь сеанс последний выбор переключателя только для того, чтобы иметь шанс сэкономить одно нажатие следующий раз - это как-то странно. Но это, несомненно, обусловлено моими психофизическими особенностями, а другим может покажется нормальным. Жизнь покажет. Если эта жизнь будет.

Qwertiy, спасибо за потраченное время. Думаю, дальнейшая моя критика Вашего подхода не имеет смысла, так как я увидел существенное и принципиально её отличие от моих вариантов. Конечно же, всё моё мне кажется более логичным и удобным. Но и Ваше имеет свои особенности.

Предлагаю переключится на Макса. :) :twisted:

Аватара пользователя
Qwertiy
Охотник за багами
Сообщения: 1199
Зарегистрирован: Вс янв 31, 2010 12:12 am

Сообщение Qwertiy » Ср май 12, 2010 11:11 pm

Fuhrer писал(а):Как по мне, это недостаточно веский аргумент, чтобы отказывать остальным в удобном шорткате. Хотя и функция-то не шибко нужна, как по мне. Не часто есть смысл отменять операцию только из-за того, что там появились дублирующиеся имена.
Вообще-то, мне не кажется столь очевидным использование Esc в этом диалоге... А что касается Отмены, то тоже ей почти не пользуюсь. Точнее пользуюсь только когда забуду '\' (https://forum.unrealcommander.net/viewto ... t=30#p5776). Но в этом случае, даже при отмене 1 файл остаётся переименованным...
Fuhrer писал(а):Может и поместятся. Смотря какой вид кнопок для Вас приемлим.
Мне интересно, а как Вы сделали эту картинку? Почему-то мне кажется, что в реальности текст будет обрезан снизу при уменьшении кнопки...
Fuhrer писал(а):Я предпочитаю быть уверенным в поведении программы, чем надеяться на память и то, что это тот экземпляр, который я помню.
Добавить ещё один флажок в диалог - "Полная очистка диалога". И всё Ok.
Fuhrer писал(а):В группе первой выбирается кнопка "Файл". Остальные случаи предполагают массовость, и после них диалог уже не появляется, потому и запоминать их нет смысла. Выбор кнопки - Вверх-Вниз, группы - Влево-Вправо. Что здесь отличается от Вашего варианта?
Небольшая поправка: "после них диалог уже не появляется" в течении этой очереди. А если копировать 10 раз (из разных мест) и каждый раз выбирать "Заменить все"? Правда здесь возникает проблема параллельного копирования, но её легко решить. А может кто-то вообще не пользуется вариантом файл?
Fuhrer писал(а):Предлагаю переключится на Макса. :) :twisted:
Согласен. Итак, нам нужен плагинный принцип.

Реализация алгоритма коприрования примерно такая:

Множество возвращаемых диалогом значений:

Код: Выделить всё

Заменить, Пропустить, УдалитьИсточник, Переименовать, ПереименоватьИсточник, ПереименоватьПриёмник, ПереименоватьИсточникВ, ПереименоватьПриёмникВ, Дописать, Отмена
и всё что Вы захотите добавить из поддерживаемого в UC.

Класс диалога должен содержать:

Код: Выделить всё

реакция ShowDialog(string Источник, string Приёмник, bool Move);   // Запрос действия у диалога
string GetNewName(void);          // Для получения нового имени файла при возврате Переименовать*В
bool UseForAll(void);             // Установлен ли флаг Применить ко всем
bool ActiveCount(void);           // Сколько активных (не очищенных) версий диалога существует
void Clear(void);                 // Очистка параметров диалога
DialogClass *CreateClean(void);   // Создание нового диалога на основе данного
Обращаю внимание на комментарий "Запрос действия у диалога". Именно "у диалога", а не "у пользователя". Вызов метода означает только то, что UC получит от диалога ответ, но не то, что пользователь увидит диалог с запросом.

Начало копирования:

Код: Выделить всё

if(Dialog.ActiveCount()!=0) Dialog = Dialog.CreateClean();
При совпадении имён файлов:

Код: Выделить всё

switch(Dialog.ShowDialog(Source,Dest,MoveStatus))
Обработка возвращаемых значений очевидна. Кроме случая, когда возвращается вариант Переименовать*В с именем файла, который уже существует. Это на Ваше усмотрение... Хотя я бы ещё раз вызвал этот диалог - если он знает, что делает, то подтвердит сам без обращения к пользователю.

Завершение коприрования:

Код: Выделить всё

if(Dialog.ActiveCount()>1)
  Dialog.Close();
else
  Dialog.Clear();
Такая реализация позволяет диалогу использовать нестандартные возможности и быть не только шкурой диалога, но и полноценным дилогом с собственным, ничем не ограниченным, обработчиком различных вариантов.

Аватара пользователя
Qwertiy
Охотник за багами
Сообщения: 1199
Зарегистрирован: Вс янв 31, 2010 12:12 am

Сообщение Qwertiy » Ср май 12, 2010 11:56 pm

Qwertiy писал(а):

Код: Выделить всё

реакция ShowDialog(string Источник, string Приёмник, bool Move);   // Запрос действия у диалога
Небольшое исправление:

Код: Выделить всё

реакция ShowDialog(string Источник, string Приёмник, bool Move, int xparam=0);   // Запрос действия у диалога
Дополнительный параметр на случай, если Вы всё же расширите возможности UC... Пока нужно только для сохранения совместимости с диалогами в будущем...

Ответить