Bildschirmfoto knipst nicht alles

[KodeZwerg]

Zum einen, ich Zeichne nichts ich knipps und Speicher. Es ist mittlerweile eine Tray-App ohne Fenster, nur Popupmenu.
Ok das ist etwas gelogen, es erscheint eine Prozess-Liste mit allem was ich knippsen könnte.

Was ich wollte macht es, ich wollte ein Window knippsen und mit FullWindow steuert man ob mit Fenster-Rahmen oder ohne, Du wirst da keinen Unterschied feststellen da Deine SkinEngine kein Windows-Rahmen besitzt.

Ich übersetze mal Dein Code nach Delphi und lasse mich Überraschen. Danke dafür!:thumb:

Das Lock/Unlock habe ich einfach mal mit integriert, Danke Zacherl für den Hinweis!:thumb:

Zitat:

Zitat von EWeiss (Beitrag 1403328)

Weil es nur mit einem Fenster richtig funktioniert in dem auch alle dafür benötigten Messagen korrekt verarbeitet werden.

Ich weiß nicht so genau wie Du das mit Messages meinst, könntest Du das bitte ein wenig Erläutern oder eine Quelle zum nachlesen angeben, Danke!

[EWeiss]

Zitat:

Ich weiß nicht so genau wie Du das mit Messages meinst, könntest Du das bitte ein wenig Erläutern oder eine Quelle zum nachlesen angeben, Danke!

Was für eine Quelle?
Die Quelle ist meine Erfahrung..

Und was Windows Messagen sind muss dir doch klar sein.
Google mal nach WM_PRINT und WM_PRINTCLIENT zum Beispiel in Verbindung mit AnimateWindow ;)

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1403350)

Google mal nach WM_PRINT und WM_PRINTCLIENT zum Beispiel in Verbindung mit AnimateWindow ;)

Wenn AnimateWindow verwendet wird, muss das Fenster WM_PRINTCLIENT eigenständig implementieren. Ansonsten ist das alles kein Problem, da WM_PRINT bei Standardeinstellungen von der DefWindowProc abgearbeitet wird. Der Entwickler muss hierfür nicht wirklich etwas Eigenes implementieren.

Dennoch ist die Desktop Duplication API wie gesagt sowohl dieser Methode als auch dem Kopieren des DC Inhaltes jederzeit vorzuziehen. Wenn man noch kein Windows 8 verwendet, steht diese halt leider noch nicht zur Verfügung.

[KodeZwerg]

Da schau an, nun weiß ich was Dir dabei im Kopf rumgeflattert ist, das gibt mir Anlass das ganze nochmal zu Überdenken, bei Deiner Roten Schrift Post dachte ich so etwas in der Richtung:
Wenn eine Applikation kein WM_PRINT o.ä. anbietet dann wird nichts aus Foto. Da meine Eigenen Programm diese Msg bis jetzt noch nie verwendet haben, testete ich es und knippsen ging. Der Nebel ist auf jedenfall gelichtet, many thanks!:thumb::thumb:

Was mir jetzt wiederum durch den Kopf spukt, bei meinem ersten Post, da kopiere ich ja das DC und erhalte Bilder wo halt Sachen fehlen, nicht generell aber mal hier mal da. Wenn das kompilat mit Deiner Methode nicht zu groß ist, könntest Du es bitte zu Testzwecken bereitstellen, da seh ich ja gleich was mich erwartet und das wichtigste, ob es den Inhalt tatsächlich so knippst wie ich ihn aufm Desktop sehe. Siehe erster Post das Bilder-Knipps-Problem.

Nun bin ich ehrlich gesagt mehr als verwirrt.....

[EWeiss]

Zitat:

Was mir jetzt wiederum durch den Kopf spukt, bei meinem ersten Post, da kopiere ich ja das DC und erhalte Bilder wo halt Sachen fehlen,

Du kopierst aber genau das sollst du nicht tun..
Es hat damit zu tun weil du WM_PAINT zum zeichnen verwendest und nicht das zur Verfügung gestellte DC in WParam..
Wenn du WM_PRINT verwendest must du kein extra DC erstellen denn es ist vorhanden.

Zitat:

Wenn AnimateWindow verwendet wird, muss das Fenster WM_PRINTCLIENT eigenständig implementieren.

genau das mag unter VCL seine Bestimmung haben aber nicht unter Win32 glaube es mir schließlich habe ich die AnimateWindow Funktion in
meine NONVCL Lib integriert und das ist kein Spielchen.

Aber gut sei's drum.
https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1403358)

Aber gut sei's drum.
https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx

Hast du ja Recht im Falle von

Delphi-Quellcode:

WM_PRINTCLIENT

. Die normale

Delphi-Quellcode:

WM_PRINT

braucht man aber explizit nicht selbst implementieren.

Delphi-Quellcode:

PW_CLIENTONLY

könnte demnach Probleme machen, die Variante mit Rahmen allerdings nicht.

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1403364)

Zitat:

Zitat von EWeiss (Beitrag 1403358)

Aber gut sei's drum.
https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx

Hast du ja Recht im Falle von

Delphi-Quellcode:

WM_PRINTCLIENT

. Die normale

Delphi-Quellcode:

WM_PRINT

braucht man aber explizit nicht selbst implementieren.

Delphi-Quellcode:

PW_CLIENTONLY

könnte demnach Probleme machen, die Variante mit Rahmen allerdings nicht.

Korrekt!
Solange man nicht mit NonVcl Arbeitet denn da gibt es nur das man explizit definiert. :)
Das ist in C++ genauso wenn du kein WM_PRINT in deiner Winproc einbindest tut sich da auch nichts.

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1403366)

wenn du kein WM_PRINT in deiner Winproc einbindest tut sich da auch nichts

Sicher? Bin etwas verwirrt von dem MSDN Auszug hier:

Zitat:

Unlike WM_PRINT, WM_PRINTCLIENT is not processed by DefWindowProc

Das verstehe ich so, dass

Delphi-Quellcode:

WM_PRINT

auch ohne eigene Behandlung von DefWindowProc abgearbeitet wird. Letztere sollte man ja meines Wissens nach immer Aufrufen, wenn man keine eigene Behandlung für eine Message implementiert.

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1403368)

Zitat:

Zitat von EWeiss (Beitrag 1403366)

wenn du kein WM_PRINT in deiner Winproc einbindest tut sich da auch nichts

Sicher? Bin etwas verwirrt von dem MSDN Auszug hier:

Zitat:

Unlike WM_PRINT, WM_PRINTCLIENT is not processed by DefWindowProc

Das verstehe ich so, dass

Delphi-Quellcode:

WM_PRINT

auch ohne eigene Behandlung von DefWindowProc abgearbeitet wird. Letztere sollte man ja meines Wissens nach immer Aufrufen, wenn man keine eigene Behandlung für eine Message implementiert.

Es nutzt dir nur nichts.
Es kann abgearbeitet werden nur wenn du mit dem DC von wParam nichts tust und sogar im gleichen Kontext noch WM_PRINT verwendest dann ist es sinnlos.
Ich habe alles durch und bestimmt 3 Tage gebraucht um AnimateWindow unter NonVcl ans laufen zu bringen.

Wenn ich dies Message nicht zu meinem eigenen Window schicke passiert gar nichts.
Mein Window ist in diesen Fall schwarz.

Delphi-Quellcode:

procedure TSkinEngine.PaintDoubleBuffer(WinHandle: hWnd; imgHdc: HDC);
var
  lP: longint;
begin
  if not Composited(WinHandle) then
  begin
    PaintBackground(WinHandle, False);
    // Bei Fehler PRF_CLIENT deaktivieren
    lP := PRF_CHILDREN or PRF_CLIENT or PRF_NONCLIENT or PRF_CHECKVISIBLE;
    SendMessageW(WinHandle, WM_PRINT, GetPaintDC(WinHandle), lP);
  end;
  PaintToScreen(WinHandle, imgHdc, 0, 0, 0);

end;

gruss

[KodeZwerg]

Kurze Rückmeldung dann könnt ihr ja weiter machen, ich les euch gerne weil ich dabei gut lerne.

Zwischenbilanz mit PrintWindow:
Viele non-VCLs von Luckie kompiliert und geknippst = null problemo
Viele VCLs, auch non-Delphi, knippsen = null probleme
Hardwarebeschleunigter MediaPlayerClassic während Wiedergabe geknippst = null problemo
DirectX/OpenGL = Je nach Anwendung, das DX/GL ClientRect bleibt leer (nicht schwarz sondern so als ob man ne leere große Form hat.) Zumindest wird der Rahmen korrekt geknippst falls einer da ist und ichs aktiviert hab (FullWindow = True)

Was mich nun interessieren würde wäre ein Example wo es Probleme bereitet. Da ihr zwei Euch so gut in der Materie auskennt da habt ihr doch bestimmt ein kleines Dingens rumliegen was ich nicht knippsen könnte, oder?