AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Seltsames Verhalten der Destruktoren

Ein Thema von Delbor · begonnen am 12. Dez 2017 · letzter Beitrag vom 13. Dez 2017
Antwort Antwort
Seite 2 von 2     12   
hoika

Registriert seit: 5. Jul 2006
Ort: Magdeburg
8.276 Beiträge
 
Delphi 10.4 Sydney
 
#11

AW: Seltsames Verhalten der Destruktoren

  Alt 12. Dez 2017, 14:51
Hallo,
zeig mal bitte die Zeilen des Erstellens und der Freigabe der beiden Frames.

Hast kein VCS, um auf den alten Stand zurückzuspringen?
Heiko
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.299 Beiträge
 
Delphi 10.3 Rio
 
#12

AW: Seltsames Verhalten der Destruktoren

  Alt 12. Dez 2017, 14:56
Mal ganz platt gefrag:

Kann es sein, das einer der Aufrufe:

Delphi-Quellcode:
  FPages.Free;
  PDFPageClass.Free;
  FReportList.Free;
noch auf _Document zugreift ?
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
Delbor

Registriert seit: 8. Okt 2006
Ort: St.Gallen/Schweiz
1.186 Beiträge
 
Delphi 11 Alexandria
 
#13

AW: Seltsames Verhalten der Destruktoren

  Alt 12. Dez 2017, 21:12
Hi zusammen

Sorry, wenn ich erst jetzt antworte - Hausmannspflichten haben gerufen, bzw. sich schon fast die Seele aus dem Leib geschrien...

Die beiden Frame-Instanzen werden nicht zur Laufzeit erstellt, sondern per Klick im OI auf Frames und nach Klick auf die Mainform/eine Panelgroupseite zw ein Panel ähnlich wie eine Kompoonwnte an der gewünschten Stelle angelegt. Beide Instanzen erben also nur den Constructor-Code des Basisframes:
Delphi-Quellcode:
constructor TPDFiumFrame.Create(AOwner: TComponent);
begin
{$IFDEF TRACK_EVENTS}
  AllocConsole;
{$ENDIF}
  inherited;
  ControlStyle := ControlStyle + [csOpaque];
  FZoom := 100;
  FPageIndex := -1;
  PDFPageClass := TPDFPageClass.Create;
  FSelBmp := TBitmap.Create;
  FSelBmp.Canvas.Brush.Color := RGB(50, 142, 254);
  FSelBmp.SetSize(100, 50);

  FPages := TList.Create;
  FReportList := TStringlist.Create;
  FReportList.Sorted := False;
  FGetPageAt := 0;
  try
    FPDF_InitLibrary;
  except
    FStatus := TLabel.Create(Self);
    FStatus.Align := alClient;
    FStatus.Parent := Self;
    FStatus.Alignment := taCenter;
    FStatus.Layout := tlCenter;
    FStatus.Caption := sUnableToLoadPDFium;
  end;
