Antonshka

Привет всем, подскажите, как удалить из очереди сообщений потока определенное сообщение/сообщения? Кто-нибудь игрался с этим? Что-то как-то темно все с этим в интернете. Ситуация примерно такая: - Поток A создал кнопку. - При клике на эту кнопку, поток A создал поток Б. - Поток Б через 30 секунд запостит (используя PostMessageW) в очередь сообщений потока A специальное мною определенное сообщение. Запостит и завершится. - Однако, я передумал, и захотел отменить поток Б. Поток А, спустя 29.99 секунд после создания потока Б, идет и выполняет функцию отмены. Но, поток А не успел, и поток Б уже запостил сообщение. После возвращения потока А из функции отмены потока Б, он найдет сообщение от потока Б, и начнет его выполнять. Я же хочу, чтобы поток А, в функции отмены, дождался принудительного завершения потока Б (SetEvant, WaitForSigleObject). Затем, в этой же функции отмены, поток А проверяет свою очередь сообщений, и удаляет из нее возможное в ней сообщение от потока Б. Затем, поток А, вернется из функции отмены в MessageLoop функцию, и когда вызовет GetMessage, найдет что сообщения от потока Б уже нет. Значит оно не исполниться.

Спасибо что помог до конца разобраться.

Что если взять вот такой пример Так как v1 равно 0, значит по правилам v2 не будет проверяться. Проверка перейдет на v4. Это показывает и дизассемблер Значит OR проверяет все что слева (v1 && v2 && v3). А вернее сказать считается, со всем что слева. Ведь v3 здесь true, а значит то что правее OR по правилам проверяться не должно. Однако же оно проверяется, потому что OR считается не только с v3, но и с v1 и v2. Вот, а я просто думал что OR считается только с v3, только с чем то одним..

А я с оператором OR никак не мог разобраться. В качестве аргумента выступает все выражение до следующего слева/справа опреатора OR, если таковой имеется, или до начала/конца выражения. Так ведь? А то я думал что только до первой переменной слева/справа. Disassembler показывает, что происходит на самом деле.

Я игрался как-то раз с ним. Хотел сделать чекбоксы в виде слайдеров-переключателей. В каждом положении было по две картинки, одна видимая, другая нет. При клике они менялись видимостью. Такой трейнер занимал 1 гигабайт RAM памяти. Пришлось делать стандартные чекбосы. Не помню, использовал ли я тогда collectgarbage или нет. И помогает ли он вообще в этой ситуации.

Я в свое время хотел поменять цвет текста на обычной СЕ кнопке. Но это невозможно. Единственный выход, рисовать самому. В СЕ в celua.txt я видел такую возможность.

У меня такой способ не работает. Когда есть предусмотренный способ проверки через VirtualQuery, зачем использовать try/except? Я кстати в библиотеке WGW нигде не использую обработку ошибок. Если ее использовать, то использовать по максимуму. А если так, то код превратится не пойми во что.

Понятно. Кстати я сейчас смотрел исходники QT. Там тоже есть интересные моменты в коде, как и у меня Я заметил что в WGW Layout система уступает той что в QT. Теперь хочу доработать. Подумал, посмотрю как там сделано в QT. Но при виде кода решил что легче придумать самому. Пока разберешься, что там и к чему. Как было с Docking.

У тебя только с QT мало опыта, или вообще с GUI?

Получается это коммерческая ситуация? Нужно было платить как-то за использование библиотеки QT? Я сейчас посмотрел видео, где пишут калькулятор на QT. Мне понравилось. Что-то в этом наследование есть. Нужно подумать, может получиться совместить то что сейчас в WGW с тем что в QT.

А у тебя есть опыт работы с QT? В QT, как я понял, можно расширять классы контролов. Наследуясь от них. В WGW же, создание интерфейса осуществляется как бы процедурно, не через наследование. В QT события как я понял обрабатываются в методах класса, а не в простых функция как в WGW. И еще я кажется видел что в QT можно создать контрол через оператор "new". Не через наследование. То есть как я понял просто используя то что QT дает стандартно . - в QT есть расширение классов - в QT события обрабатываются в методах класса, а не в простых функцияч, как в WGW. Интересно, WGW от этого сильно проигрывает QT? Ну хорошо, наследовал в QT класс QPushButton, расширин функционал, добавил что новый класс при нажатии на кнопку пиликает. И теперь все кнопки созданные этим классом будут пиликать. А в WGW, вместо этого, можно создать файл PilicedButtons.h, там определить функцию на событие кнопка нажата, а в ней уже делать пиликанье. Затем все простые кнопки направить при нажатии на эту функцию. Получаем что и в QT.

