Так чье решение все-таки взял за основу? ;)
Добавлено @ 19:08

Не-а Я вообще контекст не трогаю, просто тупое "таскание" одного окна по другому

Тогда, может, ScrollWindow (как в ScrollView) ?
Та же фигня... Короче, в данном случае (чтобы фон был прибит) придется перерисовывать все окно, потому что функции ScrollЧегоНибудь очень экономно перемещают биты контекста и плевать им, что там - фон, текст. А в данном случае нужно именно тупо перерисовывать окно в другой позиции...

Нет. Там роме SetWindowPos() ни одной функции, что-либо скролирующей =)


Так посмотри в моем коде - так и делается! Окно таскается именно целиком =)
Я вот только не очень понял изначально - хорошо это или плохо? Нужно, чтобы фон гулял вместе с окном, или наоборот, стоял на месте?

Coocky, по-моему, нужно, чтобы фон не двигался.
Значит, твой код ему подойдет.
А вообще, если таких изысков с фоном нет (т.е. окно прокручивается как единое целое), обычно используют ScrollWindow или ScrollDC (это просто копирование той части окна, которая уже есть, но в новую позицию). Плюс, ScrollWindow еще дополнительно делает инвалидными те части окна, которые до перемещения были скрыты. И для них тебе приходит WM_PAINT.
Если делаешь ScrollDC, то это нужно делать руками, но больше управляемость...

Конечно, код получается посложнее, чем просто SetWindowPos. Но если для, скажем, списка какого-нибудь перисовка (а SetWindowPos - это полная перерисовка, как ты понимаешь)... - максимум моргание вызовет (с которым можно побороться), то для окна набитого более-менее сложной графикой (или картинкой смасштабированной), такая реализация скроллинга будет сильно тормозить... А закат солнца вручную (ScrollDC + Invalidate недостающих кусочков) - летает...

Я согласен, но во-первых, можно сделать "умную" перерисовку в OnPaint,отрисовав предварительно все содержимое окна в некий виртуальный битмеп размера, равного таскаемому окну, а во-вторых, от прокрутки обычно диких скоростей перерисовки не требуется, главное, как ты уж упомянула, чтобы не было противного глазу моргания. А подтормаживания скроллбаров работе не вредят (например, вспомним чтение документа в MS Word). Мы один раз тыркаемся в скролл, выставляем область прокрутки на нужную позицию, не сильно обращая внимания на небольшие задержки в скроллировании (а их можно сделать действительно совсем небольшими),и потом долго и упорно читаем текст с данного места.
Добавлено @ 20:48
Вообще, в программировании внешнего интерфейса есть две крайности:
1. Красиво, запутано,но глючно.
2. Строго, быстро, но скучно

Я про графику говорила - рабочий экран программ типа Photoshop, Corel, AutoCAD в конце концов. Кроме того, прокрутка - это не только с помощью скролл-баров, но еще и с помощью мышиного косеса, а также панорамирование (это когда экран как бы таскают за любое место - черт его знает, почему это панорамированием называется). Короче говоря, если в таких программах прокрутка будет тормозить, пользователи повесятся... или закидают тухлыми яйцами аффтара

Ладно, подождем Coocky, послушаем, чем же все-таки закончились его страдания.

Они еще вчера закончились

Че у вас с трафиком? Или я так быстро пишу. что вы не успеваете читать
Вот еще , что хотел спросить.. Про OnIdle.
Она только ж в App перегружается?
Дело в том, при каждом ресайзинге большого окна я перерисовываю две кнопки в правом верхнем углу. Если этого не сделать, то если резко и быстро таскать приложение(растягивать) влево-вправо, то рано или поздго-одна кнопка захватит часть изображения второй. Однако если перерисовывать -все нормально-но Ма-а-аленькое мерцание при растягивании. Я вот подумал, а что если перерисовать после растяжки, т.е. словить отсутсвие сообщения. Но только один раз, вернее когда значение счетчика остусвия сообщений =1
Только вот плохо то, ЧТО б достучаться до кнопки, нужно лезть к ним через указатели.
Как можно решить эту проблему? И вообщем сам способ-хорош?

Ну CScrollView Просто прокрутка там делается ОДНОЙ функцией Ну и твой пример посмотрел и сохранил.
Надо ж знать, как самому крутить. Кстати-ничего сложного, чистая математика. Я просто думал, что окна нужно еще и самому отрисовывать, когда они выходят за рамки окна

Еще в документе.

Но в окнах тоже можно ловить Idle.
В модальном диалоге, в карту сообщений нужно добавить обработчик сообщения WM_KICKIDLE. Это сообщение определено в MFC, нужно подключить afxpriv.h
Кажется, сообщение посылается без параметров, во всяком случае, я никогда их не использовала, и не знаю, что в них. Поэтому получить счетчик отсутствия сообщений не получится. Но можно (и даже лучше) сделать так: завести переменную в классе, скажем, bNeedRedraw, OnSize - ставим ее в 1, OnIdle - проверяем, и если она 1, делаем кнопкам Invalidate и сбрасываем.

Дык откелева у меня модальный диалог? Для моего диалога есть что нибудь похожее? А для беленьких?
Пойми, я хочу в OnIdle сделать переисовку, но как мне достучаться до окон из CWinApp?
А если оттуда нельзя, как же получить похожее на OnIdle в моих классах?

А какой же у тебя диалог? В твоем коде, что я видела - главный диалог модальный и есть. У тебя ведь вообще диалоговое приложение. Остальные диалоги - вложенные child'ы. Им ничего такого не приходит - значит, нарисуй соответствующую функцию у контейнера и вызывай из главного диалога. А главному - должен приходить WM_KICKIDLE, как я и говорила.

Для справки: для немодальных окон тоже есть свое сообщение:
WM_IDLEUPDATECMDUI, расылается из App как раз на Idle. Но это только для SDI или MDI приложения.

А ну да

Че-то я и в МСДН толком ничего не найду по этому сообщению.
Как его определить?

Coocky



и т.д.
А послать сообщение можешь вообще накрайняк всем, зарегистрировав его... Или Взведи евент, а по нему отрисовывай отдельно каждое окно. А лучше просто (диалоги то надеюсь объявляешь во фрейме документа?) взять да послать WM_PAINT каждому аля ::PostMessage(pFrame->mydlg[7]->GetSafeHwnf(),WM_PAINT,0,0) или напрямки pFrame->mydlg[7]->Invalidate(). А если я не в тему, то уж не обессуть

Да у меня окно диалоговое Какие фреймы