end;
Wie ich auch in andern Threads schon gesagt habe, geht es darum, 2 Frames, oder eben besser, 2 Frameinstanzen, die auf dem selben Basisframe beruhen, zu synchronisieren. Im Anhang mal ein Screenshot meiner Testanwendung: Links der kleine, schmale Frame zeigt mehrere Seiten des Dokumentes. Ein Klick auf solch eine (z.B. die 3.) soll nun diese Seite in der rechten, grösseren Frameinstanz anzeigen.
Nach längerer Zeit hab ichs dann geschafft, dass in PDFiumFrame1 für jede angeklickte Seite auch dren korrekter Index, bzw. die Seitennummer, angezeigt wurde:
Delphi-Quellcode:
procedure TSynpdfMain.PDFiumFrame1MouseUp(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
  var SP, FP,MousePos :TPoint; Index : Integer; Page : TPDFiumFrame.TPDFPageClass;
begin
  Memo1.Lines.Clear;
  Memo1.Lines.Add('------ PDFiumFrame1MouseUp ------');
//(1)
  MousePos.X:= X;
  MousePos.Y:= y;
  Page := PDFiumFrame1.PageAt[MousePos];
//(2)
  PDFiumFrame2.PageIndex := Page.Index;
// PDFiumFrame2.PDFSelPage.Index := Page.Index;
  PDFiumFrame2.SetChoosePage(Page.Index);
end;
Obiger Code entstand in den letzten Tagen; an den mit //(1) bezeichneten Stellen befindet sich Code, der mir zum einen die Seitengrössen und Indexe in PDFiumFrame1 in ein Memo ausgibt und zum andern bei (2) den Index und den Klassennamen der angeclickten Seite.
Die Methode PDFiumFrame1.PageAt[MousePos]; ist eine vom Basisframe geerbte Funktion. Und Page schliesslich ist ein Property vom Typ TPDFPage des Basisframes. Letztere Klasse ist allerdings im Basisframe privat deklariert und somit eigentlich unsichtbar. Mit DeddyHs Hilfe hab ichs dann doch geschafft. Ein Ausschnitt aus der Deklaration des Basisframes :
Delphi-Quellcode:
    procedure SetPageIndex(Value : Integer);
  public
    { Déclarations publiques }
    type
      TPDFPageClass = TPDFPage;
  public
    PDFPageClass : TPDFPageClass;
     
    constructor Create(AOwner: TComponent); override;
Aus dem Constructor des Frames:

Delphi-Quellcode:
  FPageIndex := -1;
  PDFPageClass := TPDFPageClass.Create;
... und einer aus der Mainform:
Delphi-Quellcode:
procedure TSynpdfMain.PDFiumFrame1MouseUp(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
  var MousePos :TPoint; Index : Integer; Page : TPDFiumFrame.TPDFPageClass;
begin
...
...
  MousePos.X:= X;
  MousePos.Y:= y;
  Page := PDFiumFrame1.PageAt[MousePos];
Und schliesslich befindet sich die in TSynpdfMain.PDFiumFrame1MouseUp aufgerufene Methode PDFiumFrame2.SetChoosePage(Page.Index) ebenfalls im Basisframe und wird von diesem an seine Instanzen vererbt.:

Delphi-Quellcode:
procedure TPDFiumFrame.SetChoosePage(Value: Integer);
begin
  if Self.PageIndex <> Value then
    Self.PageIndex := Value;
  Self.LoadVisiblePages;
  Application.ProcessMessages;
end;
Die aufgerufene Methode LoadVisiblePages:

Delphi-Quellcode:
procedure TPDFiumFrame.LoadVisiblePages;
var
  Index, Z, Marge: Integer; Page : TPDFPage; LSelectedPage : TRectD;
  Top, Scale : Double; LClient, LRect : TRect;
begin
  FPageIndex := -1;
  FCurPage := nil;
  for Index := 0 to FPages.Count - 1 do
  begin
    Page := FPages[Index];
    if Page.Selection = nil then
      Dec(Page.Visible);
    else
      Page.Visible := 0;
  end;
  LClient := ClientRect;
  Top := 0;
  Z := 0;
  Marge := PAGE_MARGIN; //const PAGE_MARGIN = 5; // pixel
  Scale := FZoom / 100 * Screen.PixelsPerInch / 72;
  for Index := 0 to FPageCount - 1 do
  begin
  // compute page position
    LRect.Top := Round(Top * Scale) + Marge - VertScrollBar.Position;
    LRect.Left := PAGE_MARGIN + Round((FTotalSize.cx - FPageSize[Index].cx) / 2 * Scale) - HorzScrollBar.Position;
    LRect.Width := Round(FPageSize[Index].cx * Scale);
    LRect.Height := Round(FPageSize[Index].cy * Scale);
    if LRect.Width < LClient.Width - 2 * PAGE_MARGIN then
      LRect.Offset((LClient.Width - LRect.Width) div 2 - LRect.Left, 0);
  // visibility test
    if LRect.IntersectsWith(LClient) then
    begin
      if FPageIndex < 0 then
        FPageIndex := Index;
      Page := GetPage(Index);
      Page.Rect := LRect;
      Page.Visible := 1;
    end;
  // don't go below LClient area
    if LRect.Top > LClient.Bottom then
      Break;
  // next page top position
    Top := Top + FPageSize[Index].cy;
    Inc(Marge, PAGE_MARGIN);
  end;
  // release any page that was not visibile for the last 5 paint events
  for Index := FPages.Count - 1 downto 0 do
  begin
    Page := FPages[Index];
    if Page.Visible < -5 then
    begin
      Page.Free;
      FPages.Delete(Index);
    end;
  end;
end;
Eigentlich hatte ich gehofft, dass ich mit der Übergabe des in PDFiumFrame1 ermittelten Seitenindexes an PDFiumFrame2 hier so die entsprechende Seite anzeigen lassen könnte. Das funktioniert so aber nicht.
Vielmehr denke ich, dass hier die eigentliche Quelle des deerzeitigen Problems steckt. Zur Erinnerung:
Delphi-Quellcode:
procedure TSynpdfMain.PDFiumFrame1MouseUp(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
  var MousePos :TPoint; Index : Integer; Page : TPDFiumFrame.TPDFPageClass;
begin
...
...
  MousePos.X:= X;
  MousePos.Y:= y;
  Page := PDFiumFrame1.PageAt[MousePos];
Hier wird von PDFiumFrame1.PageAt eine Seite zurückgegeben. Deren Index wird in TPDFiumFrame.SetChoosePage dem Property PageIndex des Basisframes zugewiesen. Dmit verfügt der Basisframe über ein Seitenhandle mehr, als in der Liste Pages gespeichert sind. Diese Liste wird bei Programmende freigegeben - nicht aber die Seite, die sich (noch) nicht in der Liste befindet, weshalb das Dokument nicht freigegeben werden kann.
So zumindest meine bisherige Erklärung für das zur Zeit auftretende Problem. Der Basisframe verfügt über ein Boolean-Feld FReload. Dessen Verwendung:
Delphi-Quellcode:
procedure TPDFiumFrame.PaintWindow(DC: HDC);
var
  Index : Integer;
  Page : TPDFPage;
  Client: TRect;
  WHITE : HBrush;
  SelDC : HDC;
  Blend : TBlendFunction;
begin
  FInvalide := False;
...
// check visibility
  if FReload or (FPages.Count = 0) then //<==
  begin
    LoadVisiblePages;
    PDFiumFramePaintWindowToMemo1;
    FReload := False;
  end;
// page background
Diese Art der Programmierung mit dauerndem Laden/Entladen der Seitenhandles ist für mich sehr ungewöhnlich, weshalb ich alles andere als sicher bin, die Arbeitsweise des Programms wirklich verstanden zu haben.

Gruss
Delbor
Roger
Man muss und kann nicht alles wissen - man muss nur wissen, wo es steht.
Frei nach Albert Einstein
http://roase.ch

Geändert von Delbor (12. Dez 2017 um 22:20 Uhr)
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.299 Beiträge
 
Delphi 10.3 Rio
 
#14

AW: Seltsames Verhalten der Destruktoren

  Alt 13. Dez 2017, 03:49
Einen Wunderschönen Guten Morgen

Frame1 stellt also die Thumbnails der Seiten eines Dokumentes dar (als Liste sozusagen) während Frame2 die ausgewählte Seite in einer großen Ansicht präsentiert.

D.h. beide Frames arbeiten mit dem gleichen Dokument und damit mit dem gleichen Dokumentenhandel.

Beim schließen des Dokumentes passiert nun folgendes:

Frame2.Destructor räumt sich auf und gibt das Handel vom Dokument frei.

danach

Frame1.Destructor räumt sich auf und versucht das Handel des Dokumentes frei zu geben.

Da Frame2 das schon gemacht hat, gibts eine AV.

Sinnvoller wäre es, das Dokument in der Form zu erzeugen und wieder frei zu geben und das ganze dann an die Frames zu übergeben.
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
Delbor

Registriert seit: 8. Okt 2006
Ort: St.Gallen/Schweiz
1.186 Beiträge
 
Delphi 11 Alexandria
 
#15

AW: Seltsames Verhalten der Destruktoren

  Alt 13. Dez 2017, 09:11
Hi Ghostwalker

Dir auch einen guten Morgen!

Zitat:
Beim schließen des Dokumentes passiert nun folgendes:
Frame2.Destructor räumt sich auf und gibt das Handel vom Dokument frei.

danach

Frame1.Destructor räumt sich auf und versucht das Handel des Dokumentes frei zu geben.
Da Frame2 das schon gemacht hat, gibts eine AV.
Sorry, wenn ich dir widerspreche! Bau dir doch mal ein kleines Testprogramm, ohne jede Komponente. Wenn du nun in der Toolleiste unter 'Standard<=Frames' dieses anklickst, dann auf die Form dahin klickst, wo du denn Frame haben willst, geschieht - nichts. Da zu dem Projekt noch kein Frame existiert, gibts auch keine Liste mit zur Verfügung steheden Frames, die dir angezeigt werden könnte.
Abhilfe schaffen 2 Möglichkeiten:
  • Du hast einen Frame, den du gerne in dem Projekt verwenden möchtest, der aber in einem völlig anderen Ordner liegen hast.
    • Öffne diesen Frame und speichere ihn unter dem gleichen Namen(wichtig!!!). aber natürlich nur den Dateinamen, in deinem Projektverzeichnis.
    • Dann klickst du auf <Projekt =>> Dem Projekt> hinzufügen und wählst nun die *.pas des Frames, um sie hinzuzufügen.
    • Nun kannst du ihn in der Toolpalette unter Frames auch auswählen.
  • Alternativ dazu kannst du unter >Datei =>> Neu =>> weitere> als neu zu erstellendes Objekt einen Frame wählen und erhälst nun einn leeres Feld, ähnlich wie bei einer Form
  • Diesen speicherst du wiederum im Projektorder. Dem Projekt hinzufügen musst du diesmal nicht - das hat Delphi schon gemacht

Nun hast du dem Projekt einen Basisframe hinzugefügt. Auf der Form hingegen befindet sich noch keine Frameinstanz. Nun setze im Projektverzeichnis einen Haltepunkt auf die Mainform - der soeben hinzugefügte Frame ist zwar in der uses-Liste vorhanden, nicht aber zwischen begin/end.
Wenn du nun das Projekt startest, wirst du bemerken, dass vor dem Erzeugen der Mainform der Basisframe erzeugt wird. Zumindest, wenn du diesem einen construktor himzugefügt hast und mit F7 durchstepst.
Bei Programmende laufen die Prozeduren in umgekehrter Reihenfolgee ab. Erst wird also die Form (mit ihren allfälligen Frameinstanzen) freigegeben und erst dann der Basisframe. Zusammen mit den Frameinstanzen werden auch deren Komponenten, Klassen und Handles freigegeben - _Document ist letzteres. Das _Document des Basisframes wird also erst mit diesem freigegeben (bzw. sollte vor dessen Zerstörung freigegeben werden. Aber da bin ich mir nicht sicher).

Vererbung erfolgt immer vom Basisframe zur Frameinstanz, umgekehrt jedoch nicht (wie das in Delphi überall der Fall ist). Wenn die Frameinstanzen der Form zerstört werden, werden also auch allfällige Handles dieser Instanzen zerstört, nicht aber das im Basisframe enthaltene Handle - das verzieht sich erst mit dem Basisframe ins Nirwana.

Wenn nun das Dokument 7 Seiten enthält und ich mir, wie oben ausgeführt, von der Prozedur GetPageAT eine Seite zurückgeben lasse, existieren erstmal acht Seiten. - zumindest in einer (oder auch beiden) Frameinstanzen. Dies wird in der Prozedur LoadVisiblePages bereinigt, wo alle nicht sichtbaren Seiten freigegeben werden. Anbei ein Ausschnitt aus PaintWindow:
Delphi-Quellcode:
// check visibility
  if FReload or (FPages.Count = 0) then
  begin
    LoadVisiblePages;
    PDFiumFramePaintWindowToMemo1;
    FReload := False;
  end;
FReload muss hier also true sein, dass LoadVisiblePages aufgerufen wird.
So, wie ich den Programmablauf bisher verstanden habe, wird also ohne Aufraufe von PaintWindow und LoadVisiblePages und dem setzen von FReload auf True gar nichts neu gezeichnet, und es werden auch keine nichtsichtbaren Fenster gelöscht - auch deren Handles nicht.
Ich habe bislang noch nie mit Handles direkt gearbeitet, aber ich würde mich wohl schwer irren, wenn Windows ein Handle löschen (lassen) würde, das noch selbst ein gültiges Handle besitzt.

Ich weiss nicht, ob ich nun alles richtig verstanden habe, aber - weitermachen zeigt, was Sache ist.

Gruss
Delbor

PS:
Zitat:
Sinnvoller wäre es, das Dokument in der Form zu erzeugen und wieder frei zu geben und das ganze dann an die Frames zu übergeben.
Nein, in diesem Fall nicht. TPDFiumFrame ist in sich selbst voll funktionstüchtig. Zusammen mit der mitgelieferten Unit PDFium.Wrapper; gehörte er zu einem Beispielprojekt. Ich habe ihn hier in diese Anwendung auf die oben beschriebenen Weise importiert und die Wrapper-Unit unter diesem Projekt abgespeichert und hinzugefügt. Mehr braucht es - ausser der PDFium.dll - nicht, um PDF-Dokumente anzeigen und darin hin-und her scrollen zu können. Würde ich die Erzeugung des Dokumentes in die Form verlegen, müsste ich auch den ganzen Code des Basisframes in die Formunit verlegen - und das sind doch unter Berücksichtigung der Kommentare und meiner Report- und Memo-Ausgaben knappe tausend Zeilen. (Aktuell, mit allen meinen Änderungen: 1051)
Roger
Man muss und kann nicht alles wissen - man muss nur wissen, wo es steht.
Frei nach Albert Einstein
http://roase.ch

Geändert von Delbor (13. Dez 2017 um 09:42 Uhr)
  Mit Zitat antworten Zitat
Delbor

Registriert seit: 8. Okt 2006
Ort: St.Gallen/Schweiz
1.186 Beiträge
 
Delphi 11 Alexandria
 
#16

AW: Seltsames Verhalten der Destruktoren

  Alt 13. Dez 2017, 10:12
Hi Ghostwalker
Mal ganz platt gefrag:

Kann es sein, das einer der Aufrufe:

Delphi-Quellcode:
  FPages.Free;
  PDFPageClass.Free;
  FReportList.Free;
noch auf _Document zugreift ?
Nein. Keiner.
FPages ist ein TListobjekt des Basisframes, in dem die Handles der Seiten gespeichert werden.
PDFPageClass ist eine Instanz der TPDFPageClass , die von der im Basisframeprivat deklarierten Klasse PDFPage abgeleitet ist und ausser eine einzige Instanz zu Erzeugen nichts tut.
Im Verlaufe des Programmes deklarire ich eine Variable diese Typs (der eine meiner Änderungen ist), die nun in der Lage ist, eine Instanz des Vorfahren aufzuehmen. Ob ich da wirklich eine Instanz des Typs PDFPageClass brauche, bin ich mir im Moment jedoch nicht so klar.

Gruss
Delbor
Roger
Man muss und kann nicht alles wissen - man muss nur wissen, wo es steht.
Frei nach Albert Einstein
http://roase.ch
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:02 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