Курсор мыши перепрыгивает на второй монитор с сенсорным экраном. Как отключить?
Добрый день!
У меня есть второй монитор. У него есть сенсорный ввод. Проблема такая, что работая через сенсор на втором мониторе фокус мышки и сам курсор перескакивают на второй монитор. Это ужасно раздражает, т.к. после этих действий приходится возвращать курсор на основной монитор, в его предыдущую позицию. Так же, софт, который работает в полноэкранном режиме на первом мониторе, на это реагирует по разному. Что-то в паузу встает, что-то нормально реагирует.
Есть софт, что блокирует вывод курсора за пределы назначенного монитора. Но курсор все равно скачет к границам при действиях на сенсорном мониторе. Это не решение.
Можно ли настроить так, что бы курсор оставался в своей позиции не реагируя на сенсорный ввод?
Это особенность мультимониторной конфигурации windows (на linux варианты решений есть).
Совет, размести второй монитор, например, слева сверху от первого основного, если они будут касаться уголками, чтобы переместить мышь между ними потребуется точно попасть в угол, не решение но очень сильно помогает.
В win32 api есть методы по создания независимых десктопов и привязки их к монитору, даже в sdk есть пример, но пользоваться именно им в работе неудобно.
Из готового софта я знаю только ibik aster (там настраиваются рабочие места и каждому привязывается свои мониторы мышки клавиатуры), работает удобно и без проблем, но за небольшую денюжку
У меня в плане перемещения курсора нет проблем. Пускай он бегает по всем экранам когда мне это надо. Я говорю про то, что курсор мыши перескакивает в точку нажатия пальцем на втором экране. Это разные устройства ввода. Зачем они их объеденили? Вот что мне непонятно.
А софт, что вы мне порекомендовали, это не совсем то. Мне среда нужна одна, а там предлагают что-то типа виртуальной машины с отдельными интерфейсами ввода.
John Smith, А в том и прикол, что это и тактильно и визуально и вообще физически разные устройства ввода. Я клавиатурой по меню тоже могу бегать и имитировать клики мыши пробелом, но курсор мыши на месте остаётся. При тапах по экрану так же нет курсора мыши, но он появляется только когда мышь в руки берёшь и производишь сдвиг. Вообщем, моменты спорные.
Иван, эта особенность связана с тем, что при тач нажатии, в противном случае, будет генерироваться иное событие, которое стандартный софт не сможет обработать. Он не будет понимать, что куда-то нажали. И только новый софт, который поддерживает сенсорный ввод сможет корректно работать с тачем. Ты этого хочешь?
Винда имитирует поведение курсора тачем, чтоб весь софт, даже который понятие не имеет что такое сенсорный ввод, смог отзываться на нажатия.
Hemul GM, Допустим это и так. Что мешало записать координаты мыши и возвращать их обратно при работе с мышью? Ничто не указывает на то, что палец эмулирует мышь. Курсора нет, анимация другая...
Вообщем, я сюда не за разьяснениями пришёл, а за возможным решением. Софта в мире очень много, кто-то может уже сталкивался с подобными проблемами.
Мы должны признать, что Microsoft предприняла некоторые шаги, чтобы сделать традиционный и оптимизированный для щелчков мыши интерфейс подходящим для управления им пальцами рук.
Тем не менее, проблема остается: указатель мыши является значительно более тонким и точным инструментом, чем человеческий палец, и именно по этой причине первое поколение Windows-планшетов (времен Windows XP) поставлялись в комплекте со стилусом.
В настоящее время далеко не все устройства с 8/8.1 предлагают такую роскошь, так что одно нажатие на сенсорный экран интерпретируется системой как клик левой кнопкой мыши, два нажатия как двойной щелчок, а нажатие и удерживание – как щелчок правой кнопкой. Если прикоснуться к элементу на экране, а затем потянуть и отпустить, это будет признано Windows как хорошо знакомое перетаскивание (drag and drop). Прокрутка (scroll) осуществляется путем удерживания пальца на экране с последующим его перемещением горизонтально или вертикально.
------------------------------
Перемещение курсора в нужное место - это необходимость, без которой часть софта работать корректно не будет. Т.к. некоторые действия в программах завязаны на координаты мыши в данный момент, а не на данные о координатах в событии при нажатии мыши (или "эмуляции" события)
Hemul GM, Вы пытаетесь найти объяснение почему это невозможно, я пытаюсь найти готовое решение.
Нашел софт DDMM_v1.1 (Dual Display Mouse Manager), (100 kb) счастья. Была написана 10 лет назад. Великолепно блокирует курсор в пределах одного экрана. В 50% возвращает позицию курсора, в остальных случаях телепортирует на край экрана. Есть хоткеи на перемещение. Непонятно почему это нельзя было сделать на уровне системы.
Hemul GM, ОМГ, что вы несете... Сторонний софт спокойно может перехватывать мышь, а дописать в исходный код винды пару надстроек и вставить пару чекбоксов в настройки невозможно? Да они спокойно могу распараллелить и разделить устройства что ни один софт подмены не заметит. Было бы желание.
Я еще раз напишу, я не за объяснениями сюда с вопросом пришел что и как работает, а за решением. Вы можете сколько угодно текста вливать. Это просто оффтоп.
Иван, нет, это разные задачи и способы решение твоей проблемы
с точки зрения системы, события мыши и клавиатуры не привязаны к ним самим (это события логической сущности - десктоп), отличный пример, если ты подключишь две мыши и начнешь ими двигать в противоположные стороны с одинаковой скоростью, то курсор мыши не двинется с места и на сколько я помню даже не будет соответствующих событий для приложений (я это очень давно пробовал, сумма количества вызовов on_mousemove было меньше чем их делали устройства), когда как чтобы нужное тебе могло быть реализовано в полной мере - события нужно ловить ото всех устройств. Еще пример, подключив две клавиатуры, нажимая клавишу, шифт например, приложения получают сообщение нажата клавиша, отжата клавиша, но не известно от какой именно получено сообщение, т.е. ты можешь нажать сначала на первой клавиатуре, потом на второй и тут же отжав его, приложение посчитает что первое нажатие шифт завершилось. При отпускании шифт на первой произойдет повторный вызов метода on_keyup но приложение уже отработало его и либо проигнорируется приложением (потому что условие там будет скорее всего стоять - если состояние - кнопка нажата) либо произойдет ошибка/неверное поведение (например персонаж в игре попытается повторно выполнить действие на эту кнопку, перейдя в невозможную последовательность состояний, так баги для читов кстати тоже обнаруживают, не программисты)
Решение, которое ты нашел и тебе подошло - это классический хак, обходящий проблему, это не плохо и не хорошо просто так это работает.
