Сообщений в теме: 22

[DmitryGos]

Народ, может кто знает как можно проверить активен ли элемент меню или нет?
В чем суть. При определенных действиях элемент меню становится либо активным, либо задизейбленым. Нужно продолжить выполнени скриптов только после того, как определенный элемент меню станет активным.
Инспектор меню вообще не видит (выводит только Window). Однако робот по нему может пройти и функция проверки Menu работает.
Прога написана на C#

[Pet[EG]]

Народ, может кто знает как можно проверить активен ли элемент меню или нет?
В чем суть. При определенных действиях элемент меню становится либо активным, либо задизейбленым. Нужно продолжить выполнени скриптов только после того, как определенный элемент меню станет активным.
Инспектор меню вообще не видит (выводит только Window). Однако робот по нему может пройти и функция проверки Menu работает.
Прога написана на C#

можете дотянуться до него при помощи SQAGetProperty?
если да, то пробовали ли вытягивать значение свойств disabled или enabled ?

[DmitryGos]

,Mar 31 2005, 02:25 PM]

Народ, может кто знает как можно проверить активен ли элемент меню или нет?
В чем суть. При определенных действиях элемент меню становится либо активным, либо задизейбленым. Нужно продолжить выполнени скриптов только после того, как определенный элемент меню станет активным.
Инспектор меню вообще не видит (выводит только Window). Однако робот по нему может пройти и функция проверки Menu работает.
Прога написана на C#

можете дотянуться до него при помощи SQAGetProperty?
если да, то пробовали ли вытягивать значение свойств disabled или enabled ?

О SQAGetProperty я подумал первым делом. Но я не знаю как добраться до этих элементов - Инспектор Меню вообще не видит, а функция проверки меню обращается через окно
Result = WindowVP (CompareMenu, "Caption=Window..." , "VP=MenuTest")
:(

Наданный момент извратнулся и сделал проверку через функцию проверки меню:
Result = WindowVP (CompareMenu, "Caption=Window..." , "VP=MenuTest")
Проверяется только 1 пункт.
но я считаю, что это криво и неправильно. Если кто сможет посоветовать более корректный способ, буду очень благодарен!

[Dmitry_NJ]

Наданный момент извратнулся и сделал проверку через функцию проверки меню:
Result = WindowVP (CompareMenu, "Caption=Window..." , "VP=MenuTest")
Проверяется только 1 пункт.
но я считаю, что это криво и неправильно.

Вы все сделали правильно. Хотя однозначно это кривое решение, но тут кривота не ваша, а Robot'а. SQAGetProperty с меню не работает, так что вы нашли единственно верный путь.

[Bakhtina]

малопонятно мне, причем тут Робот - объект то не распознается. На нет и суда нет. Можно попросить кодера присвоить сей объект какому-нибудь классу, либо оставить все как есть. Верно?

[Dmitry_NJ]

малопонятно мне, причем тут Робот - объект то не распознается.

Robot при том, что он не умеет работать с меню через функцию SQAGetProperty. Дело не в том, что программа написана на C#. У меня такая же проблема была с программами на PowerBuilder. Robot просто не умеет этого делать, это один из его недостатков. Единственный способ добраться до пунктов меню - использовать WindowVP, что не очень удобно. А кодер здесь никаким боком не поможет.

[Bakhtina]

спасибо за быстрый ответ, но речь шла не об инспекторе, а о кнопке меню. Грамотно, когда кнопки меню можно вызывать еще и клавиатурно (CTRL* , ALT*), а если же это невозможно, то это уже признак плохого качества. Если команда кнопки клавиатурно не выполняется, то вероятно, что она совсем не имеет свойств.

Так ли это? :)

[Dmitry_NJ]

Я не очень понимаю, что вы имеете в виду под "кнопкой меню". В моем понятии кнопка (button) и элемент (item) это разные вещи. Если вы имеете ввиду кнопки на toolbar, то опять же они просто дублируют menu items, на которые short cuts и вешаются. И насколько я могу судить из первоначального поста, стоит проблема определить состояние элемента меню - enabled/disabled. Речь не идет о выборе пункта меню будь то мышкой, или какими-то short cuts (Ctrl+/Alt+). Проверять же активность пункта меню путем его выбора, чтобы увидеть сработало или нет, это еще более криво, чем использовать WindowVP.

[Volant]

Нет ничего невозможного, виндуз АПИ спасёт всех или хотя бы читающую половину :)

Про "горячие клавиши", так вроде называются шорткаты с действиям, которые "по хорошему" должны быть все доступны и через меню... тык вот, меню вовсе не обязательно должно быть всё снабжено "горячими клавишами" )

Признак плохого качества, это когда пользователь попеременно приходится хватается за клавиатуру и мышку. ИМХО, нужно думать не о окне, а о пользователе и соответственно юзабилити смотреть в ручном режиме, потом можно наклепать тест для регрессионных проверок, но не делать оценок качества пользовательского интерфейса по проценту пунктов меню снабжённых горячими клавишами или кнопочным эквивалентом.

[Bakhtina]

Проверять же активность пункта меню путем его выбора, чтобы увидеть сработало или нет, это еще более криво, чем использовать WindowVP.

С этим согласна.

Признак плохого качества, это когда пользователь попеременно приходится хватается за клавиатуру и мышку. ИМХО, нужно думать не о окне, а о пользователе и соответственно юзабилити смотреть в ручном режиме, потом можно наклепать тест для регрессионных проверок, но не делать оценок качества пользовательского интерфейса по проценту пунктов меню снабжённых горячими клавишами или кнопочным эквивалентом.

Согласно универсальным стандартам эргономики, горячие клавиши всегда должны иметь место. Конечно, зависит от используемого софта, насколько актуальны эти шорткаты.

[Volant]

Согласно универсальным стандартам эргономики

А можно с этого момента поподробней, честно, где вы взяли эти стандарты (это не ГОСТы ;)) и где я могу их взять... дело в том что я опираюсь в тестировании интерфейса, на большой опыт работы как пользователя и длительный стаж как прогаммиста + элементарную логику, хотелось бы в этой области тоже увидеть что-то более строгое ;)

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

ЗЫ от себя замечу что даже в различных продуктах от майкрософта придерживаются разных верований в этом вопросе...

[Volant]

Кстати вспомнил. Серьёзная книга в т.ч. о качестве, но для программистов и уже немного устаревшая, хотя некоторые разделы будут полезны и понятны и тестерам в зависимости от квалификации ;)

Для программистов объясняет многое о том как аккуратно писать правильные программы на, казалось бы, знакомом языке ;)

Си и Си++ Ален И. Голуб ВЕРЕВКА ДОСТАТОЧНОЙ ДЛИНЫ, ЧТОБЫ. ВЫСТРЕЛИТЬ СЕБЕ В НОГУ

Это пример авторитетного мнения в отличие от вышеупомянутых сайтов, в этой книге есть немного о правилах хорошего тона в пользовательском интерфейсе...

[Bakhtina]

Volant, если у вас действительно длительный стаж программиста, то вы согласитесь со мной, что сами постоянно работаете с шорткатами. И что мышкой редко пользуетесь.
Если наличие шорткат не было бы обязательным условием стандарта эргономики, то их не было бы вообще.
Клавиатура - основное устройство, а мышь - вспомогательное. И поэтому изначально шорткаты являются необходимыми и удобными в эксплуатации.

[Volant]

Шоткаты зачастую допускают в сочетаниях дополнительную клавиатуру, а так в виндузе предусмотрена возможность добраться до любого пункта меню в два-три тычка по кнопкам (проверьте кстати не наглючили ли с ней ваши программисты это будет много полезней:)...
а шоткаты немного уменьшают читабельность меню... так что должен быть какой-то разумный баланс ;) но это моё ИМХО... не обоснованное ничем кроме...
а вот про эргономику ПО где конкретно, я уже согласен на средне авторитетные источники, ещё немного и в яндексе запрос наберу ;)

[barancev]

Согласно универсальным стандартам эргономики

А можно с этого момента поподробней, честно, где вы взяли эти стандарты (это не ГОСТы ;)) и где я могу их взять... дело в том что я опираюсь в тестировании интерфейса, на большой опыт работы как пользователя и длительный стаж как прогаммиста + элементарную логику, хотелось бы в этой области тоже увидеть что-то более строгое ;)

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

ЗЫ от себя замечу что даже в различных продуктах от майкрософта придерживаются разных верований в этом вопросе...

Два наиболее авторитетных источника в данном вопросе -- это Apple и Microsoft (Мелкомягкие основывали свои рекоменации на Яблочных, но довольно далеко от них отошли в силу разных причин, таких как, например, многокнопочность мышей).

Итак, по существу:

1. http://developer.app...ines/index.html
2. http://msdn.microsof...uidesigndev.asp

[Volant]

Только сейчас заметил, что ссылки выложил не Bakhtina, а barancev, за что ему большое спасибо :)

Bakhtina, а вы читали советы от майкрософт? я в процессе и пока не нашёл ничего подтверждающего ваше утверждение, кое-что в мою пользу, но статья от 94 года ;) )
многое конечно старова-то, но вы прмеры посмотрите, можно и просто тогда в ПО от майкрософт глянуть, раз мы согласились брать его за эталон (хотя, как я говорил выше, они не постоянны :) )

+Дошёл до довольно свежей статьи 2002 год.
MSDN Home > MSDN Library > Win32 and COM Development > User Interface > Accessibility > "Guidelines for Keyboard User Interface Design",

Я не нашёл упоминания о том что все пункты меню нужно ошоткачивать ;)
рекомендуется, как я и считал разумным для себя, шоткатить частоиспользуемые сочитания, указывается полезность возможности задавать свои кнопки быстрого вызова + необходимо обеспечивать доступность работы с клавиатуры (напоминаю в меню мы должны заходить по нажатию АЛТа! )

[SCAT]

Народ, может кто знает как можно проверить активен ли элемент меню или нет?
В чем суть. При определенных действиях элемент меню становится либо активным, либо задизейбленым. Нужно продолжить выполнени скриптов только после того, как определенный элемент меню станет активным.
Инспектор меню вообще не видит (выводит только 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

[barancev]

Я не нашёл упоминания о том что все пункты меню нужно ошоткачивать ;)
рекомендуется, как я и считал разумным для себя, шоткатить частоиспользуемые сочитания, указывается полезность возможности задавать свои кнопки быстрого вызова + необходимо обеспечивать доступность работы с клавиатуры (напоминаю в меню мы должны заходить по нажатию АЛТа! )

Да, Вы абсолютно правы.

Во-первых, всё это Майкрософтовское хозяйство -- рекомендации. Требований, действительно, никаких нет. Хотите -- следуйте, не хотите -- не следуйте. Во-вторых, сами они тоже не всегда следуют своим же рекомендациям. Впрочем, ценность рекоменаций от этого не падает.

Что касается "замшелости" -- там есть довольно таки свежая (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." Это действительно важно!

[Volant]

Ага, тоже уже нашёл этот чеклист и выдал его на прочтение определённой группе товарищей ;)

[Bakhtina]

Но шорткаты для быстрого досупа -- это не главное, тут Вы совершенно правы. Это просто фишечки и фенечки. И в том же чеклисте есть такой пункт: "Your application is keyboard accessible." Это действительно важно!

как приложение может стать клавиатурно доступным без шорткатов, или я чего-то не догоняю?