VCL zu Non-VCL

[EWeiss]

Zitat von freimatz:

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?

[EWeiss]

Zitat von freimatz:

Gehört also die Verwendung von FMX auch dazu?

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.



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