teadrinker пишет:

Хм, а зачем? Greystyle? Так ведь код читать неудобно.

Дело вкуса...

Именно так.

не решается ли проблема однопоточности путем запуска нескольких экземпляров AHK? Ну, к примеру, - в одном экземпляре - таймер, а во втором - шедулер с конструкцией, отслеживающей его состояние?

Решится, но лучше использовать те функции. Причины:
1) непредвиденное падение экземпляра с таймером приведёт к зависанию ожидающего скрипта.
2) новый скрипт будет съедать значительно больше ресурсов, чем поток.
3) в начале ожидания курсор примет "ожидающий вид"(как при запуске оконных приложений) и провесит так несколько секунд.
Так что лучше скопировать функции FreeWaitFunc и CreateWaitFunc в отдельный файл и при необходимости подключать его к скрипту(#Include FileName).

Хм, а зачем? Greystyle? Так ведь код читать неудобно.

Дело вкуса, я наоборот не люблю когда один аргумент(или как эту конструкцию назвать?) разбивается на два слова.

Александр_ пишет:

ahk_classAutoHotkey

Здесь, очевидно, пробел выпал.

Нет, я специально не оставлял пробелов ни в классе, ни в PID'е.

ahk_classAutoHotkey

Здесь, очевидно, пробел выпал.

Насколько я понимаю, создается тот самый таймер

Да.

Первый- это указатель на атрибуты защиты, указывая ноль мы говорим, что особых атрибутов нам не надо, пусть будут по-умолчанию. Почти всегда передают ноль, более подробно стоит разбирать этот параметр только тем, кто всерьёз собирается программировать под windows.
Второй отвечает за сброс события: 0- автоматический сброс, 1- ручной. Если таймер используется только один раз, то не важно что передавать.

Не совсем произвольное- это имя объекта ядра. Нас оно не интересует, можно передавать ноль- тогда будет создан неименованный объект.

Да, это тип возвращаемого значения. Возвращается описатель(handle) созданного таймера, он нам необходим для дальнейшей работы с таймером. Тип должен быть "ptr", дальше будет пример, где все типы указаны правильно.

Скорее "отключается", т.е. объект "таймер" всё ещё существует и его можно использовать. Для уничтожения таймера нужно закрыть все хендлы функцией CloseHandle.

1- ранее созданный таймер
2- либо дата первого срабатывания, либо промежуток через который таймер должен сработать, чтобы задать промежуток нужно передать отрицательное значение(например -50000000, означает через 5 секунд).
3- период срабатывания в миллисекундах. Т.е. после того как таймер сработает первый раз, он будет ещё и периодически срабатывать через указанный тут период. 0- значит не нужно периодического срабатывания.
4- функция завершения ожидания, в данном случае она нас не интересует из-за особенностей её срабатывания(поток должен быть в состоянии ожидания для её срабатывания)
5- параметр, который будет передан в функцию из четвёртого параметра
6- не помню, всегда ноль ставят .

Функция возвращает 0 в случае неудачи, иначе таймер успешно установлен. Т.е. объект "таймер" перейдёт в сигнальное состояние в указанное время.

WaitForSingleObject- ожидает перехода таймера(на самом деле почти любого объекта) в сигнальное состояние.
CloseHandle- уничтожает таймер.
WaitForSingleObject блокирует поток до наступления события, а AHK не поддерживает многопоточность. Для выхода из этой ситуации можно воспользоваться функциями из этой темы(из второго поста).
Пример:

#persistent
DetectHiddenWindows On
WinGet, hWnd, id, % "ahk_classAutoHotkey ahk_pid" . DllCall("GetCurrentProcessId")
OnMessage(0x401, "DlgProc")
hTimer := DllCall("CreateWaitableTimer", "ptr", 0, "int", 1, "ptr", 0, "ptr")
if (hTimer == 0)
{
   msgbox не удалось создать таймер
   ExitApp
}
EventProc := CreateWaitFunc(hTimer, hWnd, 0x401)
liDueTime := -50000000
x := DllCall("SetWaitableTimer", "ptr", hTimer, "int64*", liDueTime, "int", 0, "ptr", 0, "ptr", 0, "int", 0)
if (!x)
{
   msgbox не удалось установить таймер
   ExitApp
}
DllCall("CloseHandle", "ptr", DllCall("CreateThread", "ptr", 0, "ptr", 0, "ptr", 0|EventProc, "ptr", 0, "uint", 0, "ptr", 0))
return

DlgProc(wParam, lParam, msg, hWnd)
{
   global EventProc
   if(msg==0x401)
   {
      msgbox таймер сработал
	  FreeWaitFunc(EventProc)
	  DllCall("CloseHandle", "ptr", wParam)
	  ExitApp
   }
}

Handle:=DLLCall("CreateWaitableTimer" 
            ,"char *", 0 
            ,"Int",0 
            ,"Str",name, "UInt")

Насколько я понимаю, создается тот самый таймер, ему передаются параметры - дважды 0 (что это?) и "name" (как поясняет автор скрипта это - произвольное имя таймера; оно зачем - можно потом по нему обращаться к нему? или как?); "UInt", видимо, - тип возвращаемого значения (зачем оно и каким может быть?).

DLLCall("CancelWaitableTimer","UInt",handle)

Судя по слову "Cancel" и параметру, соответствующему ранее возвращенному значению, в зависимости от последнего таймер отменяется (отключается? уничтожается?). Это что-то типа ErrorLevel?

DLLCall("SetWaitableTimer" 
          ,"Uint", handle 
          ,"Int64*", duetime 
          ,"Int", 1000 
          ,"uint",0 
          ,"uint",0 
          ,"int",resume)

Тут вообще понятно только относительно "duetime", это время срабатывания таймера в формате UTC-file-time. Что задают остальные передаваемые параметры? И что дает эта конструкция, выходных-то данных никаких нет? Или выполнение скрипта на этом месте останавливается до наступления указанного времени?

Signal:=DLLCall("WaitForSingleObject" 
            ,"Uint", handle 
            ,"Uint",-1) 
DllCall("CloseHandle", uint, Handle)

Имеет ли этот участок кода отношение к таймеру и если да, то какое?

____________________________________
будьте снисходительны - я профан

померещилась мне окончательная ясность и я сваял такой, с позволения сказать, код:

Gui, Add, DateTime, vTimeToAlert 1 w60, HH:mm
Gui, Add, Button, r1 w60, CTAPT
Gui, Show, AutoSize
Return
  
ButtonCTAPT:

Gui, Submit
StringMid, TimeH, TimeToAlert, 9, 2
StringMid, TimeM, TimeToAlert, 11, 2
TimeToWait:=(TimeH*60*60*1000+TimeM*60*1000)-(A_Hour*60*60*1000+A_Min*60*1000)
if (TimeToWait<=0 )
TimeToWait:= TimeToWait+24*60*60*1000

SetTimer, Alert, %TimeToWait%
return

Alert:
msgbox its work!!!
SetTimer, Alert, Off 
ExitApp

Но теперь я так понимаю, что речь-то шла не про тот timer...

Пойду попытаюсь вкурить что-нибудь на этот счет...

____________________________________
будьте снисходительны - я профан

А что, должно повлиять?

Ну а как иначе. Допустим сейчас час ночи, тогда задачи "выполнить через час" и "выполнить в два часа ночи" разнятся, поскольку переведя часы на час назад можно отложить выполнение условия. Кстати, WaitableTimer работает со временем по Гринвичу, так что смена локального времени на неё не повлияет.

В качестве будильника сработает и обычный, если задать время одним промежутком.

А если время переведут?