VCL zu Non-VCL

[EWeiss]

Habe ein paar fragen zur Konvertierung von VCL zu NON-VCL
Da es einige sind habe ich diesen Thread Titel gewählt.

Delphi-Quellcode:

FillRect(FWindowDC, Rect(0, 0, FForm.Width, FForm.Height), FForm.Brush.Handle);

Delphi-Quellcode:

FForm.Width, FForm.Height

Kann ich mir über GetClientRect holen denke das ist OK!

Meine erste Frage.

Delphi-Quellcode:

FForm.Brush.Handle

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.

Delphi-Quellcode:

var
  Brush: HBrush;
begin
  Brush := CreateSolidBrush(myColor);
  SelectObject(FWindowDC, Brush);
  FillRect(FWindowDC, Rect(0, 0, ClientWidth, ClientHeight), Brush);
  DeleteObject(Brush);
end;

Kommt das in etwa hin?
Wenn ja welche Farbe wird dann bei der Form übergeben? (NULL_BRUSH) ?
Keine selbst definierte sondern die Standard Farbe.

gruss

[EWeiss]

Will wohl niemand Antworten.. ;) Egal!

gruss

[haentschman]

:roll: nach 3 Stunden. Hast du heute noch was vor?

[EWeiss]

Zitat:

Zitat von haentschman (Beitrag 1377245)

:roll: nach 3 Stunden. Hast du heute noch was vor?

Nun zumindest hat jetzt einer geantwortet Danke.
Auch wenn es nichts zum Thema beiträgt.

gruss

[Delphi-Laie]

Der Delphi-Non-VCL-Papst ist Luckie. Zur Not mal per PN bei ihm nachfragen, ob er das ggf. übersah. Ist bei seiner aufmerksamen bis pflichtbewußten Moderation allerdings eher unwahrscheinlich.

[EWeiss]

Zitat:

Zitat von Delphi-Laie (Beitrag 1377256)

Der Delphi-Non-VCL-Papst ist Luckie. Zur Not mal per PN bei ihm nachfragen, ob er das ggf. übersah. Ist bei seiner aufmerksamen bis pflichtbewußten Moderation allerdings eher unwahrscheinlich.

Du weist aber schon das es hier um VCL geht?

Zitat:

Wenn ja welche Farbe wird dann bei der Form übergeben? (NULL_BRUSH) ?

wie das in NON-VCL umgesetzt wird ist mir schon klar ;)

Delphi-Quellcode:

var
   Brush: HBrush;
begin
   Brush := CreateSolidBrush(myColor);
   SelectObject(FWindowDC, Brush);
   FillRect(FWindowDC, Rect(0, 0, ClientWidth, ClientHeight), Brush);
   DeleteObject(Brush);
end;

Aber seltsamer weise ist der Effekt etwas anders als unter VCL warum auch immer.
Ich denke da hängen noch andere Sachen dran.

Unter VCL kann ich den Ausgeschnittenen Teil der Form als clFuchsia sehen unter NON-VCL nicht.
Das ist schon etwas seltsam.

gruss

[TBx]

Zitat:

Zitat von EWeiss (Beitrag 1377253)

Auch wenn es nichts zum Thema beiträgt.

Ich denke mal, wenn Dich ein User dezent darauf hinweist, dass Pushen nicht gern gesehen ist, dann mußt Du ihn nicht auch noch treten.

Zitat:

Zitat von EWeiss

Habe ein paar fragen zur Konvertierung von VCL zu NON-VCL

und

Zitat:

Zitat von EWeiss

Du weist aber schon das es hier um VCL geht? ... wie das in NON-VCL umgesetzt wird ist mir schon klar

passt irgendwie auch nicht so ganz zusammen :gruebel:

[EWeiss]

Zitat:

passt irgendwie auch nicht so ganz zusammen

Dann erkläre mir mal warum nicht?

Ich habe versucht eine Lösung zu bekommen wie ich

Delphi-Quellcode:

FForm.Brush.Handle

nach NON-VCL umsetzen kann die Lösung habe ich dann selbst erarbeitet.
Das zu punkt NON-VCL

Zitat:

Du weist aber schon das es hier um VCL geht?

Bezog sich auf die Frage VCL!

Auf was sich dann meine Frage bezog war welche Farbe dem FForm.Brush zugewiesen wird wenn man es nicht explicit selbst tut.
Denn irgendwo her muss das Handle ja zugewiesen werden mit der dafür erstellten Farbe vom Brush.

Das zu Punkt VCL

Nun was passt hier nicht zusammen ?
Ich dachte eigentlich das mir jemand der ausschließlich mit der VCL arbeitet mir das sagen könnte.
Dem scheint wohl nicht so.

gruss

[mensch72]

Mindesten fehlt "OldBrush" zum retten des vorherigen Brushs, denn man löscht kein noch selktiertes Handle...
(ob man den Brush selektieren muss, wenn er bei FillRect mit übergeben wird, das weiß ich aus dem Kopf nicht mehr, aber schaden kann es nicht)

Delphi-Quellcode:

var
   Brush: HBrush;
   OldBrush: HBrush;
begin
   Brush := CreateSolidBrush(myColor);
   OldBrush:=SelectObject(FWindowDC, Brush);
   FillRect(FWindowDC, Rect(0, 0, ClientWidth, ClientHeight), Brush);
   SelectObject(FWindowDC, OldBrush);
   DeleteObject(Brush);
end;

[EWeiss]

Zitat:

ob man den Brush selektieren muss

Ja muss man Danke ;)

Edit:
Aber OldBrush benötigt man nicht.

Hier ein Beispiel:
http://www.functionx.com/win32/Lesson17.htm

gruss

[mensch72]

https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx

Man darf laut MS keine selektierten GDI-Objekte löschen, was aber in vielen Beispielen und Sourcen im INet nicht beachtet wird!?
Unter Win31 endete es schenll ganz böse, wenn das nicht beachtet hat, heute is die WinApi etwas robuster, aber es macht auf Dauer auch Probleme.

=> als benötigt man doch entweder den "OldBrush", oder man selektiert vor dem löschen etwas internes per "GetStockObject"

[himitsu]

Und OldBrush hat einen Vorteil.

Wenn außenrum eine große Zeichenroutine ist und mitten drin dein Code, dann kann es sein, dass danach andere Dinge mit dem falschen Brush weitergezeichnet werden, wenn du es nicht zurücksetzt.

[EWeiss]

Zitat:

Man darf laut MS keine selektierten GDI-Objekte löschen, was aber in vielen Beispielen und Sourcen im INet nicht beachtet wird!?

Nein?
Und warum tut es MS nicht selbst.
Sehe nirgends etwas von OldPen, OldBrush usw..
https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx

Ein Widerspruch in sich oder?

Zitat:

dass danach andere Dinge mit dem falschen Brush weitergezeichnet werden

Nö es ist immer die Value maßgeblich die gerade beim aktuellen zeichnen selektiert ist.

gruss

[Fritzew]

Meiner Meinung nach hat Himitsu hier recht

Das Beispiel in MSDN ist total Schrott

Schau Dir mal das an:


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

Und wenn Du dabei bist auch noch:

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

Die GDI ist zwar robuster geworden aber es schadet bestimmt nicht wenn man sich an die Regeln hält

[EWeiss]

Zitat:

Das Beispiel in MSDN ist total Schrott

Nun da fragt man sich welches Beispiel denn nun Schrott ist.
Meine verlinkten oder deine verlinkten.

Es ist mir jetzt zu mühselig das nachzuvollziehen was, wo , wer denn nun recht hat.
Ich sehe nur das ein und das gleiche Unternehmen unterschiedliche Interpretationen wieder gibt.

Natürlich, man kann nun hingehen und das für sich passende heraussuchen um gegen zu argumentieren.
Aber das erspare ich mir einfach.

Zitat:

Die GDI ist zwar robuster geworden aber es schadet bestimmt nicht wenn man sich an die Regeln hält

Wer sagt dir nun welche die Regel ist?
Wenn wie in meinen Links ersichtlich die MSDN es selbst nicht mal tut.

gruss

[bra]

In der Dokumentation zur Funktion steht, man sollte es nicht tun. Dann ist doch schnurz, was in in irgendwelchen Beispielen steht! :roll:

[EWeiss]

Zitat:

Zitat von bra (Beitrag 1377429)

In der Dokumentation zur Funktion steht, man sollte es nicht tun. Dann ist doch schnurz, was in in irgendwelchen Beispielen steht! :roll:

Die Praxis sagt was anderes.
Sorry deine Aussage ist nicht qualifiziert genug.

Zitat:

BOOL DeleteObject(
_In_ HGDIOBJ hObject
);
Return value
If the function succeeds, the return value is nonzero.
If the specified handle is not valid or is currently selected into a DC, the return value is zero.

In beiden fällen ist die Rückgabe von DeleteObject (TRUE)

Delphi-Quellcode:

    SelectObject(FWindowDC, OldBrush);
    if DeleteObject(Brush) then
      SelectObject(FOldWindowDC, FWindowBitmap);

Delphi-Quellcode:

    //SelectObject(FWindowDC, OldBrush);
    if DeleteObject(Brush) then
      SelectObject(FOldWindowDC, FWindowBitmap);

Jeder kann sich nun aussuchen was er denn nun gerne hätte.

Qualifikation!
Für mich zählt das Ergebnis und das ist in beiden fällen True (Das Object wurde freigegeben und ich hab kein Speicherleck).
Widerlege mir das dann können wir darüber weiter diskutieren.

gruss

[bra]

https://stackoverflow.com/questions/...ject-on-bitmap

[EWeiss]

Zitat:

Zitat von bra (Beitrag 1377433)

https://stackoverflow.com/questions/...ject-on-bitmap

Vergiss es. (Spam)
Hat nichts mit einem Bitmap zu tun. (Hintergrundfarbe Window\Form)

gruss

[freimatz]

Was ist NON-VCL?

[EWeiss]

Zitat:

Zitat von freimatz (Beitrag 1377443)

Was ist NON-VCL?

Wie der Name schon sagt es wird keine VCL verwendet.
Beispiel anstelle das man eine Form verwendet

Form : TForm
erstellt man das Fenster selbst.
über CreateWindowEx.

gruss

[freimatz]

Danke. Dass keine VCL verwendet wird hatte ich selber schon vermutet.
Mit Google fand ich aber nicht viel mehr heraus.
Gehört also die Verwendung von FMX auch dazu? :wink:

[EWeiss]

Zitat:

Zitat von freimatz (Beitrag 1377448)

Gehört also die Verwendung von FMX auch dazu? :wink:

Nö.. aber als alternative kannst du anstelle von FMX (NON-FMX) OpenGL verwenden.
oder war es DirectX?

sorry hab mit dem Kram noch nicht gearbeitet und werde ich wohl auch nicht tun.

gruss

[himitsu]

Jupp, im Prinzip ist die VCL ein Wrapper für eine API im Windows (GDI).

Non-VCL heißt hier, dass man z.B. selber direkt mit der API arbeitet, ohne den Wrapper dazwischen.


Also eigentlich sagt Non-VCL nicht "direkt" aus wie man was macht, sondern nur daß man einwas nicht dafür nimmt.
Car = mit Auto
Non-Car = ohne Auto ... also zu Fuß
Non-Car könnte zwar auch sein, dass man stattdessen das Fahrrad nimmt, aber da würde man das dann eher "Bike" nennen.

FMX wäre somit auch Non-VCL, im weitesten Sinne, da auch keine VCL genutzt wird, aber siehe vorherrige Zeile.


PS: Non-RTL = CreateFile + WriteFile statt TFileStream + ReadBuffer oder Read



Die API, welche von der VCL und direkt bei Non-VCL genutzt wird, nutzt intern auch wieder andere APIs, also könnte man das noch viel weiter treiben, bis hin zu die Grafikkarte direkt anzusprechen.
Und wer ganz hart ist, schickt die Befehle/Signale direkt an den Monitor oder gleich direkt an das LCD. :lol:



In diesem Fall bedeutet es "Ich hab was als VCL und will das jetzt selber machen, ohne die fette VCL als Vermittler zu nutzen".

[mensch72]

..."Für mich zählt das Ergebnis und das ist in beiden fällen True (Das Object wurde freigegeben und ich hab kein Speicherleck).
Widerlege mir das dann können wir darüber weiter diskutieren."...

- das True sagt, wie richtig erkannt, das(dein) Object wurde erfolgreich gelöscht, man bekommt ein ja auch "False" zurück wenn man 2x DeleteObject für das gleiche Handle aufruft:)
- böse ist, das weiter ja selektierte Handle im DC hat nun keinen gültiges Objectspeicher mehr
- dies verletzt die Grundregel der GDI-API das sich jeder zu jederzeit darauf verlassen darf, das stets ein gültiger PEN und ein gültiger BRUSH im DC aktiv und verfügbar sind
- wenn du 100% alles selbst, also ohne jemals für Client oder NonClient Bereich die DefWinProc zu nutzen, dann hast du es selbst in der Hand stets vor dem Aufruf einer Zeichenfunktion dich immer um PEN&BRUSH im DC zu kümmern... dann kannst du auf dieses Regel pfeifen und alles wann und wie du es selbst für richtig hälst löschen


=> es geht hier nicht um "dein" Speicherleck, sondern um das Risiko das irgendwer in einer Lib oder in Code der nicht von dir davon ausgeht, er kann mal fix was ohne sich um "alle" SelectObjects zu kümmern etwas per Aufruf einer GDI-API Funktion zeichnen, und genau dort kann es "knallen" wenn zuviel Zeit vergangen ist und der freigegebene ObjektSpeicher nun mit völlig anderen Daten gefüllt ist weil er nun für/von XYZ verwendet ist

-> mach weiter wie du denkst, das hat mit "Qualifikation" nix zu tun... es geht um's Prinip der bestmöglichen Kompatibilität mit sehr geringem Zusatzaufwand(eine OldXX-Variable plus ein SelectObject)... Für deinen Code bekäme ich im 0815 Fall einer Standardverwendung bei uns kein Audit... ich bekäme solches nur durch, wenn es absolut auf jede Nano & Micro-Sekunde beim aufruf von sehr sehr vielen Zeichenfunktionen in RealTime ankommt(dann zählt die Zeit für das gesparte SelectObject-OldXX, wenn danach eh stets ein SelectObject-NewXX kommt, und man nur im "finaly" garantiert das wenn zum Schluss wieder etwas gültiges selektiertes im DC hinterlässt)


GDI-API Programmierung ist wenn man sich an ein paar GrundSätze hält eigentlich ganz einfach und logisch, aber vom Grundkonzept eben nicht objektorientiert, also muss/sollte man sich wie die alten C-Programmierer selbst zwingen, immer schön sauber zu programmieren. Windows bekam erst dann den großen Durchbruch für die Allgemeinheit als es mit MFC und viel besser VCL eben einen Objektorientierten Ansatz zur "sinnvollen"(MFC) bzw. schönen(VCL) Kapselung gabt. Da kümmert sich immer der vom Compiler verwaltete&garantierte Destuctor-Aufruf um solchen scheinbar nervenden internen Kleinkram... so konnte plötzlich "jeder" ohne viel Nachdenken sichere Windows-GDI-Programme schreiben.

NonVCL ist also absolut nix besonderes, da helfen einem einfach die seit Win31 unveränderten prinzipellen Grundregeln, auch wenn diese heute sehr "OldScool" sind und es nun irgenwie oft auch so geht... "widerlegen" oder "beweisen" muss man da nix... es steht jedem frei mal einen GDI Druckertreiber oder einen virtuellen Grafiktreiber selbst zu schreiben, da merkt man dann was für einen Mist die lieben Programmierer per API veranstalten... Microsoft macht es sich aus Geschwindigkeitsgründen einfach, die schicken alles so direkt wie möglich durch.
Daher kann auf einem System mit sagen wir NVidia Grafiktreibern bestimmtes funktionieren, auf anderen Systemen mit ATI-Grafiktreibern aber nicht, oder man findet ganz spezielle Unterschiede bei RemoteDesktop, VMware und VirtualBox. Man darf Win10 ablehnen und muss Microsoft nicht mögen, aber es bleibt empfehlenswert sich an deren "alte Vorgaben" und "heutigen Empfehlungen" zu halten, denn eines muss man MS lassen... die achten sehr auf Langzeitkompatibilität!... Win32-API-Programme sagen wir ab Win95 laufen heute noch bis auf "schönes" HiDPI unter Win10.

[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:

Zitat von Fritzew (Beitrag 1377465)

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:

Zitat von Fritzew (Beitrag 1377467)

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:

Zitat von Fritzew (Beitrag 1377469)

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