[WINAPI] Print screen przysłoniętego okna

0

Witam.

Napisałem funkcje do robienia print screena.

Wygląda ona tak:

HBITMAP MakePrintScreen()
{
      HWND hWindow = GetDesktopWindow();
      HDC hdcScreen = GetDC(hWindow);
      RECT rect;
      HBITMAP hbmC;
      
      GetClientRect(hWindow,&rect);
      
      if((hbmC = CreateCompatibleBitmap(hdcScreen,rect.right,rect.bottom)) != NULL)
      {
            HDC hdcC;
            if((hdcC = CreateCompatibleDC(hdcScreen)) != NULL)
            {
                  HBITMAP hbmOld = (HBITMAP)SelectObject(hdcC,hbmC);
                  
                  BitBlt(hdcC,0,0,rect.right,rect.bottom,hdcScreen,0,0,SRCCOPY);
                  
                  SelectObject(hdcC,hbmOld);
                  DeleteDC(hdcC);
            }
      }

      ReleaseDC(hWindow,hdcScreen);

      return hbmC;
}

działa bardzo dobrze.

jednak muszę teraz napisać funkcje do robienia screen'a danego okna, z filtrowaniem przysłaniania przez inne okno.

więc jak moge pobrać bitmape(zrobić screena) przysłoniętego przez inne okno okna tak?

z góry dziękuje za pomoc

Dodane:

Chce to zrobić bez odsłaniania danego okna (bez używania funkcji np. SetActiveWindow)

0

Nie da się.

0

A gdyby dać hooka na BitBlt każdego okna?

0

to moze juz predzej lapac podniesienie/opuszczenie/aktywacje okna i w tym momencie przed nia zrzucac i cacheowac wyglad okien zakrywanych... ale to i tak Ciebie nie ratuje w przypadku ogólnym poniewaz jak jakies okno przykryte bedzie sobie podspodem animowac cokolwiek, to tego nie zlapiesz.. chociaz moze i rzeczywiscie bitbltem to wylapiesz.. ale czy to nie zarznie kompletnie systemu?

0

Nie da sie, poniewaz dla przyslonietego okna (o ile nie jest oknem LayeredWindow ani przez takie nie jest przysloniete) system moze nie przechowywac obrazu (oszczedza pamiec, ale kosztem tego z odslonieciem wymaga odmalowania). Co najwyzej mozesz zapamietac obraz sprzed przysloniecia.

0

przecież można pobrać HDC każdego okna
i samemu odpowiednio narysować każde okno na jednej bitmapie w kolejności Z order (albo i na podstawie twojego własnego Z order),
oczywiście to, które okna miały by być rysowane, będzie zależeć od twojego filtru
nawet z GetWindowRect masz koordynaty względem screena, więc masz wszystko czego ci potrzeba, bez żadnych konwersji masz wzajemne położenie okien.... tylko teraz je odpowiednio narysować...

jak nie o to chodzi, bo nie zrozumiałem czegoś to sory

0

Już tak wczesniej probowalem, tylko jezeli okno jest przysloniete po pobraniu hdc okna i skopiowaniu bitmapy kopiuje sie to łącznie z przyslonietym fragmentem.

Powiedzmy ze zaslonie ekran wielkim niebieskim oknem, będe chcial zrobic aktualnego screena, bez tego okna i bez odslaniania go, wtedy przy skopiowaniu bitmapy kazdego okna skopiuje się część zasłonięta.

chyba ze zrobic tak ze jakbym pokolei skanowal okna to bym wywolal komende odrysowania danego okna i przechwycil bitmape za pomocą hooka bitblt (hooka aktywowal bym tylko wtedy gdy zarzucilem komende odrysowania okna)

0

Większość okien jest tak zaprojektowana, że odrysowuje tylko swój widoczny fragment aby niepotrzebnie nie marnować zasobów. Tak więc skopiować można tylko to co jest widoczne, bo tylko to jest malowane. Jeśli jakaś kontrolka jest przysłonięta to jej procedura rysująca w ogóle nie jest wołana i żaden hook na to nie poradzi, bo nie ma co hook'ować.
Można odtworzyć układ okien o czym crayze pisał, ale będzie to tylko coś w rodzaju szkicu.

0

to moze ja ponowie pytanie zadane miedzy wierszami - bo zielony jestem w tej kwestii*) - a co, jesli wpiac sie do metod blittingu/kopiowania bitmap/etc wszystkich okien, i w momencie odpalenia naszego hooka, PRZED faktyczna operacja kopiowania pikseli okna przesuwanego na inne XY (czyli mini/maxymalizowanego, przesuwanego, resizowanego, etc), zrzucic aktualny stan docelowego miejsca ekranu do wlasnego bufora, niesystemowego, i zwiazac ow wycinek(i) obrazu z oknem(i) wykrytym(i) na tym obszarze? chorrendalnie pamieciozerne, nie potrafiace poradzic sobie z animacja okien backgroundowych, ale -- teoretycznie dajace mozliwosc odtworzenia wygladu okna przyslonietego w postaci takiej w jakiej bylo w momencie zasloniecia go?

