AW: VCL zu Non-VCL
Zitat:
Beispiel anstelle das man eine Form verwendet Form : TForm erstellt man das Fenster selbst. über CreateWindowEx. gruss |
AW: VCL zu Non-VCL
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: |
AW: VCL zu Non-VCL
Zitat:
oder war es DirectX? sorry hab mit dem Kram noch nicht gearbeitet und werde ich wohl auch nicht tun. gruss |
AW: VCL zu Non-VCL
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". |
AW: VCL zu Non-VCL
..."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. |
AW: VCL zu Non-VCL
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:
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 |
AW: VCL zu Non-VCL
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 ;-) |
AW: VCL zu Non-VCL
Zitat:
Denn letztendlich weis niemand mehr woran man sich halten soll. Das ist der Frust den man dabei fühlt. :) gruss |
AW: VCL zu Non-VCL
Aber Emil, vielleicht können wir ja auf Deine Eingangsfrage zurückkommen.
Delphi-Quellcode:
Der Brush ist in TwinControl definiert und wird dort mit
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 aktuellen Farbe als SolidBrush erzeugt. Bei Farbänderung wird er neu erzeugt. Hoffe ich habe Deine Frage richtig verstanden |
AW: VCL zu Non-VCL
Zitat:
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 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:52 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz