Changeless,

посмотрите это.

ChangelessВы подошли несколько иначе, однако, в Вашем примере загрузка такая, что даже указатель мыши тормозит и медленно ездит по экрану. Никогда такого не видел!!! У меня P4 1.8 (Northwood), но я думаю что и i7 980 тоже прийдется не сладко. Куда же он расходует столько ресурсов???Нашёл P4 1.8. Да, нагрузка 100%, но мышь не тормозит. На пятилетней давности C2D E6700 нагрузка в среднем 8-9%, причём при самом суматошном дёргании мышкой лишь изредка и на доли секунды множитель проца меняется с энергосберегающего на полный. Это я для статистики.
ChangelessЯ нигде не увидел у Вас таймера.Вставьте таймер. Но события таймера в Access могут перестать приходить при самых простых действиях пользователя.
ChangelessУ Вас потоковое видео?Нет. Экран снимается в битмап в памяти, битмап загружается в элемент управления Image через его свойство PictureData. Кстати, это самая тяжёлая операция. Что ж, вернёмся к копированию с экрана на экран.ChangelessКроме того, не создавая окно, следуя Вашему примеру, мне сложно будет решить проблему "каскада" (т.е. в окне формы Вы будете видеть эту же форму, в окне которой будет она же и так до бесконечности).А как надо?
ChangelessБенедикт, огромное спасибо за mousehook - попробую реализовать у себя. Надеюсь это не он так грузит проц.Грузит, и это ощутимо на слабых машинах. Кроме тогоChangelessне могу заставить нормально работать перехват событий мыши WH_MOUSE_LL (при этом WH_MOUSE - работает без проблем). При включении WH_MOUSE_LL появляются страшные тормоза на форме. Посмотрите на пример во вложении, если кликнуть по форме и зажать ЛКМ, начинает страшно тормозить отрисовка, при этом никаких событий на перехват нет! В чем тут может быть проблема?Некоторые оконные классы Access-а при захвате (capture) мыши, по-видимому, изменяют стандартный цикл обработки сообщений. Это приводит к проблемам и с таймером, и с хуком. В качестве простого-грубого выхода можно предложить принудительное снятие захвата. См. приложение.

Дополнение.
Слабую машинку этот код тоже нагрузит, но эта нагрузка уже более правильная "идеологически", так как, во-первых, убрана тяжёлая обработка из хука, во-вторых, обновление сделано через WM_PAINT, который обрабатывается системой особым образом: когда в очереди нет других сообщений, и слиянием нескольких WM_PAINT (с объединением регионов обновления). Слияние на слабой машине должно выражаться в том, что счётчик Posted растёт быстрее счётчика Processed при интенсивном дёргании мышкой.

Changeless,

Пока просто вопросы.

Нажатие ЛКМ - это штатная операция, т. е. предполагается, что пользователь её должен сделать, или это тестирование на случай, а вдруг он это сделает?
Вы не drag and drop операцию, случаем, хотите реализовать?
Надо ли отслеживать движение мыши за пределами окон данного процесса (точнее, потока)?
Могут ли в процессе работы открываться/закрываться формы?


>Как часто? У меня раз в 50миллисекунд.
В первом примере - при каждом вызове процедуры хука.

Changeless,

да, можно посмотреть этот вариант, ЕМНИП, был на RSDN пример с анимацией, основанный на этом.

По поводу более традиционных подходов возникла идея двигать не окно, а регион отсечения окна. Но краевые эффекты всё равно есть.

Changeless,

"Слоёное" окно перемещается действительно красивее, без лишних "эффектов".