[JFWRus] Re: Переключение NUMLOCK

Здравствуйте, Руслан.

Большое спасибо за разъяснения, идею и код. Правда я не понял вот эту
строку:

Тут возможно какое-то недоразумение. Зачем менять два слэша на
четыре? Хотя, возможно я чего-то недопонял. Ничего,разберусь.
Спасибо что подтолкнули меня к AutoIt. Язык показался мне
интересным. Буду с ним знакомиться.

Доброго времени суток, Шабанов Юрий.

Из сообщения от 02.03.2009 5:58:

StringReplaceSubstrings (GetUserSettingsDirectory (), "\\","\\\\")

Зачем менять два слэша на четыре?

На самом деле недоразумение есть, но не в этом :).
Строковые выражения, записанные в коде в виде "\<символ>"
при выполнении заменяется на "<символ>",
где <символ> - единичный символ.
Таким образом строка кода, приведенная выше при выполнении будет заменять
"\" на "\\".
Вот тут то и недоразумение,
поскольку на самом деле это замена здесь совершенноне нужна.
достаточно написать:
Run ("\""+GetUserSettingsDirectory()+"/NumLockOn.au3\"")

С уважением, Руслан Усачев

RUsach***@t*****.by

***
Это сообщение No 8252
было разослано для 468 участников дискуссионного листа
[JFWRus] Re[2]: Переключение NUMLOCK

Здравствуйте,

Почему же???
Берём MSDN и изучаем следующие сообщения WM_KEYUP и WM_KEYDOWN. После этого посылаем
соответствующее сообщение через конструкцию скриптового языка челюстей SendMessage
или PostMessage.
Всё - финита ля комедия.

Использование смеси скриптовых языков - это очень, очень плохой стиль по многим
причинам. Вот сходу парочка:
1. У человека может не быть соответствующего интерпритатора.
2. Человек может не знать другого языка или не хотеть его знать. В таком примере
это не принципиально, а в примере чуть больше становится важно. Не представляете
как хочется помянуть всех родителей и родственников какого-нибудь автора смешавшего
в скрипте несколько языков.
Лучше уж целиком написать его на том же AutoIt или AutoHotKey или даже на JScript,
кому что милее.

До свидания.

***
Это сообщение No 8261
было разослано для 468 участников дискуссионного листа
[JFWRus] Re[2]: Переключение NUMLOCK

Доброго времени суток, Serge Tumanyan.

Из сообщения от 02.03.2009 20:43:

Взяли, изучили, послали - финита ля комедия.
Если посылаем скан-код ASCII-символа, то естественно все OK!
А приложению типа NotePad как-то начхать на посланный ему NumLock, imho.
Для этих целей в WinAPI существует функция SetKeyboardState,
аналога которой в скриптовом языке Jaws в отличие от GetKeyboardState нет.
А сообщения wm_KeyDown и wm_KeyUp не предназначены
для изменения состояния режимных клавиш, опять же imho.

Let hWnd = GetCurrentWindow ()

postMessage (hWnd, 256, 144, 0)

Delay (3)

postMessage (hWnd, 257, 144, 0)

Если вместо 144 (NumLock) посылать 65 (a), то OK, а так - фигвам...
Буду благодарен за конструктивную критику,
указание на возможные ошибки и
и за пример работающего кода.

С уважением, Руслан Усачев
RUsach***@t*****.by

***
Это сообщение No 8262
было разослано для 467 участников дискуссионного листа
[JFWRus] Re[3]: Переключение NUMLOCK

Здравствуйте,

посланный ему NumLock, imho.

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

До свидания.

***
Это сообщение No 8266
было разослано для 468 участников дискуссионного листа
[JFWRus] Re[4]: Переключение NUMLOCK

Приветствую всех.
Руслан пишет:

Это верно. Обработка NumLock выполняется системой еще до того, как сообщение
WM_KEYDOWN с кодом NumLock помещается в очередь сообщений приложения (а реальное
нажатие NumLock обрабатывается вообще на уровне BIOS).

[...]

TypeKey("NumLock")
или
SimulateKey ("NumLock")

Ну и магическое заклинание к этому коду:
1. Пуск -> Все программы -> JAWS 8.0 -> Файлы JAWS -> Общие настройки.
2. Открыть файл keycodes.ini.
3. Найти строку:
NumLock=197|144|1
и закомментировать ее (поставить в начале строки точку с запятой). Затем поместить
строку:
NumLock=69|0
4. Сохранить файл.
После этого вышеуказанные строки будут работать.

Есть вариант, не требующий изменения файлов JAWS:
var

object o

let o= CreateObject("WScript.Shell")

o.SendKeys("{NUMLOCK}")

Успехов. Анатолий.

***
Это сообщение No 8268
было разослано для 468 участников дискуссионного листа
[JFWRus] Re[4]: Переключение NUMLOCK

Здравствуйте,

Ну боюсь это Вы несколько погорячились. Много раз уже обсуждался вопрос используют
ли форточки БИОС или нет и однозначного отвера на это нет. Есть аргументы как
за, так и против. Лично по моему мнению это врядли по причине того, что огромное
число кусков БИОСА попросту нереентерабельны. NumLock вообще-то посылает обычный
скан код, можете проверить под ДОСом, значение я не помню естественно (может
45?), а вся его уникальность заключается с точки зрения любой операционной системы
именно в той самой пресловутой лампочке, не более.

До свидания.

***
Это сообщение No 8270
было разослано для 469 участников дискуссионного листа
[JFWRus] Re[5]: Переключение NUMLOCK

Приветствую всех.

ли форточки БИОС или нет
[...]

По моему мнению достаточно поисследовать пару-тройку функциональных драйверов
Windows, чтобы убедиться в том, что они используют вызовы Ke386CallBios() для
обращения к ROM BIOS.

Скан-код посылает установленный на клавиатуре микроконтроллер для любой клавиши,
т.к. он, по большому счету, не имеет представления об их функциональном назначении.

Это можно сделать и под Windows. В сообщении WM_KEYDOWN в параметре lParam бит
с 16 по 23 содержат скан-код нажатой клавиши.

Успехов. Анатолий.

***
Это сообщение No 8273
было разослано для 469 участников дискуссионного листа
[JFWRus] Re[6]: Переключение NUMLOCK

Здравствуйте,

Возможно кто-то из производителей это и использует, я не берусь утверждать, что
это не так, даже возможно где-то такими вещами страдает и Майкрософт, не исключаю,
хотя это из ряда вон выходящий плохой стиль и я в этом опять же сильно сомневаюсь,
но не думаю, что так сделано в драйвере клавиатуры. Ещё во времена ДОСа я довольно
не плохо знал общую структуру строения обработки клавиш в БИОСЕ и даже не один
раз и не на одном БИОСе изучал обработку клавиатуры. То, что там код БИОСа не
реентерабельный, думаю Вы врядли будете дисскутировать, не говоря уже о том,
что поддержки многих видов клавиатур илди клавиатуро-подобных устройств, типа
видео-мышей и USB-клавиатур просто отсутствует в БИОСе, что кстати до некоторой
степени сдерживает переход полностью на USB клавиатуры - не зайдёшь в setup,
если это не специальная хитрая мать. Очень мне интересно послушать как же по
Вашему мнению обрабатывается клавиша NumLock на USB клавиатуре на уровне БИОСА,
на матери на которой нет поддержки USB клавиатур в БИОСе, а то, что она обрабатывается
я могу Вам гарантировать, видимо хитрые форточки патчат БИОС, прошивая поддержку
USB клавиатур прямо на лету во флеш-память, благо теперь это можно, а на старых
матерях, где стоит ещё не флеш память, просто перепаивают микросхему память простым
паяльником, разве не так?.. Запускаете Вы установку форточек, а они обнаружив,
что у Вас USB клавиатура, и не флеш БИОС вылезают из компьютера и быстро так
открутив крышку системника перепаивают микросхему на специально заготовленную
фирмой Майкрософт, причём делают это так быстро, что Вы даже и ничего заметить
не успеваете, и думаете, что ничего не произошло, а форточки после этого с чувством
выполненного долга обрабатывают нажатия клавиши NumLock на уровне БИОСа - хороша
картинка, разве не так, а главное правдоподобна?