А ведь логично. Должна же API предоставлять какой-то механизм исследования участка памяти. Рихтера читал недавно, но видимо не запечатлелось. Из MSDN собрал такое Да, есть такой момент.

Кажется вот рабочий способ. Не знаю насколько это правильно, но работает. Каждый раз перед проверкой доступа вызывать ReadProcessMemory.

Не сам базовый адрес модуля, а его адрес + смещение.

Покажи свой код. Может что-то связано с защитой памяти. VirtualProtectEx.

Я понял тебя. Ты говоришь вообще в целом. С этим я согласен, это я держу во внимании. Сейчас в библиотеке все так и есть. Все закрыто, ничего лишнего пользователь не то что изменить, даже и создать не может. Например никакой объект класса свойства контрола. Все что ему открыто, все безопасно. А я говорил про конкретную ситуацию с параметром функции события. Этот объект-параметр, специально имеет открытые поля, они безопасны, их можно изменять. Как я писал выше, по сути это все равно что вызвать метод такого объекта-параметра, просто библиотека делает это за пользователя. LRESULT OnPaintFunctionName(WGW::OnPaintEvent* onPaintEvent) { //Как в QT, получаем значение методом. HDC compDC = onPaintEvent->getMyCompatibleDC(); FillRect(compDC, ...) //Как в WGW FillRect(onPaintEvent->compDС, ...) }

Интересно как на С++ проверяется валидность значения адреса. HMODULE gameExeModule = GetModuleHandleW(L"ThisGame.exe"); gameExeModule += 0x10E58C; gameExeModule = *gameExeModule; //А если по *gameExeModule у нас NILL? Помню даже на форуме видел темы про это, только на СЕ. //Интересно такое допустимо на C++? if (*(gameExeModule)) //Этот вопрос конечно же разрешается несколькими тестами. Но пока не до них.

Графические артефакты? Я немного не понял тебя. Если к примеру взять событие WM_PAINT. Вот обычная функция для события рисования Это класс передаваемого объекта в параметре (указателя на него, сам он находится в классе окна, постоянно). Как видно из класса, только поля объявлены как public. Пользователь не может создать или обратится к этому объекту вне функции события. Создать его может только класс окна/контрола. А это то как заполняются поля при каждом сообщении WM_PAINT Поля объекта получают копии значений. Оригиналы не затрагиваются. Если пользователь по ошибке запишет в поле compDC что-то свое, то да, код далее этого момента будет глючить. Но так подумать, это можно отнести вообще ко всем переменным. Например В WGW этот вызов HDC hDC = onPaintEvent->getMyCompatibleDC(); выполняется за пользователя, автоматически и заранее. Все ошибки какие пользователь может совершить с переменными в данном случае в WGW, равны тем что в QT. Поэтому я не понял тебя.

Понятно 🙂. Мы же вместе собрались изобретать велосипед. Пусть простой, но зато свой. Вчера я даже не смог скачать QT Creator. Хотел посмотреть как там устроены сигналы, слоты. VPN не стал организовывать, из роликов и документации я примерно понял что там и к чему. Мне кажется WGW в этом плане попроще будет. Я заметил что в QT в параметре метода события (например кнопка нажата), передается определенный для этого типа события объект. И чтобы получить какие-либо его характеристики, нужно вызвать его методы. //QPushButton Class virtual void keyPressEvent(QKeyEvent *e) override И некоторые методы QKeyEvent А в WGW немного по другому. Вместо QKeyEvent объекта передается тоже определенный для этого события объект , но он не имеет методов. Он имеет public поля с уже подсчитанными/полученными значениями (из wParam, lparam). Такой подход в сравнении с QT удобнее, как мне кажется. Но есть один минус, - даже если пользователю не нужны эти данные в методе события, они все равно подсчитываются/получаются. То есть холостая работа. Хотя опять же, она такая незначительная, что я подумал так и оставить, а не писать методы для их получения. Либо разработчики гнались за максимальной производительностью, что даже такие мелочи оформили в отдельные методы. Либо это у них такой принцип. Не знаю.

Добавил. Я заметил у тебя в коде употребление префикса m_ (m_cheatSize). Про свой я уж молчу.

Понял, так и сделаю. Не буду ждать пока поправлю все. Несколько дней назад я создал Github аккаунт. Раза с 10 только получилось разобраться как правильно обновлять проект. Пока не знаю как вести обсуждения, впрочем, пока не до них. Я отправил приглашение для Xipho Github. @Xipho можно мне написать что этот проект совместная работа с тобой? А также всеми, кто помогал в разрешении вопросов, конечно же. Если у кого-то также есть желание, присоединяйтесь. Нужно ваше имя на Github, для отправки приглашения.

По идее да, тоже размыто 😜. Но в случае с update я думаю что будут ложные холостые вызовы. Например если есть 100 кнопок, из которых активны только 99 . Система сделает 99 вызовов update просто так. 99 проверок if легче же для системы чем 99 вызовов? Уже сделано, мы просто теперь обсуждаем правильность сделанного. Вообще просто обсуждаем как сделано.

Теперь кажется понятно. Значить действие || распространяется на все вообще части, слева от него и справа. Со скобками получается можно избавиться от повторного сравнения isAnchorEnabled if ( isAnchorEnabled && (!isInLayout || layoutOwner && !layoutOwner->layout.enabled) ) { calculate(); }

isAnchorEnabled повторяется два раза. Я поэтому и начал задумываться над тем как все это работает. Скобки в интернете советовали тоже, но что если без них? Как тогда поведет себя выражение. Хочу просто понять, а использовать можно и скобки. Можно ли так упростить if (isAnchorEnabled && !isInLayout || layoutOwner && !layoutOwner->layout.enabled) calculate(); isAnchorEnabled если будет true, тогда по идее далее его нет смысла проверять. Если && и || работают только с тем что конкретно слева и справа от них (а не вообще все, до конца), тогда по идее такой вариант сработает. У меня еще была мысль посмотреть в Disassembler, посмотреть как там на самом деле работает && и || в таких длинных выражениях.

Я столько много копал на этот момент. Плюс сам для себя пытался понять, как мне удобнее. В интернете большинство придерживается methodName. На счет скобок не нашел. Автор Imgui использует MethodName, и скобки все слева. Я перевел в одном классе все методы на methodName, перевел все поля-объекты также на camelCase (не поля обычных int, float... они и так были camelCase). И я нашел что для глаз так легче. BTN2->ToolTip.TitleText.Append(L"ToolTipTitleSecond1 \n", RGB(144, 140, 10)); //было BTN2->toolTip.titleText.append(L"ToolTipTitleSecond1 \n", RGB(144, 140, 10)); //стало Не знаю как это работает, но camelCase читается удобнее. Со скобками как в Java менее удобно, (наверно потому что не привык). Но зато с ними методы отделяются друг от друга более очевидно. Класс окна всего один. Он создает простое окно. Он поддерживает все что только можно сделать с окном. Создал такой экземпляр, и навесил на него все что нужно, все что он позволяет на себя навесить. Стили, полосы прокрутки, альфа канал, переопределил WM_PAINT и получил в своей функции в параметре уже готовый CompatibleDC, только и рисуй на нем. Я примерно прикидывал, и не нашел ничего такого специфичного, чтобы не позволил сделать класс окна с окном. Потому не стал его раздваивать. С предопределенными WinAPI контролами (Button, EditBox), тоже самое что и с окном, что хочешь, то и навесил на них. Есть например и специфичные окна, как например самодельный PopupMenu. Можно было наследовать его о таким обрызом Но PopupMenu не нуждается ни в Menu ни в Полосах прокрутки. Поэтому PopupMenu выведен в свой собственный класс, и наследуется не от Control класса, как например это делают Window, Button, EditBox, а наследуется сразу от GUI. PopupMenu не нуждается в тех объектах-свойствах в которых нужнаются эти. Поэтому всему архитектура сейчас такая. Ее лучше как ты говоришь увидеть, но и так схематично тоже помогает понять что к чему. Я запомнил этот момент. Лишний раз не нужно оверинженерить, как говорил ты и книга.