>>2109

> О господи, это набор костылей для управления тем, что из коробки нормально не автоматизируется, к которому для удобства ещё и прикручены простенькие высокоуровневые средства создания своих окошечек, при помощи которых можно что-то себе налепить методом тык-пык. Вот раньше любили ругать «программистов на (Visual) Basic» за непонимание того, что вообще они делают, а теперь с тобой разбираться.

И что не так? Не все языки программирования должны быть сложными, должен и такой просто конструктор существовать, чтобы любой человек мог разобраться и создать для себя программу.

> Простых скриптообразных средств создания графических программ достаточно ещё со времён Tcl/Tk:

Вот и AutoHotkey тоже простой и удобный.

И я прекрасно понимаю что делаю, каждая строчка имеет свою цель.

> Подводные камни у тебя прямо на скриншоте: как только мы выходим за рамки примитивных операций, всё равно приходится лезть в кишки системы и понимать, как она работает.

Нет, не приходится, всё понятно и доступно написано в документации.

> И вот уже начинается шаманство с указанием WS_EX_COMPOSITED и WS_EX_LAYERED в числовом виде

Потому что в AutoHotkey оно указывается именно в числовом виде, нужны эти опции чтобы при смене картинки окно не мерцало (flickering). Конкретно это решение я нашла в интернете, да, а что в этом плохого?
https://learn.microsoft.com/en-us/windows/win32/winmsg/extended-window-styles
Что тут написано про эти стили я не особо понимаю, но если они решают мою проблему, то всё хорошо.

> и прямым вызовом функций системных библиотек

Это возможность языка AutoHotkey, он работает в системе и очевидно может использовать системные библиотеки.
Что тебя удивляет или пугает?

SetCurrentProcessExplicitAppUserModelID нужен чтобы дать уникальный идентификатор нашей программе, чтобы другие запущенные AutoHotkey приложения не группировались в одну иконку на панели задач.
https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-setcurrentprocessexplicitappusermodelid
Вот тут об этом написано.

> по-моему, для выделения отдельной кнопки на панели задач окну достаточно указать WS_EX_APPWINDOW, как написано и в документации к Windows, и в документации к AHK

Нет, ты ошибаешься, твоя опция вообще про другое.

> Конкретно твоя задача решается буквально школьниками, которые в Visual Basic, в Deplhi и в чём угодно ещё добавляют в окошечко картинку, объект таймера и пишут просто и понятно обработчик события от клавиатуры и обработчик события от таймера. Без всякой хрени, что вот у нас последовательный однопоточный скрипт, но задающий функции, выполняющиеся глобально и по необходимости вручную выбирающие нужное окно.

И через AutoHotkey тоже решаются, код красивый и элегантный, всё работает чётко и стабильно, поставленная задача решена, в чём проблема, какой хрени?

>>2140

> нужны эти опции чтобы при смене картинки окно не мерцало (flickering).

> Что тут написано про эти стили я не особо понимаю, но если они решают мою проблему, то всё хорошо.

Вот про это я и говорю. Одно дело знать, что пользуешься костылями и сознавать пределы их возможностей, другое — впустить в себя костыльные методы решения проблем и не видеть в этом проблемы.

Можно предположить, что высокоуровневый объект «изображение на форме» в AHK (внутренности которого для авторов скриптов представляют чёрный ящик) в общем случае при смене источника файла выгружает из памяти старую картинку, перерисовывает себя без содержимого, декодирует и загружает в память новую картинку, перерисовывает себя с ней. Это логично, потому что и при целенаправленной замене картинки автором на пустое место, и при потенциальной ошибке загрузки нового файла содержимое старого (уже недоступное в качестве ресурса) следует убрать с экрана, а выделять специально для этого случая отдельную доступную пользователю функцию перерисовки странно и неудобно (если манипулирующий состоянием скрипт развесистый). Вероятно, именно для человеческой работы с изображениями в AHK пришлось добавить низкоуровневый костыль для работы с handle'ами картинок и функцию LoadPicture, а также ручное управление выделенной под них памятью (копирование вместо передачи владения, явное освобождение вместо автоматического). По идее, тебе нужно загрузить обе картинки при старте и указывать один или другой handle для копирования при смене картинок. Другой вариант — просто добавить два растровых объекта и менять их видимость/порядок. А вот и третий — ещё костыль, который мне только что попался:
https://www.autohotkey.com/docs/v2/lib/GuiControl.htm#redraw-remarks
Если авторы AHK чего-то стоят, то и для картинок отключение на время смены значения будет работать.

