numpad9::
clipboard=
Send, ^a
Send, ^c
clipwait
fileappend, %clipboardall%, c:\txt.txt
sleep, 1000
filereadline, var1, c:\txt.txt, line1
filereadline, var2, c:\txt.txt, line2
if (var1<>var2) soundbeepА по-моему, мы просто используем определённый синтаксис, говорящий интерпретатору, что нужно вызвать соответствующий объект. С оговоркой "явно" согласен, но это не меняет сути происходящего.
Ещё как меняет. Вызывая стандартную msgbox я не говорю интерпретатору вызвать MessageBox, я могу даже не знать о её существовании. Да и интерпретатор не обязан её вызывать, он может сразу вызвать MessageBoxEx, MessageBoxTimeout, или SoftModalMessageBox- это никого волновать не должно.
]]>Вот смотри, мы пишем в исходном коде, к примеру, MsgBox, и интерпретатор вызывает соответствующую WinAPI-функцию. Или мы, используя требуемый синтаксис, пишем
oShell := ComObjCreate("Shell.Application")и интерпретатор также обращается к соответствующей API. В чём ты видишь разницу?
Во втором случае мы явно используем сторонний объект(Shell), который не является частью языка.
]]>oShell := ComObjCreate("Shell.Application")и интерпретатор также обращается к соответствующей API. В чём ты видишь разницу?
]]>Но чтобы вызвать метод COM-объекта, к примеру, из AHK-скрипта, нужен определённый интерфейс, который сам по себе API-функцией не является, как и "стандартная функция".
Как и для любых API-функций.
]]>Методы COM-объектов- это API-функции.
Но чтобы вызвать метод COM-объекта, к примеру, из AHK-скрипта, нужен определённый интерфейс, который сам по себе API-функцией не является, как и "стандартная функция".
]]>Повторюсь, на команды AHK также можно смотреть, как на интерфейс к API, ведь никакого другого способа их выполнения не существует.
И что? API-функциями они от этого не становятся. По твоей логике API-функции- это функции, не содержащие вложенных функций, а это не верно, тем более что API не обязательно ограничивается функциями.
Последнего тезиса не понял.
"стандартные функции"- это не API-функции. Методы COM-объектов- это API-функции.
]]>Только к тому, что и при использовании COM из AHK, и при использовании обычных команд происходит обращение к API посредством определённого интерфейса, в этом сходство этих действий.
Это очевидно. Суть в том, что вызывая "стандартные функции" мы не обращаемся к API, а вызывая методы COM-объектов- обращаемся.
]]>Не понимаю к чему ты клонишь.
Только к тому, что и при использовании COM из AHK, и при использовании обычных команд происходит обращение к API посредством определённого интерфейса, в этом сходство этих действий.
teadrinker пишет:Вовсе не обязательно, AHK_L поддерживает COM.
Не знал.
Ну, тогда спор, видимо, исчерпан! 
Вовсе не обязательно, AHK_L поддерживает COM.
Не знал.
Не как API, а как оболочку для API. Просто COM — это оболочка, которую можно использовать в разных языках, а команды AHK — да, оболочка, которую можно использовать только в AHK, но от этого они не перестают быть оболочкой API в рамках данного языка.
Ну тогда эти API будут оболочками для других, более низкоуровневых API. Не понимаю к чему ты клонишь.
И вообще странное сравнение технологического стандарта(COM) с подпрограммами в AHK 
.
Для использования COM придётся использовать DllCall
Вовсе не обязательно, AHK_L поддерживает COM.
А "обычные" команды нельзя рассматривать как API, поскольку они служат только для "внутреннего пользования".
Не как API, а как оболочку для API. Просто COM — это оболочка, которую можно использовать в разных языках, а команды AHK — да, оболочка, которую можно использовать только в AHK, но от этого они не перестают быть оболочкой API в рамках данного языка.
]]>Это условие сработает в любом случае: и при использовании COM, и "обычных" команд, и DllCall().
Для использования COM придётся использовать DllCall- методы объектов вызываются как и обычные функции, только нужно передавать ещё и указатель на объект. А "обычные" команды нельзя рассматривать как API, поскольку они служат только для "внутреннего пользования". Например я не могу вызывать эти функции в своих проектах на C++ или паскале. Определение из википедии:
Интерфейс программирования приложений (иногда интерфейс прикладного программирования) (англ. application programming interface, API [эй-пи-ай]) — набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах.