aaa := "123"
vkBB::
tmp := Clipboard, Clipboard := "", Clipboard := aaa
ClipWait
SetKeyDelay -1
SendInput {Click}^{vk56}
Clipboard := tmp
ReturnSendInput {Click}%clipboard%
Спасибо, работает! (быстрая последующая смена буфера - не влияет)
Но делает это довольно медленно. Ну не совсем посимвольно, но время довольно весомое проходит, если текст длинный...
Не согласен, так как тогда бы такой код попеременно посылал бы, то "a", то "z".
Ваш код ну совсем про другое, попробую переписать 15 сообщение:
Некое окно забирает данные из буфера не сразу по получении Ctrl+V, а спустя пару-тройку десятков мс, к этому моменту буфер уже изменяется следующей командой после SendInput (Clipboard := tmp).
Возможно и по-другому: SetKeyDelay по-умолчанию 10, значит {Click} занимает 10 мс, т.е. смена буфера и отправка ^{vk56} происходят одновременно.
Если же отправлять напрямую содержимое буфера в Send, то последующие изменения самого буфера уже никак не повлиют на Send.
SendInput {Click}%clipboard%Пример приведите.
У меня все работает вроде без глюков:f11:: clipboard := "a" clipboard := "z" SendInput % clipboard clipboard := "b" SendInput % clipboard
Спасибо! Проверил, потестил. Работает! (пробовал и переменные, и длинные значения)
Заменил на SendInput {Click}^{vk56} или без клика - и начались прежние глюки.
Значит, именно в этом:
SendInput {Click}^{vk56} или просто ^{vk56}
- находятся тормоза. Именно это долго и происходит так, что быстрая последущаяя смена буфера влияет...
Это вместо вашего KeyWait, vkBB, зачем вы ждете отпускания клавиши мне неизвестно
Я думал, что vkBB:: и так начинает работать по началу нажатия. И ждёт отпускания только, если следующей строчкой указать KeyWait. Буду знать, Спасибо!
]]>f11::
clipboard := "a"
clipboard := "z"
SendInput % clipboard
clipboard := "b"
SendInput % clipboardТак как, так работает без пауз:
Спасибо за ответ. Да, такое без глюков, знаю.
Глюки начинаются, если после вставки сразу или через несколько команд - опять меняется буфер. Уж слишком быстро происходит, а вставка тормозит по сравнению с остальным, как выяснилось.
Не, просто конкретное окно принимает данные из буфера не сразу по получении Ctrl+V, а спустя пару-тройку десятков мс, а буфер уже изменен следующей командой.
Не согласен, так как тогда бы такой код попеременно посылал бы, то "a", то "z".
А он посылает либо "z" либо ничего.
f11::
clipboard := "a"
clipboard := "z"
SendInput ^vControlSetText - я слышал, читал тут одну тему. Но будет ли он работать везде? (у меня вставки текста нужны в браузере, форумы, публикации [s]каментов за дядю вову[/s] фильмаков)
]]>f11::
clipboard := "a"
clipboard := "z"
SendInput % clipboardТолько так:
В быстроте буфера нет проблем (также, ClipWait есть)
А Sleep мне щас помогло ПОСЛЕ SendInput (чтобы подождало пока вставит, и только потом переходило к следующим операциям, к следующему обновлению буфера)
Мой вопрос был в определении конца операции вставки...
Теперь думаю над способом обхождения без Sleep
Думаю ничего не выйдет.
https://autohotkey.com/docs/commands/On … Change.htm
If the script itself changes the clipboard, its OnClipboardChange label or functions are typically not executed immediately; that is, commands immediately below the command that changed the clipboard are likely to execute beforehand. To force the label or functions to execute immediately, use a short delay such as Sleep 20 after changing the clipboard.
Только так:
f11::
clipboard := "a"
clipboard := "z"
Sleep 20
SendInput ^v
aaa := 123
vkBB::
KeyWait, vkBB
www := clipboard
clipboard := aaa
ClipWait
SendInput {Click}^{vk56}
clipboard := www
ClipWait
www =
Но, если добавить Sleep после SendInput - всё работает! Теперь думаю над способом обхождения без Sleep, над способом определить конец вставки...
]]>