TRichMemo - Grafik einfügen

Th69 · Verfasst: Fr 22.05.20 18:47

Dann ist das ja noch eigenartiger.
Ist das denn in TWin32WidgetSet auch schon eingebunden?

PS: Linkst du die Bibliotheken dynamisch oder statisch (d.h. verwendest du die Runtime-Packages oder nicht)?

galagher · Verfasst: Fr 22.05.20 19:05

Th69 hat folgendes geschrieben :

Ist das denn in TWin32WidgetSet auch schon eingebunden?

Nun, TWin32WidgetSet ist in Win32.int deklariert, und ja, SysUtils ist auch dort eingebunden.

Th69 hat folgendes geschrieben :

PS: Linkst du die Bibliotheken dynamisch oder statisch (d.h. verwendest du die Runtime-Packages oder nicht)?

Die Packages sind fix in Lazarus, das heisst, ich habe die IDE kompiliert, um die verschiedenen Packages nutzen zu können.

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

Th69 · Verfasst: Fr 22.05.20 20:15

Kommst du denn auch an den Sourcecode von SysUtils ran, um zu schauen, wie dort die Exceptions für die Runtime-Fehler eingeschaltet werden?

Irgendwie muß es ja einen Unterschied geben, denn bei deinem Code funktioniert es ja.

Edit: Es wird wohl ErrorProc auf eine eigene Prozedur gesetzt (evtl. kannst du in dieser mal debuggen, d.h. Haltepunkt setzen).

galagher · Verfasst: Fr 22.05.20 20:19

Th69 hat folgendes geschrieben :

Kommst du denn auch an den Sourcecode von SysUtils ran, um zu schauen, wie dort die Exceptions für die Runtime-Fehler eingeschaltet werden?

Ja, den Sourcecode habe ich. Wonach genau suchen wir denn?

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

Th69 · Verfasst: Fr 22.05.20 20:28

Hatte gerade noch meinen Beitrag editiert: schau mal nach der Prozedur, welcher ErrorProc zugewiesen wird.

Evtl. liegt es ja auch an diesem speziellen SIGSEV-Fehler. Dieser dürfte wohl "216 General Protection fault" aus Appendix D: Run-time errors entsprechen.
Kannst du diesen mal mit deinem Testprogramm auslösen (d.h. einen ungültigen Speicherzugriff, z.B. auf eine feste Adresse bzw. Dereferenzierung von nil)?

galagher · Verfasst: Fr 22.05.20 20:28

Th69 hat folgendes geschrieben :

Edit: Es wird wohl ErrorProc auf eine eigene Prozedur gesetzt (evtl. kannst du in dieser mal debuggen, d.h. Haltepunkt setzen).

In sysutils.pp kommt ErrorProc nicht vor.

Aber ich habe eine interessante Seite gefunden: www.delphipraxis.net...oraer-speichern.html
Leider kann ich den Code aber nicht nutzen, weil Lazarus keine Prozedur ClipBoard.GetAsHandle hat. Lieber würde ich aber natürlich den momentanen Weg mit den Arrays beibehalten.

Edit: Und auch ClipBoard.SetAsHandle gibt es nicht.

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

galagher · Verfasst: Fr 22.05.20 20:41

In sysutils.inc habe ich gefunden:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

Procedure InitExceptions;
begin
//...
  ErrorProc:=@RunErrorToExcept;
//...
end;


//...

Edit: Ich denke ja doch, dass es - namentlich bei Lazarus - erlaubt ist, fremden Sourcecode zur Gänze zu posten.

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

galagher · Verfasst: Fr 22.05.20 21:04

Th69 hat folgendes geschrieben :

Evtl. liegt es ja auch an diesem speziellen SIGSEV-Fehler. Dieser dürfte wohl "216 General Protection fault" aus Appendix D: Run-time errors entsprechen.
Kannst du diesen mal mit deinem Testprogramm auslösen (d.h. einen ungültigen Speicherzugriff, z.B. auf eine feste Adresse bzw. Dereferenzierung von nil)?

Was und wie genau zB.?

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

Th69 · Verfasst: Fr 22.05.20 21:10

Ich habe es jetzt auch direkt auf dem freepascal-git repository gefunden: sysutils.inc

Mein Delphi ist schon etwas eingerostet, aber laut Pointers and references: Delphi so ähnlich:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:

var
  pIntPointer : ^Integer;
  IntVar : Integer;
begin
  pIntPointer := nil;
  IntVar := pIntPointer^; { <- und das dann in einem try..except Block }
end

Und dann debugge mal die RunErrorToExcept-Prozedur (Step by Step).
Überprüfe auch mal, ob CatchUnhandledException angesprungen wird (was ja bei aktiviertem try..except-Block eigentlich nicht passieren sollte).

galagher · Verfasst: Fr 22.05.20 21:16

Th69 hat folgendes geschrieben :

Und dann debugge mal die RunErrorToExcept-Prozedur (Step by Step).

