при попытки перерисовать окно UpdateWindow или PostMessage,WM_PAINT... соденжимое окна не меняется ( данные для отображения зависят от состояния переменных ) причем управления на соответствующую часть WndProc передается. с чем это может быть связано?
darklight Вариантов море и перебирать их все тут просто лень. Чтоб получить более конкретный ответ, сначала давайте сюда ваш исходник.
Дабы не поднимать новых тем, будем додалбливать эту Ж). Итак, имеется следующая ситуация: Рисую на контроле картинку, на WM_INITDIALOG гружу картинку, на WM_PAINT отрисовываю, всё работает. Но стоит запустить какое-нибудь полно-экранное приложение и картинка пропадает, отрисовывается она только если окно увести за край экрана. Вот код: Код (Text): local paint PAINTSTRUCT local rect RECT invoke GetDlgItem, [hwnddlg], 1004 mov ebx, eax invoke GetClientRect, ebx, addr rect invoke BeginPaint, ebx, addr paint mov ebx, eax invoke CreateCompatibleDC, ebx mov esi, eax invoke SelectObject, esi, [hDC] ; в hDC загруженная картинка mov edi, eax invoke BitBlt, ebx, 0, 0, [rect.right], [rect.bottom], esi, 0, 0, SRCCOPY invoke SelectObject, esi, edi ; мне кажется это лишний вызов invoke DeleteObject, edi ; нужно ли удалять объект для освобождения хендла? invoke DeleteDC, esi invoke GetDlgItem, [hwnddlg], 1004 invoke EndPaint, eax, addr paint Я нашел временное решение, если в Begin\EndPaint в качестве хендла указывать хендл основного окна (то есть рисовать на окне, а на на контроле), то все работает отлично. Правда в этом случае необходимо корректировать координаты вывода изображения. Может кто-нибудь прояснить что нужно сделать, чтобы нормально рисовать на контроле, и из-за чего вообще происходит описанная выше проблема?
Ну не знаю в чем проблема, но я отрисовываю без Begin\EndPaint.. Если надо могу приаттачить работающий пример на FASM'е...
Конечно "приатачь", интересно посмотреть как реализовано. Ещё у меня попутно дополнительный вопрос, не относящийся непосредственно к теме - где можно достать примеры как рисовать свои окна (со своим "скином"), как это часто делают в различных кейгенах и кряках? Смотрится эффектно. Вот что нибудь вроде этого -
axe_roma Ааа, вот спасибо. Правда в выложенных примерах не нашел того что искал, а некоторые вообще отказались работать, но через информацию в архиве вышел на страничку автора, там есть рабочие шаблоны. Но вот первый вопрос всё-же остался без ответа пока. В ходе экспериментов, нашел немного нестандартное решение. Если в начале обработчика WM_PAINT вызвать DefWindowProc, то контрол не стирается. Делаю вывод - что по видимому я не делаю какой-то дополнительной обработки, которую за меня делает DefWindowProc, но пока что то не могу врубится какую.
HeadHunter Не верна сама идея рисовать "из вне" на стандартном контроле, который предназначен для того чтобы отрисовываться самостоятельно (и есно затирать твоё "творчество"). Либо юзай штатные средства контрола (типа STM_SETIMAGE). Либо замени его на своё дочернее окно (или субклассируй контрол) и тогда рисуй по WM_PAINT контрола/дочернего окна, а не родительского. как раз потому, что ты заставляешь его прорисоваться до своих извращений, а не после них.
Если требуется только рисование в дочернем окне (ДО) - то самое простое - это ставим простую кнопку на диалог и делаем ей стиль BS_OWNERDRAW. И далее рисуем по сообщению WM_DRAWITEM в функции (DlgProc) диалога. Если данные поменялись (для ДО), то просто делаем InvalidateRect() ДО и WM_DRAWITEM вызовется автоматически.
darklight вам надо создать так же bitmap и рисовать через совместимое устройство на него, а потом выводить через обычное устройство в окно, но битмап и совместимый dc надо создавать в create и уничтожать в destroy.
Y_Mur Ааа, клас, клас, клас. Очень развёрнутый ответ, помог "STM_SETIMAGE", и никаких заморочек с WM_PAINT. Насчет затирания я догадывался, но в ходе своих экспериментов получал разные результаты, что сбивало с толку. Теперь всё прояснилось, спасибо. AsmGuru62 Ага, тоже понял ход мысли, учту. tex32 Не, как раз таки размещение DefWindowProc в конце процедуры не давало результата, вернее оно его окончательно аннулировало Ж). В общем Y_Mur уже ответил что да как. max7C4 Да не, все в порядке, все совместимо, нюанс был в другом. Ну собственно он решён благодаря откликнувшимся. Прям не ожидал такого количества ответов, думал совсем эта ветка мхом поросла Ж).
max7C4 О блин, не посмотрел что ответ был дан darklight. Думаю спустя 4 года ему уже не интересно что тут пишут Ж). Я просто поднял старую тему, что бы не создавать новой.
