-
Постов
3 901 -
Зарегистрирован
-
Победитель дней
32
Xipho стал победителем дня 10 августа
Xipho имел наиболее популярный контент!
Репутация
137 NOPerИнформация о Xipho

- День рождения 18.03.1981
Информация
-
Пол
Мужчина
-
Порождать новый контекст в процессоре только для того, чтобы он какое-то время простаивал - вот это, уж извини, лютейший бред. А то, что ты хочешь сделать - это, по сути, что-то вроде местечкового планировщика, почитай, как их обычно пишут.
-
Потому что ты хочешь изымать из этой очереди сообщения выборочно. Очередь сообщений винды под это не затачивалась. Чтобы извлечь одно сообщение, тебе надо вычитать все предыдущие и снова их положить в очередь. Разве это не бред? Прочитал остальное, и, извини, запутался еще больше. Выглядит так, как будто ты наворотил какую-то непонятную хрень, и теперь пытаешься ее разгрести. Это яркий признак того, что где-то ты напутал в архитектуре. Предлагаю сделать шаг назад и переосмыслить ту задачу, которую ты этими костылями пытаешься решить.
-
Это то, на чем построено всё функционирование оконной системы в винде. Конечно, бред. Потому что положенное в очередь сообщение будет дожидаться обработки по порядку (в общем случае) поступления. FIFO принцип. То есть, чтобы добраться до последнего сообщения, нужно вычитать все предыдущие. Ну и плюс вычитка сообщений всё-таки предполагается в основном потоке приложения. А в том кейсе, что ты описал, это не выглядит как FIFO, так как есть дополнительные условия и желание изымать сообщение из очереди при определенных обстоятельствах. Отсюда я делаю один вывод - тебе нужно что-то вроде буферного хранения сообщений, раз они могут быть отменены. Ну и система отложенной постановки сообщений из этого буферного хранения в виндовую очередь. Наверное, ты это читал, но скину на всякий случай: https://docs.microsoft.com/ru-ru/windows/win32/winmsg/about-messages-and-message-queues#message-routing
-
В цикле GetMessage/DispatchMessage с возвратом в очередь всех сообщений, которые не совпадают с тем, что тебе нужно. Но осуществлять подобное средствами очереди сообщений винды - имхо, бред.
-
Это значит "находясь в главном меню игры, сворачиваем ее и запускаем трейнер".
- 2 ответа
-
- 1
-
-
Если разыменуемая память доступна, то ошибки не возникнет, а вот мусор вернется, так что тут не вариант.
-
Нет, там использовалась 4 версия, она была бесплатной для коммерческого использования на тот момент.
-
Есть, но поверхностно - делал UI управления настройками устройства для депарафинизации нефтяных скважин. Там не было необходимости дорабатывать существующие контролы. Да, всё так Вопрос подхода. Qt в этом случае выбрали наследование, а ты выбираешь композицию. Сходу нельзя сказать, лучше что-то из этого, или хуже. Тут вопрос больше удобства кодинга. В случае с композицией у тебя ответственность смещается в сторону "композитора", то есть того, кто создает кнопку. В случае с наследованием всё, что связано с кнопками, инкапсулировано в классах кнопок. По моему личному скромному мнению - всё, что связано с GUI контролами выглядит как вполне подчинающееся иерархии классов, и, следовательно, тут хорошо подходит наследование. Но наследование должно быть грамотным, продуманным.
-
В коде тебе нужно будет вручную найти адрес модуля, который указан в строке, и к нему прибавить оффсет, который прибавляется.
-
Твоя обязанность как разработчика библиотеки - максимально обезопасить пользователя от подобных ошибок. Пользователь НЕ должен иметь доступа на запись полей внутри класса. Да, пользователь может сделать переменную и ее переназначить - и вот это уже будет на совести пользователя. А вот открытые к изменению публичные поля, это еще одна точка отказа, за которую ответственность несешь ты, как разработчик библиотеки. В идеальном мире ни одно поле не должно быть публичным, а сеттер поля должен делать валидацию поступающих на вход значений. У того же HDC в OnPaintEvent можно сеттер вообще сделать приватным, как и само поле, и тогда снаружи его изменить будет нельзя. Не устаю говорить всегда о том, что пользователю библиотеки ни в коем случае нельзя доверять. Потому нужно стараться максимально закрыть от пользователя детали реализации, и открыть ему только те части, в которых не сможет накосячить. Ну или накосячит по минимуму. В данном конкретном случае я сходу не подскажу, как это можно сделать, надо посидеть, подумать.
-
Подход не очень. Тот, кто будет пользовать твою библиотеку, может задуматься, ошибиться и записать в это поле какое-то значение. А потом будет тратить часы на отладку не понимая, почему получает графические артефакты (или что-нибудь еще менее приятное)