Уважаемые господа учёные!
Уже который год у меня в подвале происходит подземный стук.
Сам я в подвал не спускался.
Объясните, почему и отчего происходит этот стук?
В базовой версии бывают проблемы с копированием русским символов в буфер обмена.
Есть ли похожая проблема в ANSI билде AHK_L?
Она может проявиться и в юникодном. В теме в Коллекции о корректной передаче русского текста через буфер обмена я описал её причину. Но ведь программы всё больше юникодные и текст из буфера хотят в Юникоде, так что использование юникодного билда должно сильно уменьшить вероятность такой проблемы.
И еще вопрос а надо ли переходить на AHK_L?
Что такого нового принципиально в AHK_L? Массивы и COM?
Допустим COM я не знаю и использовать вряд ли буду.
Новое, например, отсутствие проблем с кодировками. Можно прочитать или записать файл в любой кодировке, легко перекодировать строку. Вообще расширены возможности работы с файлами и строками. Легко посылать юникодные символы, т.к. их можно просто прописать в исходном коде в натуральном виде, а не изощряться с кодами. Поскольку исходник можно сохранить в UTF-8 или UTF-16 и они не потеряются. Последнее, конечно, справедливо для юникодного билда. В ANSI-билде, насколько знаю, исходник при чтении по-любому перегоняется в ANSI, так что такие символы будут утрачены.
Честно сказать, я особо не вникал в нововведения. Просто перевёл свой постоянно работающий скрипт на AHK_Lw и всё. Особых проблем не помню. Если у Вас всё работает на базовом АНК, не знаю, зачем Вам переходить. Я из любопытства перешёл. Но я на данный момент мало пишу на АНК, а так вообще возможности заманчивые. Конечно, буду их использовать, если что.
]]>И еще вопрос а надо ли переходить на AHK_L?
Что такого нового принципиально в AHK_L? Массивы и COM?
Допустим COM я не знаю и использовать вряд ли буду.
Собственно, переводить вручную не всегда нужно. Если строка передавалась как тип "Str", достаточно исправить на "AStr", и функция получит её копию, перекодированную в ANSI. Но если строка передавалась в виде адреса, тогда нужно перекодировать самому.
Можете попробовать и ANSI-вариант AHK_L. Там была проблема с русской буквой "я", но она уже исправлена.
]]>Значит ли это, что в AHK_L Unicode версии скрипты, написанные для AHK, не будут работать, если они содержат DllCall и т.п.?
Проблемы собственно с DllCall — при переходе на AHK64. А тут ведь написано — "when DllCall, VarSetCapacity, NumPut or NumGet are used with strings." Если через DllCall в какую-то функцию API передавался указатель на строку, содержащуюся в переменной, то теперь это будет указатель на юникодную строку, вот что нужно учитывать. Т.е. при необходимости перекодировать её в ANSI, что в AHK_L не проблема. Или вызывать юникодную версию API-функции.
Есть portable версия AHK_L?
У AHK_L своя страница есть, там можно взять бинарник в зипе отдельно и документацию в CHM. AutoHotkey_L
]]>Unicode: Strings are stored in UTF-16 format. Each character consumes a multiple of two bytes in this format, so care must be taken when DllCall, VarSetCapacity, NumPut or NumGet are used with strings.
Значит ли это, что в AHK_L Unicode версии скрипты, написанные для AHK, не будут работать, если они содержат DllCall и т.п.?
Остальное в принципе должно работать нормально.
Есть portable версия AHK_L? На офф сайте только установочный файл.
Скиньте установленный AHK_L в архиве, если есть.