Ich soll den Code also in eine Prozedur meines Programms testweise einbauen, try/except drum rum, und das dann testen?

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

Th69 · Verfasst: Fr 22.05.20 21:27

Ja, so wie dein vorheriges Testprogramm mit der DivideByZero-Exception und dann Haltepunkt auf die erste Zeile der RunErrorToExcept-Prozedur setzen und schrittweise debuggen, was da passiert (warum dein except-Block nicht angesprungen wird).

Edit:
Du sollst nicht den Code der RunErrorToExcept-Prozedur kopieren, sondern diesen nur debuggen (d.h. die Sourcedatei im Editor öffnen und Haltepunkt dort setzen - es kann sein, daß du erst dein Programm starten mußt und einen eigenen Haltepunkt anspringen mußt, ehe du den Haltepunkt in der Systemdatei setzen kannst).

PS: Falls du explizit 216 abfangen willst, dies sollte dann eine EAccessViolation-Exception sein.

galagher · Verfasst: Fr 22.05.20 21:56

Th69 hat folgendes geschrieben :

Edit:
Du sollst nicht den Code der RunErrorToExcept-Prozedur kopieren, sondern diesen nur debuggen (d.h. die Sourcedatei im Editor öffnen und Haltepunkt dort setzen - es kann sein, daß du erst dein Programm starten mußt und einen eigenen Haltepunkt anspringen mußt, ehe du den Haltepunkt in der Systemdatei setzen kannst).

Lazarus akzeptiert in sysutils.inc keine Haltepunkte...

Th69 hat folgendes geschrieben :

Ja, so wie dein vorheriges Testprogramm mit der DivideByZero-Exception und dann Haltepunkt auf die erste Zeile der RunErrorToExcept-Prozedur setzen und schrittweise debuggen, was da passiert (warum dein except-Block nicht angesprungen wird).

Im Testcode wird except sehr wohl angesprungen, und zwar mit und ohne IDE!

Th69 hat folgendes geschrieben :

Edit:
Du sollst nicht den Code der RunErrorToExcept-Prozedur kopieren, sondern diesen nur debuggen (d.h. die Sourcedatei im Editor öffnen und Haltepunkt dort setzen - es kann sein, daß du erst dein Programm starten mußt und einen eigenen Haltepunkt anspringen mußt, ehe du den Haltepunkt in der Systemdatei setzen kannst).

Ok, dann entferne ich das aus meinem Beitrag. Aber wie gesagt: Haltepunkt klappt in sysutils.inc nicht. Liegt's an der Dateinamenerweiterung oder an der Tatsache, das die Methoden dort nur im implementation-Teil und nicht auch im interfacce stehen?

Th69 hat folgendes geschrieben :

PS: Falls du explizit 216 abfangen willst, dies sollte dann eine EAccessViolation-Exception sein.

Hm... Schritt für Schritt erstmal...

Edit:
Für heute erstmal vielen Dank!

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

Th69 · Verfasst: Fr 22.05.20 22:05

galagher hat folgendes geschrieben :

Lazarus akzeptiert in sysutils.inc keine Haltepunkte...

Das ist blöd. ;-(

galagher hat folgendes geschrieben :

Im Testcode wird except sehr wohl angesprungen, und zwar mit und ohne IDE!

Auch bei einem SIGSEGV-Fehler?
Dann verstehe ich nicht, warum es nicht bei deinem Clipboard-Programm funktioniert?

galagher hat folgendes geschrieben :

Für heute erstmal vielen Dank!

Dann gute Nacht!

galagher · Verfasst: Sa 23.05.20 05:21

Th69 hat folgendes geschrieben :

Dann verstehe ich nicht, warum es nicht bei deinem Clipboard-Programm funktioniert?

Ich auch nicht. Und was ich noch nicht verstehe: Der SIGSEGV-Fehler tritt nur so etwa jedes 10. Mal auf, ansonsten funktioniert es.

Mit der IDE kam diesmal danach noch folgende Meldung:

Zitat:

Projekt project1 hat Exception-Klasse "Exception" ausgelöst mit der Meldung:
IndexOfCachedFormatID: Internal Error: invalid FormatID 0 for clipboard

In Datei 'include\clipboard.inc' in Zeile 58

Und Zeile 58 dieser Datei ist eben genau dies:

markieren

Delphi-Quelltext

1:
2:
3:

raise Exception.Create(
  'IndexOfCachedFormatID: Internal Error: invalid FormatID 0 for '+
     ClipboardTypeName[ClipboardType]);

Vielleicht hilf das ja weiter.

Zu den SIGSEGV-Fehlermeldungen selbst: Die linke Grafik zeigt den SIGSEGV-Fehler bei dem "pIntPointer := nil;"-Test, die rechte den SIGSEGV-Fehler beim Einfügen der Grafik.

Edit:
Und was die Sache noch seltsamer macht: Ich kopiere also irgendeinen RTF-Text von Word in die Zwischanablage, füge danach meine Grafik ein, es knallt und das Programm beendet sich. Danach starte ich das Programm erneut, füge wieder die Grafik ein und diesmal funktioniert es. Und wenn ich dann die Grafik noch so oft einfüge - es klappt.
Wenn es 1x klappt, dann bleibt das auch so. Wenn nicht, dann bleibt auch das so. Bis ich exakt den selben Text erneut kopiere. Dann sind die Karten neu gemischt und es wird klappen oder eben nicht, meist jedoch schon... :eyecrazy:

Einloggen, um Attachments anzusehen!

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

Th69 · Verfasst: Sa 23.05.20 09:26

Guten Morgen,

sind das dann beides Fehlermeldungen vom System oder sind das deine eigenen (per ShowMessage(E.Message))?

Und bei dem DivideByZero-Testprogramm verhält es sich anders, d.h. da wird direkt der except-Block angesprungen?

Du könntest auch einfach mal selber ErrorProc auf eine eigene Prozedur umleiten und dann nur folgenden Code dort verwenden:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:

var
  E : Exception;
begin
  E := Exception.Create('Test-Exception');
  Raise E at Address,Frame;
end;

Und wenn der dann gefangen wird (ohne Dialog), dann temporär vor dem Clipboard-Aufruf diese ErrorProc-Prozedur verwenden und nachher wieder auf die ursprüngliche zurücksetzen.

galagher · Verfasst: Sa 23.05.20 09:38

Guten Morgen!

Th69 hat folgendes geschrieben :

sind das dann beides Fehlermeldungen vom System oder sind das deine eigenen (per ShowMessage(E.Message))?

Beides sind Fehlermeldungen vom System.

Th69 hat folgendes geschrieben :

Und bei dem DivideByZero-Testprogramm verhält es sich anders, d.h. da wird direkt der except-Block angesprungen?

Ja, ausserhalb der IDE schon. Mit der IDE kommt zuerst eine SIGFPE-Meldung und dann das except. Bei dem IntVar := pIntPointer^-Test verhält es sich ebenso, nur dass da mit der IDE eben eine SIGSEGV-Meldung kommt.

Th69 hat folgendes geschrieben :

Du könntest auch einfach mal selber ErrorProc auf eine eigene Prozedur umleiten und dann nur folgenden Code dort verwenden:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:

var
  E : Exception;
begin
  E := Exception.Create('Test-Exception');
  Raise E at Address,Frame;
end;

Und wenn der dann gefangen wird (ohne Dialog), dann temporär vor dem Clipboard-Aufruf diese ErrorProc-Prozedur verwenden und nachher wieder auf die ursprüngliche zurücksetzen.

Das verstehe ich einfach nicht!

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

galagher · Verfasst: Sa 23.05.20 12:36

Ok, ich habe ErrorProc nach dem Vorbild von sysutils.inc in meinen Code eingebaut, die Deklaration ErrorProc:=@RunErrorToExcept; habe ich in den initialization-Abschnitt von RichMemo.pas gesetzt. Deinen Code habe ich dann in Prozedur RunErrorToExcept eingefügt.

Ergebnis: Unverändert, alles ist wie vorher.

RunErrorToExcept wird nicht erreicht.

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

Th69 · Verfasst: Sa 23.05.20 13:37

Vllt. ist die Zuweisung zu früh (und sie wird von der anderen Initialisierung überschrieben).
Setze es mal direkt vor dem try.

galagher · Verfasst: So 24.05.20 19:59

Th69 hat folgendes geschrieben :

Vllt. ist die Zuweisung zu früh (und sie wird von der anderen Initialisierung überschrieben).
Setze es mal direkt vor dem try.

Welches try und welche Zuweisung genau meinst du:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

    try  {finally}  //<- dieses try?
      {Array aFormats (=die ClipBoard-Formate) befüllen und Daten in das Array aStreams schreiben}
      for i := 0 to n-1 do
      begin
        {Stream-Array anlegen für die ClipBoard-Formate}
        aStreams[i] := TMemoryStream.Create;
        aFormats[i] := ClipBoard.Formats[i];  //<- diese Zuweisung?
        {ClipBoard-Formate sichern}
        ClipBoard.GetFormat(aFormats[i], aStreams[i]);

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

galagher · Verfasst: Mo 25.05.20 22:03

Der SIGSEGV-Fehler tritt nur bei Zwischenablagendaten von meinen beiden alten Programmen auf, bei Zwischenablagendaten anderer aktueller Programme funktioniert es ja problemlos, also akzeptiere ich das erstmal so.

Wie ich heute festgestellt habe, funktioniert ClipBoard.Clear nicht. TClipBoard ist offenbar ein wenig buggy...

_________________
gedunstig war's - und fahle wornen zerschellten karsig im gestrock. oh graus, es gloomt der jabberwock - und die graisligen gulpen nurmen!

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme