Antonshka

Я тоже английскую версию читал. Я с некоторого времени вообще не могу читать русские. На днях смотрел про "1C", про встроенный там язык Перем количествоЦветов; Перем разрешениеЭкрана; Если количествоЦветов < 256 Тогда разрешениеЭкрана = 1024; Иначе разрешениеЭкрана = 1920; КонецЕсли; А веди те для кого английский родной так и видят свой код. Но для меня это тяжело. Про комментарии я помню он писал что да, в некоторых случаях они полезны, но я воспринял это как лучше их совсем не писать. Лучше да, чтобы сам код за себя говорил.

Почитал "Чистый код", почитал про паттерны. Заново переписываю уже написанное. Особенно понравилось про комментарии, - я так ленился их писать. А согласно книге, они есть признак грязного кода. Недавно прочитал Рихтера, и хотел было реализовывать многопоточность для GUI, но, сегодня наткнулся на этот материал. Согласно ему, лучше использовать только один поток для управления всем GUI. Что не может не радовать. Для других потоков, которые буду использоваться для серьезных расчетов, буду использовать PostThreadMessageW, или другие подобные, для отправки сообщения контролу в главные GUI поток. Надеюсь что план правильный.

Я когда-то делал что-то подобное для игры Dirt 5. В определенный момент загрузки карты в определенной игровой функции мне нужно было считать бинарный файл в память игры. Нужно чтобы в игре была загружена библиотека, в которой находится нужная функция, иначе прежде придется загрузить еще и DLL для нее. Для понимания как и какие параметры передавать, я писал на С++ образец WinAPI ReadFile, компилировал, запускал, подключал CE. Далее находил вызов, сверял с соглашением x64 calling convention, и уже после пробовал написать подобное для игры. После возврата из некоторых WinAPI функций могут изменяться XMM регистры не входящие в состав параметров. Для этого до вызова функции нужно сохранить их значения отдельно в памяти, потом после вызова восстановить.

Последний вариант мне пригляделся больше. Ты имел ввиду GetDIBits функцию? Я пытаюсь сделать меню как в Maya 3D, по внешнему виду и функционалу. Там оказывается при наведении на пункт меню иконка еще и подсвечивается, то есть становиться ярче. В интернете нашел две теории как сделать иконку ярче. Первая это через умножение каждого канала на множитель. Вторая это перевод RGB в HSV, затем изменение V (яркости), и затем обратный перевод HSV в RGB. С HSV не вышло, даже без изменения V некоторые цвета становятся другими. Я пробовал два разных исходника. Результат один и тот же. Пришлось использовать множитель. С ним цвета нормальные. Это некоторые методы для иконки

Это верно. Мне был интересен сам подход. Самый быстрый и лучший. Так как я полагал что существует несколько подходов. Через CompatibleDC например, или возможно напрямую как-нибудь.

Привет всем, никто не сталкивался с такой задачей? Пользователь, для пункта меню, предоставляет только цветную версию иконки (для удобства). Метод "Добавить пункт" класса "Меню", автоматически создает ее черно-белую версию. Она будет рисоваться когда пункт меню будет выключен. DrawState из WinAPI хоть и умеет делать из цветной иконки черно-белую, но результат не всегда хороший. Поэтому сейчас ищу наиболее лучший и быстрый способ конвертации. Основная идею конвертации это изменение RGB значения каждого пикселя изображения на определенное значение. Как появится первый рабочий вариант, то обязательно его выложу.

Попробуй заинжектить на "push rdi" свой АА скрипт. В нем самостоятельно сравнивай значение rdi. А там уже, на своей ветке, делай трассировку.

Из своего опыта могу сказать что через cmp сравнение float работает некорректно. Особенно если float имеет отрицательное значение. Я использовал fpu. Из старого трейнера - fld dword ptr [Camera_Original_Pitch] fcomp dword ptr [Mouse_Screen_Y_Min_Value] fstsw ax sahf jae @f