*) mowie ze jestem zielony, poniewaz nie przychodzi mi na mysl zadne miejsce w typowym cyklu zycia/przetwarzania komunikatow okna ktore mozna by sie wczepic zeby zlapac -wszystkie- potencjalne operacje zamazania innego okna..

0

Hmm, ale mi wlasnie chodzi o to zeby pobrac obraz AKTUALNY okien, to co jest w danej chwili a nie przed zaslonieciem okna.

pozdrawiam

0

juz Ci powiedziano: w ogolnosci, nie da sie, poniewaz dla aplikacji napisanych bezblednie, ich zasloniete okna w ogole nie rysuja sie ani nie aktualizuja swojej zawartosci

hym. taka mysl: da sie oszukac okno by sadzilo ze jest widoczne, mimo ze nie jest? jakie wiadomosci do niego sfingowac, albo jakie funkcje winapi spatchowac aby zwracaly falszywe wyniki.. no tak.. a co z .net.. chociaz jak nie WPF to w tle i tak z winapi korzysta, a jak WPF to mozna probowac oszukac okno-hosta...

0
quetzalcoatl napisał(a)

hym. taka mysl: da sie oszukac okno by sadzilo ze jest widoczne, mimo ze nie jest?

Teoretycznie wywołanie InvalidateRect oraz wysłanie WM_PAINT załatwia sprawę, okno powinno się odmalować. Tylko co hook'ować skoro kontekst okna nie będzie przenoszony na kontekst ekranu? Wszystkie funkcje działające na HDC?

0

Można przechwycić BeginPaint+EndPaint i podać własny HDC. Opcjonalnie można też przechwycić GetDC, GetWindowDC oraz ReleaseDC na czas obsługi WM_PAINT, podając to samo HDC co w BeginPaint. Dobrym krokiem jest też przechwycenie GetUpdateRect w razie gdyby kod docelowego okna sprawdzał czy jeszcze coś jest do odrysowania (oprócz paintstruct.rcpaint).
Zaraz po zainstalowaniu inline-hooków tworzymy HDC z odpowiednio dużą bitmapą, wysyłamy WM_ERASEBKGND i WM_PAINT do docelowego okna i jego potomków, a następnie usuwamy hooki.

0
sapero napisał(a)

Można przechwycić BeginPaint+EndPaint i podać własny HDC.
No właśnie z tym podaniem własnego HDC nie wiem czy będzie tak łatwo. Próbowałeś? Wydaje mi się, że bitmapa i kontekst który podmienimy będą musiały być utworzone w kontekście procesu który hook'ujemy.

0

Tak, mój program wlasnie sie opiera na pliku dll wstrzykiwanym do kazdego procesu.

Zaraz przetestuje wszystko to co tu napisaliscie

0

Zgadza się. Sam fakt istnienia hooka tego wymaga, jeśli by pominąć hookowanie poprzez zdalną obsługę wyjątków za pomocą chwilowego debuggowania.
Jeżeli napiszę gotowca, to co to będzie za frajda dla innych?
Ja bym to zrobił w dll'u ładowanym z AppInit_DLLs. Wątek uruchomiony w dllu by oczekiwał na zmiany w pewnym kluczu rejestru (RegNotifyChangeKeyValue) skąd by wiedział które okno ma odrysować, a bitmapę mógłby przesłać przez socket, plik, lub przez coś równie prostego.

0

Jak kiedyś musiałem zrobić coś takiego, to zapamiętywałem obecny z-order (czy jak to tam było) aplikacji, dawałem ją na wierzch, robiłem zdjęcie, przywracałem.

0

@up.

Pisałem już w poprzednich postach, że NIE chce odkrywać okna.


Założyłem hooka na BeginPaint, GetDC, GetWindowDC.

i w każdych tych funkcjach podmieniałem DC na inny (swój) dla testu i tam sprawdzałem czy HWND należy do procesu kalkulatora (calc.exe)

chciałem żeby kalkulator nic nie mógł narysować.

Ale wyszło cos takiego:

http://img405.imageshack.us/i/16098617.jpg/

Skoro zablokowałem dostęp do rysowania, to dlaczego jest menu Edycja, Widok, Pomoc,

albo takie 2 przyciski i tło?

w ogóle dlaczego widać pasek z zamknięciem oknia, zmaksymilizowaniem itd?

To do rysowania tego nie jest wykorzystywane HDC?

To co jest do tego wykorzystywane (i do malowania tła) ?

0

Zacznijmy od tego, że w WM_PAINT rysyjemy tylko obszar klienta. Ramka wyniku i te dwa kwadraty są rysowane w WM_NCPAINT. Belka, ramka okna i menu w WM_NCPAINT, WM_NCACTIVATE, WM_NCMOUSEMOVE... choć menu może być rysowane też w WM_DRAWITEM, o ile jest 'ownerdrawn'.

Co do funkcji z HDC, to jeszcze są GetWindowDC i GetDCEx.
Sprawdź czy PrintWindow lub WM_PRINT, WM_PRINTCLIENT nie wystarczy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1