О виртуальной мыши

← →
Сергей М. © (2010-04-14 13:39) [0]

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

При воспроизведении ранее записанной последовательности рассматривается вариант инжектирования эмулируемых событий с использованием интерфейса mouse_event().

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

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

Подкиньте, пож., толковые идеи на эту тему ?

Изобретать велосипед с собственной разработкой этого слоя, полагаю, нет резона - наверняка существуют готовые фриварные реализации ..

А может все гораздо проще и я полез в дебри ?)

← →
Игорь Шевченко © (2010-04-14 13:42) [1]

> А может все гораздо проще

WH_JOURNALHOOK/WH_JOURNALPLAYBACK ?

← →
Сергей М. © (2010-04-14 13:46) [2]

> Игорь Шевченко © (14.04.10 13:42) [1]

И как журнальный плейбэк может помочь в вопросе о "невыхватывании мыши" из рук юзера ?

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

← →
Anatoly Podgoretsky © (2010-04-14 13:47) [3]

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

Не вправе, фокус ввода один на все мышки и функции.

← →
brother © (2010-04-14 13:50) [4]

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

← →
Сергей М. © (2010-04-14 13:55) [5]

> brother © (14.04.10 13:50) [4]

Это равносильно выхватыванию мыши из его рук ..

> Anatoly Podgoretsky © (14.04.10 13:47) [3]

> Не вправе

Почему не вправе ?
Юзер вправе как минимум подвести мышь к кнопуле "Stop playback" и клацнцть ее, не так ли ?
Варианты про хоткей как костыль пока не рассматриваю)

← →
Сергей М. © (2010-04-14 13:58) [6]

> Anatoly Podgoretsky © (14.04.10 13:47) [3]

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

← →
brother © (2010-04-14 13:58) [7]

> Это равносильно выхватыванию мыши из его рук ..

правильно, ибо если он кликнет или еще что, то твой "плеер" - "пролетает")

← →
Anatoly Podgoretsky © (2010-04-14 14:00) [8]

> Сергей М. (14.04.2010 13:55:05) [5]

Вот это вправе, но подвести одной мышкой к одной кнопке и в тоже время другой мышкой к кнопке два не получится.

← →
Сергей М. © (2010-04-14 14:00) [9]

> brother © (14.04.10 13:58) [7]

А это уже проблемы юзера: не елозь и не тыкай когда и куда не следует, пока идет плейбэк ..
Детали ограничений - в справке к программулине)

← →
brother © (2010-04-14 14:01) [10]

> у каждой свой курсор и обе не мешают

О_О подрубил вотрую мышь ща... один курсор...

← →
Anatoly Podgoretsky © (2010-04-14 14:01) [11]

> Сергей М. (14.04.2010 13:58:06) [6]

Ну не надо про свой курсор, как раз наоборот курсор общий.

← →
brother © (2010-04-14 14:01) [12]

винда - однопользовательская система, так что, либо автоматика, либо юзветь...

← →
Сергей М. © (2010-04-14 14:06) [13]

> Anatoly Podgoretsky © (14.04.10 14:01) [11]

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

← →
brother © (2010-04-14 14:06) [14]

> что развести юзера и плейер по разным углам таким образом
> не удастся ?

[12]

← →
brother © (2010-04-14 14:09) [15]

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

← →
brother © (2010-04-14 14:10) [16]

> Изобретать велосипед с собственной разработкой этого слоя,
> полагаю, нет резона

похоже самое время ;)

← →
Anatoly Podgoretsky © (2010-04-14 14:11) [17]

[3]
В виндоус одна логическая мышка, независимо от количества физических. Развести можно если написать свои драйвера и все необходимое для рисования и обработки от разных мышей, такое есть в некоторых играх.

← →
Сергей М. © (2010-04-14 14:11) [18]

> brother © (14.04.10 14:09) [15]

> но это пиииии

Вот именно.
Так же как имитировать изображение отдельного курсора там где в дан.момент требует плейер ..

← →
Сергей М. © (2010-04-14 14:13) [19]

> Anatoly Podgoretsky © (14.04.10 14:11) [17]

> Развести можно если написать свои драйвера

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

← →
brother © (2010-04-14 14:15) [20]

> Вот это меня и интересует,

нет не то... в винде может быть только один актиный контрл? думаем далее...

← →
Игорь Шевченко © (2010-04-14 14:16) [21]

Курсор точно один и обе мыши за него воюют. Потому что обе мыши ставят свои события в одну системную очередь аппаратного ввода, которую разруливает RIT. А mouse_event проходит мимо этой очереди сразу к RIT, наколько я помню, а тот уже его направляет нужному потоку.

← →
brother © (2010-04-14 14:19) [22]

> такое есть в некоторых играх.

заметье учитывая [20] у игры одно ативное окно ;)

← →
Сергей М. © (2010-04-14 14:23) [23]

> Игорь Шевченко © (14.04.10 14:16) [21]

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

← →
brother © (2010-04-14 14:24) [24]

> в любой секунд найдется окно, потенциально возжелавшее быть
> сверху

блин...(

← →
Игорь Шевченко © (2010-04-14 14:32) [25]

Сергей М. © (14.04.10 14:23) [23]

А кто курсор рисует ? Мне казалось, что RIT, обрабатывая очередь системных событий

← →
brother © (2010-04-14 14:34) [26]

Скажите мне, а как Вы 2а активных окна делать будете?

← →
Сергей М. © (2010-04-14 14:35) [27]

> Игорь Шевченко © (14.04.10 14:32) [25]

Так я и не возражаю что он самый и рисует ..
Но от этого ж не легче)
Или ты намекаешь на гипотетическую возможность внедриться в RIT-механизм и изменить его поведение нужным образом ?

← →
Eraser © (2010-04-14 14:36) [28]

> [23] Сергей М. © (14.04.10 14:23)

> потенциально возжелавшее быть сверху, так ?)

по таймеру делат окно выше других каждую секунду. для данной ситуации этого хватит через глаза, imho.

← →
brother © (2010-04-14 14:38) [29]

меня не слышно?

← →
Сергей М. © (2010-04-14 14:39) [30]

> Eraser © (14.04.10 14:36) [28]

Ну с таймером понятно - костыль он и есть костыль)

← →
Сергей М. © (2010-04-14 14:40) [31]

> brother © (14.04.10 14:38) [29]

А оно зачем - два активных окна ?

← →
brother © (2010-04-14 14:42) [32]

в общем если:
> А это уже проблемы юзера: не елозь и не тыкай когда и куда
> не следует, пока идет плейбэк ..
> Детали ограничений - в справке к программулине)

то лучше [4] это гарантирует правильный реплей...

← →
brother © (2010-04-14 14:44) [33]

> А оно зачем - два активных окна ?

> Не вправе, фокус ввода один на все мышки и функции.

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

← →
Anatoly Podgoretsky © (2010-04-14 14:46) [34]

> brother (14.04.2010 14:19:22) [22]

В играх часто используются свои курсоры и прямой доступ к оборудованию DirectPlay

← →
Сергей М. © (2010-04-14 14:47) [35]

> brother © (14.04.10 14:44) [33]

> если юзверь потенциально может нарушить работу реплея

Говорю же - это его, юзверя, проблемы) ..
Об этом он, очевидно, должен быть предупрежден в сопровод.док-ции к программулине)

← →
brother © (2010-04-14 14:51) [36]

> и прямой доступ к оборудованию DirectPlay

не есть суть, главное

> фокус ввода один

← →
Anatoly Podgoretsky © (2010-04-14 14:52) [37]

> Сергей М. (14.04.2010 14:47:35) [35]

Не обязательно, пусть на своей шкуре изучает, как работать.

← →
Anatoly Podgoretsky © (2010-04-14 14:54) [38]

> brother (14.04.2010 14:51:36) [36]

Так в игре так и есть, одна картинка на весь экран и фокус ввода тоже один, на весь экран, плюс координаты тыканья и известно от какого устройства пришел тык или движение.

← →
Сергей М. © (2010-04-14 14:54) [39]

> Anatoly Podgoretsky © (14.04.10 14:52) [37]

Нет ну я, конечно, согласен что проблемы индейцев шерифа не волнуют, но ..

← →
Anatoly Podgoretsky © (2010-04-14 15:00) [40]

Вот пусть и канает.

← →
Дмитрий Белькевич (2010-04-14 15:16) [41]

> обе мыши чудесно уживаются, у каждой свой курсор и обе не
> мешают (

Гм, никогда не видел такого поведения. Видел: курсор - один, но управляется обоими мышами (проверил ради интереса :)). Фокус ввода таки один.

← →
Юрий Зотов © (2010-04-14 15:38) [42]

Демку сделать в виде ролика (то есть, со своим собственным "рисованным" курсором, а вместо mouseevent использовать его эмуляцию). Рядом с окном демки поместить обычное окно - плейер с кнопками Пуск, Пауза, Стоп.

Есть куча программ для создания таких демо-роликов. Например, Microsoft Camcorder пишет ролик в виде AVI или EXE, по выбору. AVI проигрывается обычным плейером, EXE показывает свой собственный.

← →
Anatoly Podgoretsky © (2010-04-14 15:46) [43]

Так и делают нормальные, надежные демо, независящие от мышей

← →
12 © (2010-04-14 15:59) [44]

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

> Сергей М. (14.04.2010 16:49:45) [45]

У нее свой рабочий стол, точно также записаный, не говоря уже об SilverLight

> Anatoly Podgoretsky © (14.04.10 16:52) [46]

Ах вон оно что ..

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

> Сергей М. (14.04.2010 16:56:47) [47]

Этого я не знаю. Может быть это другой класс демок, более сложный.

http://www.microsoft.com/Rus/Education/MultiPointMouse.aspx

MultiPoint Mouse SDK – бесплатно распространяемый набор библиотек для разработчиков, позволяющий создавать приложения, поддерживающие одновременную работу нескольких мышек. Технология поддерживает одновременную работу от 2 до 50 мышек

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=f851122a-4925-4788-bc39-409644ce0f9b

> TIF © (14.04.10 19:43) [49]

Э-э-э..

Оно, конечно, крайне любопытно было бы поглядеть, но тащить 60 Мб хрен знает чего, зная при этом что для этого явно требуется .NET-"нахлобучка" - это выше моего понимания)

> но тащить 60 Мб хрен знает чего

)))
Наше дело предложить, ваше дело отказаться ©

PS: вспоминал и вспомнил-таки сейчас, где видел описанную в сабже "живую" демонстрацию с движением курсора. В Sony Vegas 8. Вот только самое-то главное не помню, можно было там
> подвести мышь к кнопуле "Stop playback" и клацнуть ее
или всё-таки нет

:(

> TIF (14.04.2010 22:51:51) [51]

Ну это как раз просто, точно известен класс окна и название. В отличии от того как кликнуть по X,Y а его там нет или не оно. Но это обычно не демо, как таковое, а обучающая система, Микрософт любит подобное делать.

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

Вот это
http://www.eurekalog.com/tutorial1_delphi.php
похоже на сабж?

> Сергей М. © (14.04.10 13:39)

А точно ли нужен реальный повтор действий, а не показ записи, как в

> Германн © (15.04.10 00:24) [54]
> Вот этоhttp://www.eurekalog.com/tutorial1_delphi.phpпохоже
> на сабж?

?

> Демо © (15.04.10 00:55) [55]

Ну точный или не точный - это как звезды расположатся)
Главное чтобы плейер позиционировал курсор туда куда надо и клацнул тем чем надо там где надо.. Ну или колесом поелозил-пощелкал ..

А уж как на это отреагирует система или некое окно под курсором - это для плейера д.б. фиолетово

> Сергей М. © (14.04.10 13:46) [2]
> > Игорь Шевченко © (14.04.10 13:42) [1]И как журнальный
> плейбэк может помочь в вопросе о "невыхватывании мыши" из
> рук юзера ?Ведь требуется не только инжектировать мышиный
> ввод, но и визуализировать положение курсора ..

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

За это морду бить будут, я ткнул курсором в edit, пока все нормально, затем снова плейер получил управление и установил курсор в другое место, допустим на другой edit, а я между прочим вводил пароль!

← →
han_malign (2010-04-15 14:25) [59]

ааа... MMPORG бот...
нынче клиенты пользовательскую активность проверяют...

> Anatoly Podgoretsky © (15.04.10 11:34) [58]
> За это морду бить будут, я ткнул курсором в edit, пока все
> нормально, затем снова плейер получил управление и установил
> курсор в другое место, допустим на другой edit, а я между
> прочим вводил пароль!

Можно же запоминать позицию, в которой пользователь последний раз был активен, и возвращать курсор туда.

> Сергей М. © (15.04.10 10:01) [56]
>
>
> > Демо © (15.04.10 00:55) [55]
>
>
> Ну точный или не точный - это как звезды расположатся)
> Главное чтобы плейер позиционировал курсор туда куда надо
> и клацнул тем чем надо там где надо.. Ну или колесом поелозил-
> пощелкал ..
>
> А уж как на это отреагирует система или некое окно под курсором
> - это для плейера д.б. фиолетово
>

А я всё равно не понял.
Так ли уж нужно в демке двигать реальный указатель мышки?

> Демо (15.04.2010 22:36:00) [60]

Так я про это и говорю, ужас

> Германн (16.04.2010 02:19:01) [61]

Так или кинофильм или иммитация.

О виртуальной мыши Найти похожие ветки