VCL zu Non-VCL

[EWeiss]

Ok!
Dein Statement hat mich überzeugt

Auch wenn ich immer noch nicht so recht überzeugt bin. (Mein Einwand)
Denn man bedenke bei der ganzen Diskussion für und wieder.. Warum werden dann auf falsche??? Dokumentationen (Sample Codes) verwiesen
wenn das was in der API Dokumentation so steht dann letztendlich doch anders ausgeführt wird.

Nochmal.
Die API Dokumentation
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

und darunter der Link auf der gleichen Seite bei Example
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

Hier wird genau das Gegenteil gemacht von dem du so überzeugt bist.
Verstehe das wer will.

Es hat immer einen faden Beigeschmack wenn selbst auf der MSDN dann auf Samples verwiesen wird
wo es nicht so ausgeführt wird wie in der API Dokumentation angegeben wem soll man nun glauben.

Zitat:

Daher kann auf einem System mit sagen wir NVidia Grafiktreibern bestimmtes funktionieren

Na ja NVIDIA ist auch nicht mehr was es war.
Habe gerade das Problem mit den neuesten Treibern keine meiner Anwendungen die mit OpenGL laufen funktionieren damit.
Der einzig zuverlässige ist 352.86 alle anderen verursachen abstürze mit OpenGL..
Aber gut ist ein anderes Thema.

gruss

[Fritzew]

Genau auf dieses Beispiel habe ich mich bezogen,
das ist totaler Schrott. Habe es bei Microsoft gemeldet (Das war in nun fast 25 Jahren das erste mal) Bin jetzt selber gespannt.

mensch72 hat hier absolut recht. Die GDI ist robuster geworden aber die Treiber nicht immer. Vor allem günstige Drucker kommen da schon manchmal mit skurrilen Ergebnissen. Bin in der CAD - Branche und was da teilweise ankommt an Treibern bei Kunden würde bei uns Regale füllen, könnten wir das nicht elektronisch Machen

[EWeiss]

Zitat von Fritzew:

Genau auf dieses Beispiel habe ich mich bezogen,
das ist totaler Schrott. Habe es bei Microsoft gemeldet (Das war in nun fast 25 Jahren das erste mal) Bin jetzt selber gespannt.

mensch72 hat hier absolut recht. Die GDI ist robuster geworden aber die Treiber nicht immer. Vor allem günstige Drucker kommen da schon manchmal mit skurrilen Ergebnissen. Bin in der CAD - Branche und was da teilweise ankommt an Treibern bei Kunden würde bei uns Regale füllen, könnten wir das nicht elektronisch Machen

Danke Das du es gemeldet hast.
Denn letztendlich weis niemand mehr woran man sich halten soll.

Das ist der Frust den man dabei fühlt.

gruss

[Fritzew]

Aber Emil, vielleicht können wir ja auf Deine Eingangsfrage zurückkommen.

Delphi-Quellcode:

Wann wird das Brush Handle erstellt und wie kann ich das umsetzen zu Non-VCL
Das einzige das ich meiner Funktion übergebe ist das Window Handle der NON-VCL Anwendung.

Der Brush ist in TwinControl definiert und wird dort mit
der aktuellen Farbe als SolidBrush erzeugt. Bei Farbänderung wird er neu erzeugt.

Hoffe ich habe Deine Frage richtig verstanden

[EWeiss]

Zitat von Fritzew:

Aber Emil, vielleicht können wir ja auf Deine Eingangsfrage zurückkommen.

Delphi-Quellcode:

Wann wird das Brush Handle erstellt und wie kann ich das umsetzen zu Non-VCL
Das einzige das ich meiner Funktion übergebe ist das Window Handle der NON-VCL Anwendung.

Der Brush ist in TwinControl definiert und wird dort mit
der aktuellen Farbe als SolidBrush erzeugt. Bei Farbänderung wird er neu erzeugt.

Hoffe ich habe Deine Frage richtig verstanden

OK danke das wollte ich wissen..

Ich habe nämlich mit AnimateWindow einen seltsamen Effekt das der Hintergrund beim Animieren weiß wird also der Teil der noch nicht gezeichnet wurde.
Dachte das läge am Brush dem scheint aber nicht so. (Treiber oder ähnliches Problem? Finde es nicht)
Es ist das Fenster das man unter Applications.Handle (hInstance) ansprechen kann also der nicht sichtbare Bereich des Fensters der das Problem verursacht.
Muss da noch was Nachforschen ob hier irgend ein Fensterstyle das Problem vielleicht beheben kann.

gruss

[Fritzew]

könnte WM_ERASEBKGND Dein Problem sein?
Habe kein D2010 im zugriff gerade sonst würde ich nachmachen was das Application Winde so alles treibt

[EWeiss]

Zitat von Fritzew:

könnte WM_ERASEBKGND Dein Problem sein?
Habe kein D2010 im zugriff gerade sonst würde ich nachmachen was das Application Winde so alles treibt

Ich könnte mal ein
RedrawWindow versuchen in WM_ERASEBKGND
Im Moment gebe ich es mit 1 zurück.

Delphi-Quellcode:

{$REGION 'WM_ERASEBKGND'}
    WM_ERASEBKGND:
      begin
        Result := 1;
        exit;
      end;
{$ENDREGION}
{$REGION 'WM_PRINT'}
    WM_PRINT:
      begin
        GetClientRect(WinHandle, Rect);

        DC := wp;
        SrcDC := SKAERO_GetProperty(WinHandle, FORM_PaintDC);
        BitBlt(DC, 0, 0, Rect.Right, Rect.Bottom, SrcDC, 0, 0, SRCCOPY);

        ReleaseDC(Winhandle, DC);
        ReleaseDC(Winhandle, SrcDC);
      end;
{$ENDREGION}
{$REGION 'WM_PAINT'}
    WM_PAINT:
      begin
        BeginPaint(WinHandle, ps);
        SKAERO_PaintDoubleBuffer(WinHandle, ps.HDC);
        EndPaint(WinHandle, ps);
        Result := 0;
        exit;
      end;
{$ENDREGION}

Aber ich habe bald die Vermutung das es an Aero liegt wenn eingeschaltet.
Ich kann es sehen aber kein Screen Capture Tool vermag den Fehler aufzunehmen.

gruss

[EWeiss]

Nope geht nicht.

Mit eingeschalteten Aero zeichnet AnimateWindow zuerst den "non Client Area" Bereich und erst dann den Client Area Bereich.
Muss da wieder mal nachforschen wie ich das beheben kann.

EDIT:
Ich denke das hat sich erst mal erledigt..(mit AnimateWindow) Mit aktivierten Aero funktioniert das nicht.
MS! Schade das dass nie gefixt wurde.

Danke.

gruss