А что же делают «решающие проблему» стили окна?

WS_EX_LAYERED говорит системе, что приложение может использовать прозрачность и не прямоугольную форму окна (помянем скин Windows Media Player в виде башки… а нет, проверил — ни хрена, там только форма меняется творческим использованием SetWindowRgn(), и на 9X/ME это всё тоже работало). WS_EX_COMPOSITED говорит, что дочерние элементы окна так же могут перекрывать друг друга не полностью. Но у нас не используется ни то, ни другое, что же меняется? Вывод таких окон и элементов идёт (то есть шёл когда-то) не прямо в буфер экрана, а в отдельные буферы, которые потом системой накладываются (с учётом прозрачности) строго после того, как лежащие ниже окна себя отрисуют. Кроме того, независимые буферы дают больше воли системе в том, когда и как их обрабатывать. Иначе говоря, исключительно благодаря тому, что твои циклы замены картинок и их перерисовки укладываются в один период перерисовки экрана системного композитора (вероятно, приклеенного к 60 fps на обычном мониторе), или тому, что Windows по какой-то своей логике решает этот вывод объединить, ты на мониторе видишь только конечный результат при задании этих флагов. Можно на это полагаться? Нет. Допустим, твои картинки станут размером с пол-экрана, или их надо будет масштабировать в другой размер, и операция загрузки перестанет быть «моментальной». Допустим, твой скрипт запустят на старой системе или в виртуальном окружении вроде WINE, где механизм работы отличается. Допустим, выйдет DirectX 15, в котором как-то ещё переделают взаимодействие с аппаратными буферами. «Решение» превратится в тыкву. Костыль? Конечно! Вместо того, чтобы понять причину проблемы, её случайным образом маскируют.

> Это возможность языка AutoHotkey, он работает в системе и очевидно может использовать системные библиотеки. Что тебя удивляет или пугает?

Можно написать программу на голом C, не использующую стандартную библиотеку или готовые каркасы для графического интерфейса, напрямую вызывающую все до единой системные функции. Можно и на AHK кучу импортов себе организовать, будто ты мастер динамической линковки и жонглирования указателями. Можно, но не нужно.

> чтобы другие запущенные AutoHotkey приложения не группировались в одну иконку на панели задач.

А, у тебя таких утилит несколько запущено. Ну вот у любого нормального средства ты получишь один процесс, главное окно, реальную очередь событий. Тут тебе надо помнить, что на самом деле основное окно процесса скрыто, взаимодействует со всем, что творится в системе, кучей разных способов, события в скриптах эмулирует, отдельно наблюдая за дочерними окнами, а для разведения нескольких таких окошек по кнопкам надо использовать ещё один волшебный костыль.

> И что не так? Не все языки программирования должны быть сложными, должен и такой просто конструктор существовать, чтобы любой человек мог разобраться и создать для себя программу.

Это правильно, и это когда-то был идеал. Вот учёный, перед ним компьютер, он не программист, он просто использует Fortran для расчётов. Вот менеджер, перед ним компьютер, он не программист, он просто использует SQL, чтобы посмотреть объём поставок клиентам. Вот проектировщик, он не программист, он просто использует какой-то язык для декларации ограничений для элементов и автоматической проверки этих условий. Пользователь компьютера именно что управляет им для решения своей проблемы, а не только полагается на готовые средства, предложенные другими. Только у тебя совсем не такой молоток, чтобы все шурупы им забивать.