Тема: AHK -> AHK_L: совместимость скриптов
Если я решу перейти на AHK_L какие могут возникнуть трудности с совместимостью скриптов?
На офф форуме по поводу совместимости ничего не нашел, может рлохо искал.
Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Если я решу перейти на AHK_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 в архиве, если есть.
Значит ли это, что в 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
Т.е., если я использую версию Ahk Unicode x86, то проблем с DllCall, VarSetCapacity, NumPut or NumGet быть не должно.
Кроме случая, когда я передаю в функцию юникодную строку (русский текст например?). В этом случае необходимо строку переводить в анси. Так?
Все строки в переменных будут в Юникоде, не только русские. Везде, где в DllCall тип параметра "Str", теперь это будет юникодная строка. Так что если функция ждёт строку в ANSI, будет ошибка в её работе.
Собственно, переводить вручную не всегда нужно. Если строка передавалась как тип "Str", достаточно исправить на "AStr", и функция получит её копию, перекодированную в ANSI. Но если строка передавалась в виде адреса, тогда нужно перекодировать самому.
Можете попробовать и ANSI-вариант AHK_L. Там была проблема с русской буквой "я", но она уже исправлена.
В базовой версии бывают проблемы с копированием русским символов в буфер обмена.
Есть ли похожая проблема в ANSI билде AHK_L?
В Unicode билде я так понимаю подобной проблемы нет.
И еще вопрос а надо ли переходить на AHK_L?
Что такого нового принципиально в AHK_L? Массивы и COM?
Допустим COM я не знаю и использовать вряд ли буду.
В базовой версии бывают проблемы с копированием русским символов в буфер обмена.
Есть ли похожая проблема в ANSI билде AHK_L?
Она может проявиться и в юникодном. В теме в Коллекции о корректной передаче русского текста через буфер обмена я описал её причину. Но ведь программы всё больше юникодные и текст из буфера хотят в Юникоде, так что использование юникодного билда должно сильно уменьшить вероятность такой проблемы.
И еще вопрос а надо ли переходить на AHK_L?
Что такого нового принципиально в AHK_L? Массивы и COM?
Допустим COM я не знаю и использовать вряд ли буду.
Новое, например, отсутствие проблем с кодировками. Можно прочитать или записать файл в любой кодировке, легко перекодировать строку. Вообще расширены возможности работы с файлами и строками. Легко посылать юникодные символы, т.к. их можно просто прописать в исходном коде в натуральном виде, а не изощряться с кодами. Поскольку исходник можно сохранить в UTF-8 или UTF-16 и они не потеряются. Последнее, конечно, справедливо для юникодного билда. В ANSI-билде, насколько знаю, исходник при чтении по-любому перегоняется в ANSI, так что такие символы будут утрачены.
Честно сказать, я особо не вникал в нововведения. Просто перевёл свой постоянно работающий скрипт на AHK_Lw и всё. Особых проблем не помню. Если у Вас всё работает на базовом АНК, не знаю, зачем Вам переходить. Я из любопытства перешёл. Но я на данный момент мало пишу на АНК, а так вообще возможности заманчивые. Конечно, буду их использовать, если что.
Что делать если ахк не работает?
Уважаемые господа учёные!
Уже который год у меня в подвале происходит подземный стук.
Сам я в подвал не спускался.
Объясните, почему и отчего происходит этот стук?
Страницы 1
Чтобы отправить ответ, вы должны войти или зарегистрироваться