бит

Который помещается туда драйвером клавиатуры, который в свою очередь теоретически
может поместить туда любую информацию. Например, изобразите-ка мне получение
двойного скан-кода от расширенной клавиатуры - ничего более получения установленного
бита 24 Вы от драйвера клавиатуры не добьётесь, а реально при нажатии клавиш
дополнительных блоков клавиатуры микроконтроллер клавиатуры начиная с PC AT посылает
два скан-кода. На этом кстати основана и работа всякого рода клавиатуро-подобных
устройств, типа тех же видео-мышей и прочих извращений. Там как Вы понимаете
такими скан-кодами как в клавиатуре даже и не пахнет, а в сообщениях Вы получаете
как раз скан-коды обычной клавиатуры, помещаемые туда драйвером. Так что предложенный
Вами способ не является сколько-нибудь доказательным, в отличие от проверки из-под
ДОСа, который ничего особо не трогает и можно перехватив прерывание клавиатуры
(не помню сейчас - 12 что-ли?) и преспокойненько читать порт клавиатуры напрямую
получая посылаемые скан-коды.

Челюсти, кстати в функцию KeyPressedEvent получают именно обработанные скан-коды
клавиатуры, что и наводит меня на подозрение, что нажатие клавиши NumLock проходит
через систему сообщений форточек, а значит его можно съемулировать, поскольку
только что проверил, NumLock посылает скан-код в KeyPressedEvent.

О сколько нам открытий чудных готовят просвящения дух и опыт сын ошибок трудных...
(с) Пушкин Александр Сергеевич...

До свидания.

***
Это сообщение No 8275
было разослано для 469 участников дискуссионного листа
[JFWRus] Re[7]: Переключение NUMLOCK

Приветствую всех.

Ну прежде вы именно это исключали. Иными словами, в предыдущем сообщении вы рассуждали
о том, о чем не имеете представления?

В драйвере клавиатуры этого нет (см. ниже).

Сам себя не похвалишь -- никто не похвалит. Верно?
А BIOS'ы с тех пор сильно изменились...

The PC 97 standard requires that a computer's
BIOS must detect and work with USB HID class keyboards that are designed to be
used during the boot process.
Несложно сообразить, что эта спецификация от 1997 года.
В нынешних BIOS включить что-нибудь типа USB Keyboard support,USB Legacy Support,
USB Keyboard via.., etc. и поддержка USB-клавиатуры будет осуществляться BIOS'ом.
В зависимости от BIOS, возможно, еще кое-что придется включить/отключить в настройках.
Разумеется, чем более "свежее" железо, тем меньше проблем с этой поддержкой.
Известны проблемы на этапе загрузки Windows, когда с помощью USB-клавиатуры нельзя
выбрать пункт в загрузочном меню, но не BIOS в этом виновата.

Ну, в общем случае, вы мыслите в правильном направлении, только для этого существует
известный и более цивилизованный способ -- заменить обработчик прерывания на
свой (что и делает Windows).
Верно лишь то, что выражение "на уровне BIOS" было неудачным (двусмысленным),
а подразумевалось, что ОС работает с аппаратурой на том уровне, на котором изначально
работает BIOS (то есть спортами контроллера клавиатуры) -- лень было разжевывать.
Но сути дела это не меняет, а суть дела в том, что переключение состояния NumLock
посылкой сообщения WM_KEYDOWN пользовательскому приложению -- это, выражаясь
вашими словами, полный бред, т.к. обработка этой клавиши осуществляется системой
до того, как сообщение ставиться в очередь и будет доступно приложению.
Так что если в самом приложении нет специального кода, обрабатывающего WM_KEYDOWN
с VK_NUMLOCK (а этого нет в подавляющем большинстве приложений), то это сообщение
будет проигнорировано.
Соответственно, если по сути сказать нечего, но есть желание придраться, то
и придираться надо было к соответствующим словам, а не разглагольствовать о
том, что Windows не использует DIOS.

Теоретически, разумеется, возможно все, но речь шла о конкретной клавиши (см.
тему сообщений): NumLock, для получения скан-кода которой не нужно загружаться
в DOS.

посылает

Зафиксируем тот момент, что вы сказали "два скан-кода", из чего можно сделать
вывод, что речь-таки идет о расширенных скан-кодах (тогда корректнее говорить
не "два скан-кода", а двухбайтовый скан-код). Во всех иных случаях микроконтроллер
посылает либо меньше двух байтов, либо больше, так что "два скан-кода" -- это
расширенный скан-код.
Думаю, я правильно истолковал ваши слова.
В этом случае первый байт скан-кода указывает, что это расширенный скан-код (и
этот байт обычно равен 0xE0), а второй байт, собственно, и содержит скан-код.
В сообщении WM_KEYDOWN бит 24 указывает, что скан-код клавиши является расширенным
(действительно, зачем тратить на это целый байт, если можно обойтись одним битом),
а биты с 16 по 23 содержат второй байт расширенного скан-кода. Если это, на ваш
взгляд, туманно изложено в Platform SDK, то можете проверить на практике.

Существуют еще так называемые "дополнительные скан-коды", но размер этих скан-кодов
не два байта.

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

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

Для эмуляции нажатия клавиш в NT следует использовать keybd_event.

The keyboard driver's interrupt handler calls the keybd_event function.

Эта функция доступна из пользовательского кольца, поэтому вызывая ее, вы уподобляетесь
драйверу клавиатуры и ваша клавиша проходит через всю системную цепочку обработки
клавиатурных нажатий (лишь в конце которой стоит помещение WM_KEYDOWN в очередь
сообщений; а когда вы напрямую посылаете WM_KEYDOWN окну приложения, то вся предыдущая
цепочка не выполняется).
Так вот, возвращаясь к вопросу, обозначенному в теме сообщения, наиболее вероятно,
что скриптовая функция TypeKey использует вышеозначенную keybd_event , чтобы
эмулировать нажатие клавиши. Значение параметров для этой функции TypeKey берет
из keycodes.ini, в котором (по непонятной пока причине), начиная с определенной
версии JAWS, указывается неправильный скан-код для клавиши NumLock.

Успехов. Анатолий.

***
Это сообщение No 8283
было разослано для 469 участников дискуссионного листа
[JFWRus] Re[8]: Переключение NUMLOCK

Здравствуйте, i_chay.

Вы писали 10 марта 2009 г., 10:14:40:

Друзья, дискусия переходит тематику рассылки и несколько переходит
на личности.
По моему уже был дан вариант кода, как послать клавишу Num Lock.
Дак, что тема закрывается или возвращаемся от Дос, Биос и
прерываний к JAWS и коду скриптов JAWS..

Здравствуйте,

рассуждали

Вы очень некрасиво передёргиваете, что свойственно Вам когда Вы чувствуете свою
неправоту, а признаться страшно. Я утверждал, что форточки не используют вызовы
БИОС. Где Вы видите в моём утверждении хоть слово о драйверах. Если следовать
Вашей логике, то форточки пишут все кому не лень, включая даже фирму Фридом Саентифик.
Даже Вы или я могут стать автором форточек если напишут вшивый драйверок, почувствуй
себя сотрудником Майкрософт!

Удивительно, я думал Вы и здесь со мной не согласитесь.

Ну это уж совсем беспонтовый наезд не по делу явно. Сказать больше нечего?

Безусловно, и новые БИОСы я не изучал, времени уже нет. Но вот что странно форточки
даже на старых изученных мной БИОСах обрабатывают нажатие клавиши на уровне БИОС,
даже на USB клавиатурах. Я в шоке, как так, я даже об этом не догадывался, явно
Майкрософт перешила БИОСы, ой простите, перепаяла, во времена тех БИОСов ещё
не было флеш-ПЗУ.

настройках.

Не вопрос, у меня мать EPOX из ене дешёвых, выпуска 2004 года, приезжайте настройте
мне работу USB клавиатуры в БИОС-сетуп. Если Вам это удастся, то я не премину
об этом написать здесь. Но что-то я в этом сомневаюсь.

изначально

Ага, в моих постах Вы придираетесь к каждому слову, к каждой запятой, требуя
абсолютной точности, а сами допускаете настолько расширительное толкование, меняющее
смысл кардинально, а потом выкручиваетесь как уж на сковороде. Чем кумушек считать
трудится, не лучше ли на себя кума оборотиться (с) Крылов.

Перехват прерывания имеет отношение к БИОС только то, что это прерывание по умолчанию
обрабатывается БИОСом, а всё остальное никакого отношения к БИОСу не имеет. Ваше
выражение обрабатывается на уровне БИОСа означает, что в форточках БИОС обрабатывает
нажатие клавиш и уже передаёт обработанное форточкам. Не говоря уже о том, что
понятие уровень БИОСа вообще не существует.

Иначе говоря если следовать Вашей логике любая клавиша обрабатывается на уровне
БИОСа, которого не существует.

Либо если не установлен перехватчик события, посылки сообщения, который это обработает
в любом приложении. Учите мат. часть.

[... разглагольствования о том что надо делать всем вокруг и что не надо поскипаны
...]

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

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

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

и

получите.

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

До свидания.

***
Это сообщение No 8289
было разослано для 469 участников дискуссионного листа
[JFWRus] Re[9]: Переключение NUMLOCK

Приветствую всех.

Меня пока что мало волнует эстетическая сторона, тем более, что у меня есть серьезные
основания полагать, что мое представление о красоте существенно отличается от
вашего.
По поводу передергиваний вот цитата 1:

ли форточки БИОС или нет
[...]

Цитата 2:

Второе высказывание противоречит первому, поэтому я и уточнил: разбираетесь ли
вы в том, о чем пишете? судя по агрессивной реакции -- не разбираетесь, иначе
ответили бы спокойно и аргументированно.

Я вам предложил поисследовать драйверы на предмет вызова функции Ke386CallBios,
которая является системной функцией ядра Windows (см. ntoskrnl.exe) -- то есть
вас надо буквально носом ткнуть, чтобы стало понятно, о чем речь?
И драйверы, о которых шла речь, именно от Microsoft и входят в дистрибутив Windows.

Драйверы, входящие в состав дистрибутива, -- неотъемлимая часть операционной
системы (она попросту не встанет без них, а то, что не работает -- это не операционная
система).
Кстати, кроме басен Крылова, в вашем возрасте надобно для поддержание профессиональной
квалификации почитывать и другие книжки. В одной из которых можно найти следующее:
* * *
[boot loader] timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WIND0WS [operating systems] multi(0)disk(0)rdisk(0)partition(1)
\WINDOWS="Microsoft Windows XP Professional " /fastdetect C:\="Microsoft Windows"
Заметьте, что в этом примере путь к каталогу Windows задан по специальному синтаксису,
отвечающему соглашению по именованию Advanced RISC Computing (ARC). В Windows
используется три вида такого синтаксиса. Первый, синтаксис multi(), показан в
примере; он указывает Windows загружать системные файлы через функции прерывания
INT 13, предоставляемые BIOS.
* * *

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

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

Расширяемость толкования зависит от способностей толкователя (от его расширителя).
Не нахожу ничего кардинального, т.е. такого, что изменило бы суть вопроса: "полный
бред" Туманяна по поводу переключения NumLock при помощи WM_KEYDOWN.

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

Это ваше толкование и не надо его приписывать мне. Смысл, который я вложил в
это понятие, был уже разъяснен в предыдущем сообщении.
Или, быть может, вы сами с собой дискутируете?

Ну хоть это вы понимаете. Именно поэтому каждый волен подразумевать тот смысл,
который считает нужным.

Опять же не стоит приписывать мне вашу логику, иными словами -- согласно вашей
логике, возможно, это и так.
В моей логике таких пассажей нет.

обработает

Правильно ли я понял, что к тому "полному бреду" про посылку из скрипта сообщения
WM_KEYDOWN для переключения NumLock, вы еще предлагаете через скрипт довесить
к процессу хук?
А может сразу из скрипта JAWS загрузить драйвер ядра и управлять им оттуда же?
К чему надо было писать о перехвате сообщений, когда речь идет о скриптах JAWS.
Вспомните, о чем шла речь или у вас не хватает воли и интеллекта оставаться в
рамках вопроса: как переключить NumLock в скрипте JAWS?
Поскольку, как следует из вашего очередного "беспонтового" наезда, вы матчасть
изучили, то я жду от вас решения на основе изложенного вами способа, а именно:
переключение NumLock из скрипта JAWS посылкой сообщения WM_KEYDOWN и установкой
перехвата сообщений (dll с перехватчиком загружается тоже из скрипта JAWS), иначе
вы -- полное трепло.

получения

[...]

Это не имеет отношение к сути вопроса, а суть вопроса в том, что Туманян опять
лажанулся с тем, как расширенные скан-коды представлены в сообщении WM_KEYDOWN.

По вашему же посылу:

посылает

мы обсуждали лишь скан-коды нажатий(!) клавиш, которые представлены в соответствующих
битах WM_KEYDOWN.
Отпускание клавиш, во-первых, никак не обсуждалось, а во-вторых, представлено
другим сообщением -- WM_KEYUP. Для субъекта, который обвиняет всех и вся в увиливании,
как-то не к лицу так вилять, не правда ли?
Или все средства хороши?
Ну что же -- у каждого есть право выкручиваться и таким образом.

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

что через систему сообщений проходит сообщение WM_KEYDOWN...

слове

Теперь ожидаю от вас еще и второе решение вопроса, указанного в теме, а именно:
реализацию переключения NumLock из скрипта JAWS посредством отсылки недокументированного,
возможно, нигде не описанного, системного сообщения (полное определение см. в
цитате).

По вашим словам (я вынужден ссылаться на вас, т.к. то описание, которое вы изложили,
мне нигде не встречалось, и хотя я догадываюсь, о чем могла бы идти речь, но
тогда это работает не так), эти сообщения не привязаны к окну, да и вообще,
по-вашему, они не обрабатываются оконной системой... из чего следует, что в
очередь сообщений окна они не попадут и оконная процедура их не получит. Так
из какого же места не надо передавать управление DfWindowProc?
Кроме того, "глубины" Windows всегда отрабатывают до того, как сообщение будет
поставлено в очередь приложению. Пользовательское приложение -- это самое последнее
место, куда доходит информация о происходящем в системе. Это надобно понимать,
программируя в том числе и скрипты JAWS.

Успехов. Анатолий.

***
Это сообщение No 8307
было разослано для 472 участников дискуссионного листа
[JFWRus] Re[10]: Переключение NUMLOCK

Здравствуйте, i_chay.

Вы писали 13 марта 2009 г., 13:10:40:

Тема закрыта.
Дальнейшее продолжение приведёт к премодерации.
Обсуждаются исключительно технические вопросы связанные с JAWS.