Тоже хотел попробовать себя в этой задаче. Есть даже своя нестандартная идея. Стандартная как понимаю это R-дерево. Но, мне нужно доделывать начатое.

Я читал об этом в книге Щупака. Про сообщения, очередь, GDI. У него все это изложено в более краткой форме. Также сам Щупак пишет что он учился по книгам именно Юаня, Рихтера, и других. Я часто замечал почти буквальное повторение частей текста из книг Юаня, Рихтера, в его книге. А у тебя программа может определить любой город на планете? И даже если это небольшая деревня? Сколько времени нужно программе чтобы определить название города?

Пока что библиотека работает на одном основном потоке. И если этот поток будет занят, то обновления интерфейса не будет. Это минус конечно. Ранее в книге Щупака я читал про способ с PeekMessage. Думаю буду использовать его. Это да, тут нужно быть внимательным. Особо я пока не задумывался над этим. Многопоточность я проходил, когда читал книгу Щупака и тестировал примеры. Но в библиотеке она пока не реализована. Но в планах и во внимании она есть. Мне кажется что на разработку этой библиотеки у меня уйдет не один год. Но в начале я полагал что это лишь на несколько месяцев. Постоянные переделки, улучшения. Но мне это нравится, поэтому не тягостно.

Максимально быстро это круто. Я тоже добиваюсь максимально быстрой работы библиотеки. Вчера разработал схему, при которой обновляются только те окна и разделители, которые изменили свои размер или положение. Проверяется это прежним и текущим положением, но без вызовов и запросов текущей позиции. Никаких GetClientRect/GetWindowRect для любого окна. Только один раз, для главного. Дальше простая математика. От этого теперь нет ни единого лага. Никаких лишних вызовов функций или методов, там где это возможно. Никаких лишних выделений и освобождений памяти под локальные переменные. Лучше добавлю в класс переменную, чем в метод.

Звучит интересно. Но почему нельзя использовать внешние сервисы? Чтобы приложение могло работать без интернета? Первое что мне приходит на ум, для решения такой задачи нужна база данных. Это как с окнами, например, нужно определить находится ли курсор мыши в области какого-либо определенного окна. Или над каким окном находится сейчас курсор. Так как территория города не имеет четкой прямоугольной формы, то полагаю ее нужно разбить на множество небольших прямоугольников, и по ним сравнивать. Нужна база данных этих прямоугольников, и к каким городам они относятся.

В библиотеке что я указал выше, есть возможность использовать MDI интерфейс. Я смотрел как-то ранее на MSDN его суть, - не приглянулся. Стоит ли вообще пытаться его реализовать? Если в той библиотеке какую я хочу написать, будет Dockind система, с опцией Tabbed document interface. Также возможно и Collapsible система. Словом если будет IDE-style interface. Не пойму зачем автор вышеупомянутой библиотеки его реализовал. Чтобы просто был, или и правда есть в нем какое-то удобство. Честно говоря, я прочитал все MSDN руководство по MDI, и не увидел каких-либо особых фишек. Все тоже самое, кажется, можно сделать и с SDI, не говоря уже о IDE стиле.

Доделал перемещение полосок-разделителей. Все хорошо, но видны лаги, небольшие. Скачал DXDO, для WPF, для создания Docking, создал такое же количество окон, - лагов нет. Как понимаю, это потому что WPF отрисовывает через DirectX. Нашел интересную C++ GUI библиотеку, в которой есть Docking. Она не на DirectX. У нее тоже заметно небольшие лаги. Понятно, лучше уже не сделать значит. После того как увидел что кто-то уже сделал подобную моей библиотеку, желание доделывать свою, никудышную, немало так угасло. Но ничего, продолжу.

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

Это Anchor система? У тебя есть видео работы этой системы? Или может скрины, нескольких этапов.

У меня на очереди была книга Рихтера. Добавлю и эти к ней. Спасибо. Не могу отложить код, он не завершен. Доведу до рабочего состояния только Docking, и приступлю к книгам.

Похоже я снова напутал. На самом деле у меня родитель только перебирает своих потомков, а они уже сами изменяют свои свойства, - размер и положение. Примерно так currChildCnt = parent->childT; while (currChildCnt) { currChildCnt->bottomDiv->Top = ... currChildCnt = currChildCnt->brotherAtRight; } Я часто путаюсь, извиняюсь.

Кажется теперь я понял, что ты имеешь ввиду. Действительно, у меня сейчас не так, как ты пишешь. У меня окно-родитель/контейнер-родитель, после изменения своего размера, начинает перебирать всех своих личных потомков (непосредственных), корректируя их размеры, а те, после корректировки, делают тоже самое со своими личными потомками, и так до самого последнего потомка, для этой ветви. Как мне кажется, по сути это ни чем не отличается от твоего варианта. У тебя сами личные потомки должны как-то отреагировать на событие, причем они должны соблюсти еще и последовательность, - вначале самый крайний изменяет свой размер, затем по очереди соседи, так как сосед справа равняется на соседа слева. При моем же способе, родитель просто перебирает своих личных потомком, начиная с крайнего, - никаких забот со стороны личных потомков о последовательности нет. Что-то вроде урока физкультуры, - учитель говорит "равняйсь", а ученики по очереди начинают равняться друг на друга. Что плохого в этом моей способе?

Вначале я делал сплиттер из статического текстового контрола, перехватывая WM_PAINT и заполняя цветом фон. Но, способ оказался глючным. Неполное закрашивание. Сейчас сплиттеры это простые окошки, как ты пишешь. Вообще да, лишние телодвижения ни к чему. Сейчас полный перебор дерева происходит только при изменении размеров главного окна, когда в любом случае все окна и контейнеры нужно как-то корректировать. При смещениях полосок, - я пока не знаю как это все будет. Я только сейчас начал заниматься ими. Надеюсь будет достаточно изменить только размеры нижележащих потомков. Все упирается в эти полоски, точнее в эти относительные размеры потомков к их родителю. Кстати Imgui в этом плане не следит за оставшимися промежутками между окнами при полном их сжатии. Видны разные по ширине промежутки, это некрасиво. Также в Imgui неудобно изменять размеры окон при перетаскивании полосок. В VS при перемещении полоски родителя, вообще все потомки также смещаются, и это удобно, в Imgui же не так, в Imgu изменяется размер только соседнего окна, и при вставке нового окна с внешней стороны, то есть в главное окно, приходится каждое окно обратно возвращать на свое место, вместо того чтобы взять и один раз сместить полоску нового вставленного окна. Не знаю, зачем он так сделал.

У меня почти так. Каждая полоса-разделитель имеет в своем классе указатель на то окно, с которым она ассоциирована. А окно в свою очередь, имеет указатель на контейнер, с которым оно ассоциировано. При смещении полосы, изменяется размер контейнера, а затем, по всем правилам, нужно было бы подкорректировать размеры всех нижележащих контейнеров-потомков, как ты пишешь. Но, у меня не так, в моем случае я беру самый корень дерева, и корректирую размеры вообще всех контейнеров. Это конечно не правильно, это излишне. Но я так делаю вот по какой причине. После сжатия, контейнер 2 будет сжат не до конца, так как он имеет больший шаг/относительную степень своего размера по отношению к родительскому. Для того чтобы этого не было, чтобы все контейнеры сжимались до конца, мне приходится вызывать функцию выравнивания для всего дерева вообще. Я нигде не смог найти алгоритма, по которому можно сделать Docking систему, вообще ноль информации. Есть уже готовая система и исходники, для Imgui, но во первых она работает коряво, мне не нравится поведение окон, во вторых я не могу разобраться в коде, что там и к чему. Есть еще своя родная Docking система в Imgui, но там я тоже не могу разобраться в коде, что там и к чему. Мне проще было придумать и написать свою, двигая и анализирую окна в VS. Про шаблон подписки я прочитал, видел и код примера. Что по поводу рекурсивной функции, для задачи поста? Есть ли возможность использовать ее, или оставить очередь?

Я опять извиняюсь за свою косноязычность. Я неправильно нарисовал схему. Я не написал что братья сами также являются потомками. Просто метод построения произвольного дерева, согласно этому источнику, - у узла-родителя есть один потомок, самый левый, а у этого самого левого потомка, братья. Эти браться являются также потомками этого родителя, но связь с родителем идет через самого левого потомка. Вот, а у меня, два потомка, "самых левых", у родителя, с братьями у каждого. А так, если вернуться к задаче этого поста, то нужно взять дерево, и для всех узлов-родителей, найти количество их потомков. Вот что в ответе должно быть: - Узел 1, имеет 4 узла М и 3 узла Ж - Узел 2, имеет 1 узел М и 1 узел Ж - Узел 3, имеет 1 узел М - Узел 4, имеет 1 узел М и 1 узел Ж Самому тяжело это все реализовывать, сам удивляюсь этой сложности. Но как я писал ранее, слишком много разных взаимодействий и влияний одних окон на другие, при вставке, изменении размера главного окна. Чтобы сохранялись/восстанавливались пропорции. Пока я не начинал писать код, мне тоже казалось что будет легко. Но на самом деле, там все по хитрому. На видео видно что вначале уменьшаются внутренние контейнеры. Причем нужно учитывать сколько потомков ниже, чтобы оставить место именно для стольких полос-разделителей, сколько их находится ниже, в дереве.

Суть задачи в том, чтобы после добавления в дерево нового узла, обновить для каждого родителя в этом дереве количество его потомков. Вот схема обычного произвольного дерева, в моем представлении На этой схеме, у родителя может быть только один потомок. Родитель и потомок могут иметь своих братьев. Тот потомок или брат, у которого есть свой потомок, является также и родителем. Но в моем случае, мне пришлось сделать так, что у родителя может быть и два потомка (максимум). Более того, родитель у меня может быть двух видов, V и H. - У родителя V могут быть только потомки типа L и R. - У родителя H могут быть только потомки типа T и B. - У родителя L или R могут быть только потомки типа L. - У родителя T или B могут быть только потомки типа T. Это так я составил схему, алгоритм, по которым работает Docking система Когда я добавляю или удаляю окно в Docking систему, мне нужно пересчитывать количество потомков для всех узлов-родителей во всем дереве. Сейчас перерасчет работает при помощи очереди. Особо не видно чтобы тормозило, но не знаю, может с рекурсией будет и быстрее. А так, все работает как надо. Остались мелкие доработки. Рисовать заголовки у окон, кнопки на них, и т.д.

Получается что каждый узел-родитель должен вызвать для себя рекурсивную функцию подсчета собственных потомков? Каждый раз обходя дерево, начиная со своего личного уровня и до самого нижнего? Я никак не пойму тот код на Kotlin, потому не знаю даже того алгоритма. Но если так, как я написал выше, то не получится ли что некоторые узлы будут посещаться более одного раза? P - это узел-родитель. Ветвь на рисунке слева, где 35 сравнений, это при рекурсии. Где 10 сравнений, это при использовании очереди, без рекурсии. 35 или 10 сравнений, это сравнения "if", на то какого типа данный узел. Помимо всего прочего, при рекурсии, нужно же еще обойти дерево для определения кто есть узел-потомок, чтобы вызвать для него/них рекурсивный подсчет? Я не совсем понимаю что такое коллекция. Это контейнер с одним потомком и одним братом? Если так, то у меня ситуация немного иная, - у меня у родителя может быть два разных потомка, у которых имеются свои братья, числом более одного. Например, родитель имеет потомка childL и childR, но childL и childR между собой не братья, хотя у них и один родитель. У childL и у childR есть свои братья, много братьев. И childL и childR и их братья, сами могут быть для кого-то родителями. И так далее.