![]() |
AW: Debugger hält beim Programmende in CPU-Fenster
SynEdit hat da ein Problem, weil ich habe an einer Stelle in einer Anwendung SynEdit wegen eines Custom-SQL-Editors im Programm für unsere User. Rufe ich das nicht auf, schließt sich das Programm sauber, öffne ich das Fenster mit dem SynEdit Memo auch nur einmal, dann kriege ich beim Schließen der Anwendung einen Fehler im der was mit einem Interface in SynEdit zu tun hat.
|
AW: Debugger hält beim Programmende in CPU-Fenster
Das kann gut sein dass sich da gegenseitig was aufschaukelt. Denn den SynEdit in Verbindung mit dem SQL-Highlighter verwende ich auch.
|
AW: Debugger hält beim Programmende in CPU-Fenster
So, wo ich mal wieder Zeit hatte konnte ich das Problem reproduzieren und eingrenzen. Und zwar liegt es am VirtualBox Grafikkartentreiber. Wenn man in den VBox-Einstellungen die Grafikkarte auf VBoxSVGA stellt und den 3D-Support aktiviert, dann wirft SynEdit solche Exceptions. Das kann man mit einem Workaround beheben, indem man in der SynEdit.inc ganz am Ende den DirectWrite-Support auskommentiert:
Delphi-Quellcode:
Dann noch das Synedit-Package neu erzeugen und fertig. Damit habe ich zwar die genaue Ursache noch nicht gefunden, aber zumindest gibts keine Exceptions mehr. Der Nachteil ist, dass Synedit dann wieder GDI zeichnet und entsprechend etwas langsamer ist.
// DirectWrite
{$IFDEF SYN_DELPHI_XE2_UP} //{$DEFINE SYN_DirectWrite} {$ENDIF} |
AW: Debugger hält beim Programmende in CPU-Fenster
Das ist seltsam, weil ich nutze keine VM und habe das Problem, aber ich kann es mal probieren dieses WE.
|
AW: Debugger hält beim Programmende in CPU-Fenster
Zitat:
|
AW: Debugger hält beim Programmende in CPU-Fenster
Nachtrag: Ursache gefunden!
In der SynEdit.pas in der function TCustomSynEdit.CreateD2DCanvas folgende Zeile suchen:
Delphi-Quellcode:
und wie folgt ergänzen:
HR := D2DFactory.CreateHwndRenderTarget(D2D1RenderTargetProperties,
D2D1HwndRenderTargetProperties(Handle, Size), FRenderTarget);
Delphi-Quellcode:
Das scheint also wirklich ein Treiberproblem zu sein. Denn laut
HR := D2DFactory.CreateHwndRenderTarget(D2D1RenderTargetProperties(D2D1_RENDER_TARGET_TYPE_SOFTWARE),
D2D1HwndRenderTargetProperties(Handle, Size), FRenderTarget);, ![]() Zitat:
Noch ein Nachtrag: Ich denke ich habe die Erklärung gefunden. Vor langer Zeit wurde das in SynEdit implementiert. Damals gab es damals nur DirectX9. Irgendwann kam DX10 und wurde in der Winapi.D2D1.pas ergänzt. Nur wurde SynEdit nie daran angepasst. So wie es in SynEdit implementiert ist, fällt die Initialisierung auf DX9-Featurelevel zurück. Manche Graka-Treiber bieten aber nur DX10. Man kann DX10 erzwingen, wenn man die oben genannte Zeile wie folgt ändert:
Delphi-Quellcode:
Entscheidend ist D2D1_FEATURE_LEVEL_10 anzugeben, wenn man ein DX10-System hat und D2D1_FEATURE_LEVEL_9 wenn man ein DX9-System hat. Jetzt habe ich aber spontan nichts gescheites gefunden, wie man die DirectX-Version ermitteln könnte. Außer in der Registry rumzustöbern.
HR := D2DFactory.CreateHwndRenderTarget(
D2D1RenderTargetProperties( D2D1_RENDER_TARGET_TYPE_DEFAULT, D2D1PixelFormat(), 0, 0, D2D1_RENDER_TARGET_USAGE_NONE, D2D1_FEATURE_LEVEL_10 ), D2D1HwndRenderTargetProperties(Handle, Size), FRenderTarget ); |
AW: Debugger hält beim Programmende in CPU-Fenster
Zitat:
![]() D3D11CreateDevice -> Array mit gewünschten Feature Levels reingeben, das höchste unterstützte wird mit zurückgeben. Wenn größer gleich D3D_FEATURE_LEVEL_10_0, dann kannst du von D2D1_FEATURE_LEVEL_10 ausgehen. Beispiel:
Delphi-Quellcode:
function TDirectXBase.CreateD3DResources : Boolean;
var LD3DDevice : ID3D11Device; LCreationFlags : Cardinal; LD3DDeviceContext : ID3D11DeviceContext; LDriver : D3D_DRIVER_TYPE; SupportedFeatureLevel: D3D_FEATURE_LEVEL; const FeatureLevels : array [0 .. 6] of D3D_FEATURE_LEVEL = ( D3D_FEATURE_LEVEL_11_1, D3D_FEATURE_LEVEL_11_0, D3D_FEATURE_LEVEL_10_1, D3D_FEATURE_LEVEL_10_0, D3D_FEATURE_LEVEL_9_3, D3D_FEATURE_LEVEL_9_2, D3D_FEATURE_LEVEL_9_1); DriverTypes : set of D3D_DRIVER_TYPE = [D3D_DRIVER_TYPE_HARDWARE, D3D_DRIVER_TYPE_WARP]; begin Result := False; LCreationFlags := LongWord(D3D11_CREATE_DEVICE_BGRA_SUPPORT); {$IFDEF DEBUG} LCreationFlags := LCreationFlags or LongWord(D3D11_CREATE_DEVICE_DEBUG); {$ENDIF} for LDriver in DriverTypes do begin Result := Succeeded(D3D11CreateDevice(nil, LDriver, 0, LCreationFlags, @FeatureLevels, Length(FeatureLevels), D3D11_SDK_VERSION, LD3DDevice, @SupportedFeatureLevel, LD3DDeviceContext)); if Result then Break; end; // hier dann was mit SupportedFeatureLevel machen end; |
AW: Debugger hält beim Programmende in CPU-Fenster
Wie bekommen wir diese Verbesserungen in das offizielle SynEdit rein?
Damit alle profitieren und nicht jeder solche Fixes selber anbringen muss! |
AW: Debugger hält beim Programmende in CPU-Fenster
Welches ist denn das "offizielle" SynEdit? Davon gibt es doch inzwischen so viele Forks... Die DirectDraw-Version konnte ich jetzt nicht mal in einem Repository finden. Wir haben diese Variante seit 2018 im Projekt. Die Probleme kamen in meinem Fall nach einem VBox-Update auf. Die Version die man aktuell bei
![]() ![]() |
AW: Debugger hält beim Programmende in CPU-Fenster
Welches ist denn das SynEdit Paket, das per GetIt installierbar ist?
Das würde ich wohl als das einigermaßen offizielle ansehen. Es gibt diverse verweiste Sachen bei denen es schön wäre, wenn diese weiter gepflegt würden. Nur wie bekommen wir sowas koordiniert hin um es a) überhaupt zu tun b) Doppelarbeiten zu vermeiden? Grüße TurboMagic |
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:43 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz