Antonshka

Привет, как можно избавиться от мерцания текстового контрола при очень частом его обновлении? Использую обычный Static Control, созданный на главном окне вызовом функции CreateWindowExW. В родительской оконной процедуре возвращаю HOLLOW_BRUSH, в сообщении WM_CTLCOLORSTATIC, чтобы фон теста был прозрачным, то есть чтобы отображались только черные символы. ExStyle для Static Control устанавливаю на WS_EX_TRANSPARENT. А Style на WS_CLIPSIBLINGS. Для родительского окна Style ставлю на WS_CLIPCHILDREN. Затем начинаю для родительского окна часто вызывать функцию RedrawWindow(m_Owner.GetHWND(), NULL, NULL, RDW_INVALIDATE | RDW_ALLCHILDREN); и Static Text Control жутко мерцает.

Привет, помню в свое время я тоже натыкался на это. Вот объяснение. Код игры состоит из множества функций. Функции 'А', 'Б', 'В', 'Г', 'Д' и т.д. Функция 'А' например работает с функцией 'Б'. А функции 'Г' с функцией 'Д' . Одни игровые функции работают с другими игровыми функциями. Но бывают случаи когда какая-либо игровая функция работает не только с игровыми функциями, но еще и с НЕ игровыми функцией. Например как вот с этой НЕ игровой memcpy. Последовательность работы игрового движка грубо говоря такая: - выполняется игровая функция А - выполняется игровая функция Г - выполняется НЕ игровая функция memcpy - выполняется игровая функция С - выполняется игровая функция Е Игра вылетает из--за того что происходит неправильная инъекция в memcpy . Именно устанавливаются некорректные значения для регистров. Если все делать правильно, то все будет работать. Но как @Xipho уже написал, не стоит вклиниваться в НЕ игровую функцию. Мало ли что там с ней будет после ее обновления. Как я понимаю. Лучшее решение это вклиниться после выполнения memcpy - выполняется НЕ игровая функция memcpy ------------------ вот сюда ---------------- - выполняется игровая функция С memcpy имеет такой прототип После выполнения memcpy значения регистров (R8, R9 кажется, нужно конкретно смотреть в игре) имеют значения *dest и *src. Зная их можно самому докопировать/заменить то что нужно.

Да, я сам за то чтобы программа была устроена самым простым и понятным образом. Без наворотов, только необходимый минимум. Краткость и простота и удобство, это по мне. СЕ же на Паскале как я понял написан. DB говорит в СЕ реализация записи и считывания полей через RTTI. Но в С++ RTTI только и умеет что получать имя типа, не более. Да и потом, я не понимаю что толку от этого. Ну получил я значения полей класса, а дальше что? Таймер там нужен для периодической оценки смены значений полей, или еще что, не знаю. С перегруженными операторами работает как надо, просто приходится для каждой арифметической операции писать свою функцию. Пока я остановился на основных Это класс для параметра высоты окна. Работает как в СЕ. Можно писать и так и сяк

Приемы полезные у него конечно есть, и не мало, но как я сейчас посмотрел, он использует только геттеры и сеттеры. Мне же нужно чтобы было без них.

Я наверно не так выразился, или я не понял твоего ответа. Например я нажимаю на кнопку, на форме, когда приложение уже запущено. В процедуру этой кнопки поступает сообщение WM_LBUTTONDOWN. В Case этого сообщения идет вызов определенной мною функции, например функции где будет изменятся высота этой самой кнопки, или другой какой. Button pBtn1 = new(Button); Button pBtn2 = new(Button); ... switch(msg) case WM_LBUTTONDOWN: ChangeHeight(hWnd); ... void ChangeHeight(hWnd) { pBtn1->Height = 10; pBtn2->Height = pBtn1->Height; } И на этом все. То есть класс кнопки должен сам теперь позаботится о том, чтобы вызвать вначале функцию SetWindowPos, для изменения параметров кнопки, а затем функция InvalidateRect. Но как классу дать понять, что теперь вот все, можно вызвать эти две функции? Если поле Height класса Button является типом int с доступом public. Класс никак к сожалению не уведомляется об изменениях, в нем происходящих. Сейчас смотрел как это дело работает на Qt. Так там для Height нужно писать ->setWidth() //установить ->Width() //получить Но мне то хочется как в СЕ, без скобок, и одним и тем же выражением, что для получения, что для установки. Я это ради освоения WinAPI, и C++ в целом. Я вижу пользу от этого занятия.

Как сделать так, чтобы класс контролла, к примеру класс Button, имел поле, к примеру поле Height, и чтобы можно было считывать и записывать в это поле выражениями Button* pBtn1 = new Button(); Button* pBtn2 = new Button(); pBtn1->m_Height = 10; //или так, запись pBtn2->m_Height = pBtn1->Height //или так, считывание Одна из идей, сделать поле m_Height объектом некоего класса Height, у которого есть перегруженный оператор =, или еще и другие операторы, +, -, +=, int. Но с таким подходом для каждой арифметической операции придется писать свой соответствующий перегруженный оператор. А это накладно. Сделать бы так, чтобы при считывании поля m_Height, оно автоматически преобразовывалось в тип Int. А с ним, операции заранее уже умеют работать. Но не хочется писать так pBtn1->Height() Хочется в обоих случаях писать без скобок. Можно было бы просто сделать поле m_Height обычной переменной типа Int, и сделать ее как Public. Но как тогда спровоцировать обновление отображения контролла, после того как будет совершена запись в поле m_Height. Как дать понять приложению обновить контролл. Сделать ли таймер, поток, который работал бы как Anticheat Integrity Check, - если увидел что значение поля изменилось, то спровоцируй перерисоку контролла, тем же вызовом API InvalidateRect. Но тогда, при таком способе, нужно для каждого объекта класса Button, создавать свой поток. А ведь сколько всего контроллов будет содержать приложение? Не накладно ли это, в отношении производительности работы приложения.

Хочу именно на WinAPI, чтобы освоить его. Потом можно на Qt.

Спасибо, то что нужно. Я пробовал искать "Wrapped Wraped Api UI C++". Пишу большое приложение.

Привет, подскажите, как можно реализовать управление UI на С++ как например в Cheat Engine? С помощью чистого WinAPI, не MFC. Также с помощью Visual Studio Dialog Editor. В СЕ все максимально просто, - хочешь поменять параметр контролла? Хочешь указать функцию на событие например MouseClick? Есть идея, что нужно использовать классы. Почитал в интернете, в частности вот эту статью но не смог уловить мысль. Сложно пока для меня. Хочу в итоге что-то типа

Похоже так не получится. Поиск будет идти от начала EXE модуля, то есть от адреса который выравнен по 0 в конце, а искомое Int значение может не совпасть с этим выравниванием. Нужно либо самому указывать в сигнатуре место начала Int значения, которое попадет под выравнивание 0, либо просто не мается и сканировать побайтово.

Все нормально.

После того как подключу отладчик VS к игре, нужно же еще загрузить скомпилированную DLL в игру? Например через CE? Я думал просто надо подключить VS к игре и поставить брейкпоинт. Думал VS сам загрузит DLL в процесс игры.

Привет, подскажите, как отлаживать DLL из проекта. Например, я написал DLL в Visual Studio на C++. Написал для игры. Как теперь это дело отладить? Вот статья на MSDN об этом Ставлю брейкпоинт, жму F5, но точка остановки сообщает что - the breakpoint will not currently be hit no symbols have been loaded

Привет всем снова! Что если сканировать и сравнивать память не по одному байту за раз, а по 4, или даже по 8? Даст ли это прирост скорости обработки? Например, имеем сигнатуру вида - 50 89 ?? C8 E8 3D CB FD FF ?? 5D. Далее, пусть функция, которая формирует маску и патерн, также определит, есть ли в сигнатуре непрерывная последовательность из 8, или если не 8, то хотя бы из 4 байт (то есть последовательность в которой не встречается ??). Если нет такой последовательности, то пусть выполнится стандартная версия функции поиска сигнатуры, - побайтовая. Если же есть такая последовательность, то пусть извлечется и сохраниться это 4 или 8 байтовое значение. Например C8 E8 3D CB. А затем, пусть вторая версия функции поиска сигнатуры использует это 4 байтовое значение для сравнения. Пусть она считывает по 4 байта за раз, то есть число типа int, и сравнивает его. Если будет совпадение с ним, то пусть она занесет его адрес в например std::vector<int *>. Допустим нашлось 20 совпадений. Пусть далее цикл пройдется по этим 20 указателям, и сравнит уже их побайтово, по длине маски. Есть ли смысл пробовать реализовать такое, или нет? Чтобы зря не терять мне время.

Спасибо!

Привет! Скачал сегодня книгу, - Nicolai M. Josuttis: The C++ Standard Library, 2nd edition. Формат PDF. При переходе по закладкам в тексте документа, масштаб страницы автоматически сбрасывается. У меня Adobe Acrobat - Pro DC, версия продукта - 19.21.20061.361316 (свойства exe файла/подробно). Искал в интернете как можно отключить автосброс масштаба, но действенного ничего не нашел. Через Cheat Engine нашел инструкцию которая сбрасывает масштаб при переходе по ссылке. Если кому это тоже нужно, то вот она Если вы знаете как решить эту проблему естественным способом, то я буду тоже очень рад его узнать.

Понял, это хорошо.

Имею ввиду создание отдельного окна, на котором будут разные стандартные контролы. Создание на WinAPI, но создание таким образом, чтобы код создания окна был в DLL, которая инжектится в игру, и чтобы не использовать TCP, named pipes, и подобные способы связи, а просто, напрямую, менять значения переменных, определенных в DLL.

А реально создать GUI на WinAPI в DLL которую инжектишь в игру? А то как сейчас я вижу, функции GUI на WinAPI часто требуют в качестве одного из своих параметров HINSTANCE приложения. Но у нас же не EXE, а DLL. Нельзя так сделать что-ли? А то я видел как @Xipho советовал кому-то недавно каким образом можно реализовать взаимодействие EXE трейнера с загруженной DLL. Помню советовал TCP что-ли. А так бы раз, и наше GUI находится уже в DLL, и следовательно все контролы получают прямой доступ к переменным, для опций читов, к примеру.

Это рисуется в окне игры? Или в окне приложения которое использует для себя DirectX? imgui - интересная вещь. Слышал что у него недавно появилась поддержка DX12. Про WPF слышал что нет нормальной документации, но зато он рисует средствами DirectX. Но он к сожалению на c#, а я на с++, так что не мой вариант, пока что, по крайней мере.

Привет! Дочитываю книгу Щупака, по WinAPI. По словам самого автора - Петцольд, насколько я видел, пишет о том же самом что и Щупак, правда часто в более краткой форме, Фень Юань, - пишет более подробно, но у него все про GDI. Потому, дочитав Щупака, я решил перейти уже к написанию своего собственного приложения. Писать я буду на чистом WinAPI. Для того чтобы закрепить материал, в первую очередь, и для того чтобы просто уметь это делать именно на нем. Но что потом? Так и писать GUI приложения на чистом WinAPI? На чем вы пишите GUI для своих приложений? Читал сегодня, что на чистом WinAPI, приложения и весят меньше, и работают быстрее. Что MFC неудобный, с точки зрения стиля (я его еще не изучал). Что Qt тоже имеет какие-то проблемы. Вообще в будущем есть намерение писать через DIrectX. Но если не через него, то через что?

Инициализировать коммон контролы, то есть выполнить этот код?

Забыл написать что проект на UNICODE. Итак, после нескольких часов поиска решение в интернете, стало ясно что: - элемент управления ToolTip относится к общим элементам управления (common controls). Есть еще стандартные элементы управления (user controls) - общие элементы управления определены в файле ComCtl32.dll - файл ComCtl32.dll находится в папке windows/sytem32 - файл ComCtl32.dll имеет разные собственные версии - версия файла ComCtl32.dll влияет на то с какой версией структуры TOOLINFO код API, находящийся в ComCtl32.dll, может работать - для инициализации элемента ToolTip нужно определить и заполнить структуру TOOLINFO - существует три версии структуры TOOLINFO, отличающиеся количеством полей версия 1 - TTTOOLINFO_V1_SIZE //Для ComCtl32.dll версии 4.0 и выше версия 2 - TTTOOLINFO_V2_SIZE //Для ComCtl32.dll версии 4.7 и выше версия 3 - TTTOOLINFO_V3_SIZE //Для ComCtl32.dll версии 6.0 и выше - структура TOOLINFO помимо прочих своих полей, имеет поле cbSize, которое нужно заполнить, записав в него размер самой же структуры, то есть размер структуры TOOLINFO. - поле cbSize структуры TOOLINFO используется системой для определения версии API кода, который нужно использовать для работы с ней - заголовочный файл "commctrl.h", который необходимо подключить к проекту для того чтобы работать с общим элементам управления, основываясь на значении макроса _WIN32_WINNT, выбирает для работы с ToolTip соответствующую версию структуры TOOLINFO. - _WIN32_WINNT - этот макрос определяет в каких версиях Windows может выполняться ваш код - в моем проекте макрос _WIN32_WINNT имеет значение 0x0A00, что значит Windows 10 и выше, а это значит что проект использует самую новую, самую последнюю версию структуры TOOLINFO из заголовочного файла "commctrl.h", структуру о с размеров - TTTOOLINFO_V3_SIZE - если вы явно не укажете в своем проекте что хотите использовать ComCtl32.dll версии 6.0 и выше, то по умолчанию будет использоваться версия 5.0, а это значит что будет использоваться API код для работы со структурой версии TTTOOLINFO_V2_SIZE. Таким образом, файл "commctrl.h" предоставляет нам структуру версии TTTOOLINFO_V3_SIZE, в то время как ComCtl32.dll работает с версией TTTOOLINFO_V2_SIZE. Размер структуры TTTOOLINFO_V3_SIZE на 4 байта больше чем TTTOOLINFO_V2_SIZE. Из-за этого подсказка не отображается на экране. Решение может быть одним из следующих: - либо явно указать проекту что мы хотим использовать ComCtl32.dll версии 6.0 и выше, для этого нужно создать файл манифеста, в котором это указывается, или вместо файла манифеста воспользоваться прямым обозначением нашего намерения в файле .срр - либо переопределить макрос _WIN32_WINNT, до версии Windows 2000 - либо явно заполнить поле cbSize размером структуры TOOLINFO минус 4 байта Использование ComCtl32.dll версии 6.0 и выше меняет стиль отображения элементов управления. До версии 6.0 стиль элементов как в windows 95, 98. То есть до XP.

Привет, никто не сталкивался с проблемой отображения автономного ToolTip? Делаю как в книге, и как на MSDN. Приложение запускается, но подсказку не отображает. Примитивный код С++ Ссылка на MSDN

Вот опять, решение пришло в голову сразу после того как я написал здесь свой вопрос. Два дня я тщетно пытался его решить, но стоило мне запостить... Подумают что я спамер. А ведь действительно, два дня голову ломал. Ребята, которые тоже изучаете GDI, и имеете трудности в понимании режимов отображение, вот решение вопроса установки логической единицы равной 1/16 дюйма, как я полагаю: если умножить не на 16 SetWindowExtEx(hdc, (GetDeviceCaps(hdc, HORZSIZE) / 25.4) * 16, (GetDeviceCaps(hdc, VERTSIZE) / 25.4) * 16, NULL); но на 1 SetWindowExtEx(hdc, (GetDeviceCaps(hdc, HORZSIZE) / 25.4) * 1, (GetDeviceCaps(hdc, VERTSIZE) / 25.4) * 1, NULL); то вся ширина экрана в логических единицах будет равна числу 23.543 (дюймов, полученному из 598 мм / 25.4 мм). Почему вся ширина экрана? Потому что мы установили всю ширину экрана, а также всю высоту экрана, с помощью функции SetViewportExtEx(hdc, GetDeviceCaps(hdc, HORZRES), GetDeviceCaps(hdc, VERTRES), NULL); И если мы теперь попытаемся нарисовать к примеру прямоугольник, с шириной 23.543 единицы, Rectangle(hdc, 0, 0, 23.543, 11.7715); то он отобразится на экране точь в точь шириной во весь экран, а высотой в пол экрана, так как 23.543 / 2 = 11.7715. Теперь, если умножить 23.543 на 16, SetWindowExtEx(hdc, (GetDeviceCaps(hdc, HORZSIZE) / 25.4) * 16, (GetDeviceCaps(hdc, VERTSIZE) / 25.4) * 16, NULL); то мы в 16 раз увеличим диапазон ширины, для наших логических единиц. Тем самым, например при том же значении Y = 11.7715, прямоугольник отобразится уже в 16 раз меньше по высоте, так как логическая единица уменьшилась в 16 раз. Если провести аналогию, для лучшего понимания, то возьмем к примеру метровый кусок бревна, и распилим его на 23 части, каждая часть теперь будет равна 1/23 метра, или что тоже 100 см / 23 = 4.34 сантиметра. Пять таких частей вместе будут равны 4.34 х 5 = 21.7 сантиметрам. Но если мы теперь распилим бревно на более мелкие кусочки, а именно, 23 части умножим на 16, получим 368 частей, вот, - распилим на 368 частей. То в этом случае каждая часть будет равна 100 см / 368 = 0.271 см. И те же пять частей вместе, теперь уже не будут равны как раньше 21.7 сантиметрам, но будут равны 0.271 х 5 = 1.355 сантиметра. То есть умножая на 16, мы уменьшаем размер частички (логической единицы), мы более раздробляем промежуток ширины экрана, мы делаем логическую частичку меньше и меньше, чем больше то число на которое умножаем. Всем спасибо, наконец то!