Уважаемые коллеги, могли бы вы что-либо подсказать по следующей теме?
Допустим, объявляем пользовательское сообщение var WM_MY_MESSAGE:cardinal;
Почему var? Потому что я инициализирую его так: initialization
WM_MY_MESSAGE:=RegisterWindowMessage('WM_MY_MESSAGE');
После объявляю обработчик procedure MyHandler(var Message: TMessage); message WM_MY_MESSAGE,
но требуется, чтобы WM_MY_MESSAGE было константой.
Вопрос: можно ли воспользоваться вкусностями message методов Delphi, при этом используя RegisterWindowMessage?
Уважаемые авторы вопросов! Большая просьба сообщить о результатах решения проблемы на этой странице. Иначе, следящие за обсуждением, возможно имеющие аналогичные проблемы, не получают ясного представления об их решении. А авторы ответов не получают обратной связи. Что можно расценивать, как проявление неуважения к отвечающим от автора вопроса.
18-04-2023 12:22 | Сообщение от автора вопроса
Для 3.11 не приходилось писать, а так помню, что рекомендации хранить настройки в Appdata существовали с незапямятных времён. Создатели Window долгое время смотрели на игнорирование их рекомендаций сквозь пальцы. Хранить данные в папке с программой - это логически лучший вариант, хотя права доступа диктуют свои требования. Но, например лежит прога на сетевом диске и её запускают многие. Тут, как раз вывгоднее хранить настройки в локальных Appdata, чтобы не пересекались.
>>> Не трогай рабочий код! Он - рабочий!
Трогай, трогай. Потому что он рабочий был пока система была 32-х разрядная. А при переходе на 64-х разрядную - когда работает, а когда ломается. А ещё код был рабочий, когда во времена Windows 3.11 писал конфигурационные .ini файлы прямо в папку Windows, а потом пришёл NTFS с правами доступа. Или программы, которые хранили свои данные в папке с программой вместо AppData. Примеров просто не счесть. Так что - нет, нет и ещё раз нет. Нет рабочего кода, есть недостаточно оттестированный (с) из анекдота про врачей. Рабочий код - это не ваша заслуга, а наса недоработка (с) из анекдота про спецслужбы.
На самом деле, есть чёткий способ, как пользовать переменные в обработчиках. Ответ - перехват метода WndProc. Там можно будет сравнивать полученный номер сообщения с любой величиной, хоть коньстантной, хоть переменной. Но помните, что злоупотреблять не надо. Всё-таки внутри недр приложения константные приложения сортируются двоичным поиском и поиск нужного обработчика выполняется очень быстро, тогда как обработчик, основанный на цепочке ifов будет немного... гм... медленнее...
"Враги" - это, в основном, мои ранние программы, в которых я использовал WM_USER + value. Но я подумал и уже переделал на WM_USER - всё работает, как ожидалось.
Вот только на message-методы переделывать поленился.
01-12-2022 18:51 | Комментарий к предыдущим ответам
Я всецело поддерживаю принцип "перебдеть, чем недобдеть"... Но тут куча вопросов.
Регистрировать должно одно приложение, потому как повторный вызов другим приложением - будет 0. Ну это решаемо.
WM_USER - уникально, как и WM_USER+1. Соответственно, даже если приложения пишутся в разных средах - прописать это значение труда не составит.
Если вы опасаетесь какого-нибудь "врага", который "шарится" по чужим окнам и шлет им всякие сообщения... то с тем же успехом он и Ваше уникальнозарегистрированное может послать. Чем WM_USER отличается от уникальнозарегистрированного? Только диапазоном значений, насколько я понимаю. Ограничения на посылку сообщений по диапазонам идентификаторов, насколько я помню, в виндах нет.
28-11-2022 17:35 | Комментарий к предыдущим ответам
У Вас какая-то сверх задача, что
const
WM_MY_MESSAGE = WM_USER + 1;
не устраивает? Вы свой стек окон сгенерили, чтобы обрабатывать несколькими окнами одно сообщение?
Спасибо, но я предпочитаю использовать RegisterWindowMessage, потому что это гарантирует уникальность.
Тогда уж лучще перегрузить обработчик сообщений.
Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter. Функция может не работать в некоторых версиях броузеров.
