1

Тема: AHK -> AHK_L: совместимость скриптов

Если я решу перейти на AHK_L какие могут возникнуть трудности с совместимостью скриптов?
На офф форуме по поводу совместимости ничего не нашел, может рлохо искал.

2

Re: AHK -> AHK_L: совместимость скриптов

Script Compatibility

3

Re: AHK -> 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 в архиве, если есть.

4 (изменено: YMP, 2011-01-10 16:18:57)

Re: AHK -> AHK_L: совместимость скриптов

InFlames пишет:

Значит ли это, что в AHK_L Unicode версии скрипты, написанные для AHK, не будут работать, если они содержат DllCall и т.п.?

Проблемы собственно с DllCall — при переходе на AHK64. А тут ведь написано — "when DllCall, VarSetCapacity, NumPut or NumGet are used with strings." Если через DllCall в какую-то функцию API передавался указатель на строку, содержащуюся в переменной, то теперь это будет указатель на юникодную строку, вот что нужно учитывать. Т.е. при необходимости перекодировать её в ANSI, что в AHK_L не проблема. Или вызывать юникодную версию API-функции.

InFlames пишет:

Есть portable версия AHK_L?

У AHK_L своя страница есть, там можно взять бинарник в зипе отдельно и документацию в CHM. AutoHotkey_L

5

Re: AHK -> AHK_L: совместимость скриптов

Т.е., если я использую версию Ahk Unicode x86, то проблем с DllCall, VarSetCapacity, NumPut or NumGet быть не должно.
Кроме случая, когда  я передаю в функцию юникодную строку (русский текст например?). В этом случае необходимо строку переводить в анси. Так?

6

Re: AHK -> AHK_L: совместимость скриптов

Все строки в переменных будут в Юникоде, не только русские. Везде, где в DllCall тип параметра "Str", теперь это будет юникодная строка. Так что если функция ждёт строку в ANSI, будет ошибка в её работе.

Собственно, переводить вручную не всегда нужно. Если строка передавалась как тип "Str", достаточно исправить на "AStr", и функция получит её копию, перекодированную в ANSI. Но если строка передавалась в виде адреса, тогда нужно перекодировать самому.

Можете попробовать и ANSI-вариант AHK_L. Там была проблема с русской буквой "я", но она уже исправлена.

7

Re: AHK -> AHK_L: совместимость скриптов

В базовой версии бывают проблемы с копированием русским символов в буфер обмена.
Есть ли похожая проблема в ANSI билде AHK_L?
В Unicode билде я так понимаю подобной проблемы нет.

И еще вопрос а надо ли переходить на AHK_L?
Что такого нового принципиально в AHK_L? Массивы и COM?
Допустим COM  я не знаю и использовать вряд ли буду.

8

Re: AHK -> AHK_L: совместимость скриптов

InFlames пишет:

В базовой версии бывают проблемы с копированием русским символов в буфер обмена.
Есть ли похожая проблема в ANSI билде AHK_L?

Она может проявиться и в юникодном. В теме в Коллекции о корректной передаче русского текста через буфер обмена я описал её причину. Но ведь программы всё больше юникодные и текст из буфера хотят в Юникоде, так что использование юникодного билда должно сильно уменьшить вероятность такой проблемы.

InFlames пишет:

И еще вопрос а надо ли переходить на AHK_L?
Что такого нового принципиально в AHK_L? Массивы и COM?
Допустим COM  я не знаю и использовать вряд ли буду.

Новое, например, отсутствие проблем с кодировками. Можно прочитать или записать файл в любой кодировке, легко перекодировать строку. Вообще расширены возможности работы с файлами и строками. Легко посылать юникодные символы, т.к. их можно просто прописать в исходном коде в натуральном виде, а не изощряться с кодами. Поскольку исходник можно сохранить в UTF-8 или UTF-16 и они не потеряются. Последнее, конечно, справедливо для юникодного билда. В ANSI-билде, насколько знаю, исходник при чтении по-любому перегоняется в ANSI, так что такие символы будут утрачены.

Честно сказать, я особо не вникал в нововведения. Просто перевёл свой постоянно работающий скрипт на AHK_Lw и всё. Особых проблем не помню. Если у Вас всё работает на базовом АНК, не знаю, зачем Вам переходить. Я из любопытства перешёл. Но я на данный момент мало пишу на АНК, а так вообще возможности заманчивые. Конечно, буду их использовать, если что.

9

Re: AHK -> AHK_L: совместимость скриптов

Что делать если ахк не работает?

10

Re: AHK -> AHK_L: совместимость скриптов

Почитайте правила.

Уважаемые господа учёные!
Уже который год у меня в подвале происходит подземный стук.
Сам я в подвал не спускался.
Объясните, почему и отчего происходит этот стук?

По вопросам возмездной помощи пишите письма
E-Mail: serzh82saratov@mail.ru
OS: Win7x64, AutoHotkey_L v1.1.29.01 (Unicode 32-bit).