Активность элемента меню!
#1
Отправлено 31 марта 2005 - 12:16
В чем суть. При определенных действиях элемент меню становится либо активным, либо задизейбленым. Нужно продолжить выполнени скриптов только после того, как определенный элемент меню станет активным.
Инспектор меню вообще не видит (выводит только Window). Однако робот по нему может пройти и функция проверки Menu работает.
Прога написана на C#
#2
Отправлено 31 марта 2005 - 12:25
можете дотянуться до него при помощи SQAGetProperty?Народ, может кто знает как можно проверить активен ли элемент меню или нет?
В чем суть. При определенных действиях элемент меню становится либо активным, либо задизейбленым. Нужно продолжить выполнени скриптов только после того, как определенный элемент меню станет активным.
Инспектор меню вообще не видит (выводит только Window). Однако робот по нему может пройти и функция проверки Menu работает.
Прога написана на C#
если да, то пробовали ли вытягивать значение свойств disabled или enabled ?
#3
Отправлено 31 марта 2005 - 12:36
О SQAGetProperty я подумал первым делом. Но я не знаю как добраться до этих элементов - Инспектор Меню вообще не видит, а функция проверки меню обращается через окно,Mar 31 2005, 02:25 PM]
можете дотянуться до него при помощи SQAGetProperty?Народ, может кто знает как можно проверить активен ли элемент меню или нет?
В чем суть. При определенных действиях элемент меню становится либо активным, либо задизейбленым. Нужно продолжить выполнени скриптов только после того, как определенный элемент меню станет активным.
Инспектор меню вообще не видит (выводит только Window). Однако робот по нему может пройти и функция проверки Menu работает.
Прога написана на C#
если да, то пробовали ли вытягивать значение свойств disabled или enabled ?
Result = WindowVP (CompareMenu, "Caption=Window..." , "VP=MenuTest")
:(
Наданный момент извратнулся и сделал проверку через функцию проверки меню:
Result = WindowVP (CompareMenu, "Caption=Window..." , "VP=MenuTest")
Проверяется только 1 пункт.
но я считаю, что это криво и неправильно. Если кто сможет посоветовать более корректный способ, буду очень благодарен!
#4
Отправлено 31 марта 2005 - 16:32
Вы все сделали правильно. Хотя однозначно это кривое решение, но тут кривота не ваша, а Robot'а. SQAGetProperty с меню не работает, так что вы нашли единственно верный путь.Наданный момент извратнулся и сделал проверку через функцию проверки меню:
Result = WindowVP (CompareMenu, "Caption=Window..." , "VP=MenuTest")
Проверяется только 1 пункт.
но я считаю, что это криво и неправильно.
#5
Отправлено 04 апреля 2005 - 09:07
#6
Отправлено 04 апреля 2005 - 14:07
Robot при том, что он не умеет работать с меню через функцию SQAGetProperty. Дело не в том, что программа написана на C#. У меня такая же проблема была с программами на PowerBuilder. Robot просто не умеет этого делать, это один из его недостатков. Единственный способ добраться до пунктов меню - использовать WindowVP, что не очень удобно. А кодер здесь никаким боком не поможет.малопонятно мне, причем тут Робот - объект то не распознается.
#7
Отправлено 04 апреля 2005 - 14:51
Так ли это? :)
#8
Отправлено 04 апреля 2005 - 15:03
#9
Отправлено 05 апреля 2005 - 05:14
Про "горячие клавиши", так вроде называются шорткаты с действиям, которые "по хорошему" должны быть все доступны и через меню... тык вот, меню вовсе не обязательно должно быть всё снабжено "горячими клавишами" )
Признак плохого качества, это когда пользователь попеременно приходится хватается за клавиатуру и мышку. ИМХО, нужно думать не о окне, а о пользователе и соответственно юзабилити смотреть в ручном режиме, потом можно наклепать тест для регрессионных проверок, но не делать оценок качества пользовательского интерфейса по проценту пунктов меню снабжённых горячими клавишами или кнопочным эквивалентом.
#10
Отправлено 05 апреля 2005 - 06:25
Проверять же активность пункта меню путем его выбора, чтобы увидеть сработало или нет, это еще более криво, чем использовать WindowVP.
С этим согласна.
Признак плохого качества, это когда пользователь попеременно приходится хватается за клавиатуру и мышку. ИМХО, нужно думать не о окне, а о пользователе и соответственно юзабилити смотреть в ручном режиме, потом можно наклепать тест для регрессионных проверок, но не делать оценок качества пользовательского интерфейса по проценту пунктов меню снабжённых горячими клавишами или кнопочным эквивалентом.
Согласно универсальным стандартам эргономики, горячие клавиши всегда должны иметь место. Конечно, зависит от используемого софта, насколько актуальны эти шорткаты.
#11
Отправлено 05 апреля 2005 - 06:46
Согласно универсальным стандартам эргономики
А можно с этого момента поподробней, честно, где вы взяли эти стандарты (это не ГОСТы ;)) и где я могу их взять... дело в том что я опираюсь в тестировании интерфейса, на большой опыт работы как пользователя и длительный стаж как прогаммиста + элементарную логику, хотелось бы в этой области тоже увидеть что-то более строгое ;)
(кроме общих слов неизвестного автора, который передрал с тысячи подобных ресурсов информацию о том как должны именоваться пункты меню и в каком порядке обычно должны идти кнопки)
ЗЫ от себя замечу что даже в различных продуктах от майкрософта придерживаются разных верований в этом вопросе...
#12
Отправлено 05 апреля 2005 - 07:32
Для программистов объясняет многое о том как аккуратно писать правильные программы на, казалось бы, знакомом языке ;)
Си и Си++ Ален И. Голуб ВЕРЕВКА ДОСТАТОЧНОЙ ДЛИНЫ, ЧТОБЫ. ВЫСТРЕЛИТЬ СЕБЕ В НОГУ
Это пример авторитетного мнения в отличие от вышеупомянутых сайтов, в этой книге есть немного о правилах хорошего тона в пользовательском интерфейсе...
#13
Отправлено 07 апреля 2005 - 11:46
Если наличие шорткат не было бы обязательным условием стандарта эргономики, то их не было бы вообще.
Клавиатура - основное устройство, а мышь - вспомогательное. И поэтому изначально шорткаты являются необходимыми и удобными в эксплуатации.
#14
Отправлено 07 апреля 2005 - 17:49
а шоткаты немного уменьшают читабельность меню... так что должен быть какой-то разумный баланс ;) но это моё ИМХО... не обоснованное ничем кроме...
а вот про эргономику ПО где конкретно, я уже согласен на средне авторитетные источники, ещё немного и в яндексе запрос наберу ;)
#15
Отправлено 07 апреля 2005 - 19:45
Согласно универсальным стандартам эргономики
А можно с этого момента поподробней, честно, где вы взяли эти стандарты (это не ГОСТы ;)) и где я могу их взять... дело в том что я опираюсь в тестировании интерфейса, на большой опыт работы как пользователя и длительный стаж как прогаммиста + элементарную логику, хотелось бы в этой области тоже увидеть что-то более строгое ;)
(кроме общих слов неизвестного автора, который передрал с тысячи подобных ресурсов информацию о том как должны именоваться пункты меню и в каком порядке обычно должны идти кнопки)
ЗЫ от себя замечу что даже в различных продуктах от майкрософта придерживаются разных верований в этом вопросе...
Два наиболее авторитетных источника в данном вопросе -- это Apple и Microsoft (Мелкомягкие основывали свои рекоменации на Яблочных, но довольно далеко от них отошли в силу разных причин, таких как, например, многокнопочность мышей).
Итак, по существу:
1. http://developer.app...ines/index.html
2. http://msdn.microsof...uidesigndev.asp
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#16
Отправлено 08 апреля 2005 - 19:41
Bakhtina, а вы читали советы от майкрософт? я в процессе и пока не нашёл ничего подтверждающего ваше утверждение, кое-что в мою пользу, но статья от 94 года ;) )
многое конечно старова-то, но вы прмеры посмотрите, можно и просто тогда в ПО от майкрософт глянуть, раз мы согласились брать его за эталон (хотя, как я говорил выше, они не постоянны :) )
+Дошёл до довольно свежей статьи 2002 год.
MSDN Home > MSDN Library > Win32 and COM Development > User Interface > Accessibility > "Guidelines for Keyboard User Interface Design",
Я не нашёл упоминания о том что все пункты меню нужно ошоткачивать ;)
рекомендуется, как я и считал разумным для себя, шоткатить частоиспользуемые сочитания, указывается полезность возможности задавать свои кнопки быстрого вызова + необходимо обеспечивать доступность работы с клавиатуры (напоминаю в меню мы должны заходить по нажатию АЛТа! )
#17
Отправлено 13 апреля 2005 - 07:22
Народ, может кто знает как можно проверить активен ли элемент меню или нет?
В чем суть. При определенных действиях элемент меню становится либо активным, либо задизейбленым. Нужно продолжить выполнени скриптов только после того, как определенный элемент меню станет активным.
Инспектор меню вообще не видит (выводит только Window). Однако робот по нему может пройти и функция проверки Menu работает.
Прога написана на C#
Declare Function GetMenu Lib "user32" Alias "GetMenu" (ByVal hwnd As Long) As Long
Declare Function GetMenuState Lib "user32.dll" (ByVal hMenu As Long, _
ByVal wID As Long, _
ByVal wFlags As Long) As Long
Declare Function GetSubMenu Lib "user32" (ByVal hMenu As Long, _
ByVal nPos As Long) As Long
Const MF_DISABLED = &H2&
Const MF_GRAYED = &H1&
Const MF_BYPOSITION = &H400&
Sub Main
Dim iResult As Integer
Dim lhWnd As Long
Dim lMenu As Long
Dim lSubMenu As Long
Dim lResult As Long
Window SetContext, "Caption=Безымянный - Блокнот", ""
'получаем хэндл окна
iResult = SQAGetProperty("\;Type=Window;Caption=Безымянный - Блокнот","hWnd",lhWnd)
'получаем идентификатор меню
lMenu = GetMenu(lhWnd)
'получаем идентификатор подменю "Правка"
lSubMenu = GetSubMenu(lMenu,1)
'получаем состояние пункта меню "Отменить"
lResult = GetMenuState(lSubMenu,0,MF_BYPOSITION)
'проверяем доступно ли меню
If (lResult And MF_DISABLED) Or (lResult And MF_GRAYED) Then
'пункт меню задизэйблен
SQAConsoleWrite "Disabled"
Else
'пункт меню доступен
SQAConsoleWrite "Enabled"
End If 'lResult And MF_DISABLED
End Sub
#18
Отправлено 13 апреля 2005 - 07:56
Да, Вы абсолютно правы.Я не нашёл упоминания о том что все пункты меню нужно ошоткачивать ;)
рекомендуется, как я и считал разумным для себя, шоткатить частоиспользуемые сочитания, указывается полезность возможности задавать свои кнопки быстрого вызова + необходимо обеспечивать доступность работы с клавиатуры (напоминаю в меню мы должны заходить по нажатию АЛТа! )
Во-первых, всё это Майкрософтовское хозяйство -- рекомендации. Требований, действительно, никаких нет. Хотите -- следуйте, не хотите -- не следуйте. Во-вторых, сами они тоже не всегда следуют своим же рекомендациям. Впрочем, ценность рекоменаций от этого не падает.
Что касается "замшелости" -- там есть довольно таки свежая (2004) онлайн-книга "Official Guidelines for User Interface Developers and Designers" -- http://msdn.microsof...tml/welcome.asp
Кстати, в главе "Fundamentals of Designing User Interaction - Getting Started" этой книги имеется раздел "Checklist for a Good Interface", в котором один из пунктов звучит так: "Your application supports the standard set of keyboard shortcuts, where applicable."
Но шорткаты для быстрого досупа -- это не главное, тут Вы совершенно правы. Это просто фишечки и фенечки. И в том же чеклисте есть такой пункт: "Your application is keyboard accessible." Это действительно важно!
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#19
Отправлено 13 апреля 2005 - 08:04
#20
Отправлено 13 апреля 2005 - 13:49
как приложение может стать клавиатурно доступным без шорткатов, или я чего-то не догоняю?Но шорткаты для быстрого досупа -- это не главное, тут Вы совершенно правы. Это просто фишечки и фенечки. И в том же чеклисте есть такой пункт: "Your application is keyboard accessible." Это действительно важно!
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных