TAChart Probleme in Frames

[af0815]

Ich habe hier ein Layout das auf Frames aufgebaut ist, die zur Laufzeit erstellt werden. Wobei die Frames von Vorlageframes vererbt werden.

Es gibt Probleme wenn ich eine TAChart in das Layout einfüge, das ganze kompiliere, so gibt es sigsev im constructor

Code: Alles auswählen

constructor TFrameBase.Create(AOwner: TComponent);
begin
  inherited Create(AOwner); // <<--- hier 
  FXMLPropStorage:= nil;
  FOnSelect:=nil;
  FSelected:=False;
  FCon:=nil;
  FOnCheckConnection:= nil;
  FInit := False;
end;
 

Dieser Konstruktor wird von den Kindern ebenso verwendet um ganz einfach das Frame zu initialisieren.

Entferne ich die TAChart, so läuft der Konstruktor ohne Probleme durch. In gewissen Konstellationen hat es durchaus funktioniert. Es ist aber nicht Kompilerabhängig, das Problem besteht sowohl bei (FPC/Lazarus) stable/stable, trunk/1.8RC4 als auch trunk/trunk.

Mal sehen ob ich das in einem vereinfachten Beispiel weitergeben kann. Den aktuellen Code kann ich nicht veröffentlichen.

Andreas

Edit: Beispiel erstellt

published.zip

Probleme mit TAChart in Frames

(8.65 KiB) 55-mal heruntergeladen

[Michl]

Als Workaround: Wenn du in die Uses-Klausel von frmopfehler "TATools" mit einbindest, funktioniert alles. Das Problem ist, daß im Initialization-Abschnitt von TATools OnInitBuiltinTools := @InitBuiltinTools gesetzt wird.

Es reicht auch in die Implementation-Uses-Klausel von unit TAGraph "TATools" aufzunehmen.

[af0815]

Ich bin gerade auch auf die Zeile gestossen, allerdings in TAGraph-constructor TChart.Create(AOwner: TComponent); So um Zeile 690

Code: Alles auswählen

  FExtent := TChartExtent.Create(Self);
  FExtentSizeLimit := TChartExtent.Create(Self);
  FMargins := TChartMargins.Create(Self);
  FMarginsExternal := TChartMargins.Create(Self);
 
  FBuiltinToolset := OnInitBuiltinTools(Self);  // <--- HIER 
  FActiveToolIndex := -1;
 
  FLogicalExtent := EmptyExtent;
 

Da gibt es um die Zeile 475 einen Hinweis

Code: Alles auswählen

 
//  TATools;  // needed to initialize OnInitBuiltinTools; added to avoid crash of converted Delphi projects
// wp: removed again, causes compilation error with fpc 2.6.4
 

[wp_xyz]

Wenn man das "uses TATools" in TAGraph mit einem {$IF FPC_FULLVERSION >= 30000} umgibt, könnte man das Problem für einen aktuellen FPC lösen, aber nicht für FPC2.6.4, der eigentlich immer noch unterstützt wird: Dieser kann mit der "Fast-Zirkulärreferenz" offenbar nicht so gut umgehen wie FPC 3.0+ (TATools: "uses TAGraph" in interface, und TAGraph: "uses TATools" in Implementation).

Ich frage mich aber, wieso das Problem nur mit Frames auftritt.

[af0815]

Was ist damit wenn im initialization Bereich von TAGraph auf eine Dummy-Routine initialisiert wird. Damit kann in der Initialsierung von TATools (oder sonstwo), dann überschrieben werden. Damit bäbe es keine Abhängigkeit von TATools innerhalb von TAGraph.

Das wäre IMHO sauber.

[wp_xyz]

Damit hinge die Verwendbarkeit der standardmäßig verwendbaren Zoom und Pan-Funktionen von der Reihenfolge ab, in der die Units in "uses" aufgerufen werden, oder nicht?

[af0815]

Damit hinge die Verwendbarkeit der standardmäßig verwendbaren Zoom und Pan-Funktionen von der Reihenfolge ab, in der die Units in "uses" aufgerufen werden, oder nicht?

Wenn diese Tools standardmässig vorhanden sind, dann gehört aber das TATools in TAGraph eingebunden und der Fehler bei 2.6.4 gesucht und gefixt.

Vor allen das bei einen Create-Construktor einer Komponente das auftritt ist schon hart. Vor allen hängt der Fehler ja auch von der Reihenfolge oder nicht verwenden in der uses Klausel ab. Nur bei einem Form ist die Wahrscheinlichkeit höher, das ich die Tools verwende. Wenn ich jetzt kein Frame verwende, sondern das ganze fürs Reporting nehme, egal LazReport oder FPReport, so ist der aktuelle Fehler ein absoluter Horror. Denn dort benötige ich sicher keine Tools.

Somit ist der Weg der richtige wenn in TAGraph eine Dummy initialisiert wird. Wenn das Toolset dazukommt, so muß es sich dort dann richtig eintragen. Um, zirkulare Refernzen zu vermeiden, gehört die Funktion nicht dann in eine extra unit (zB. TChartUtils), die dann sowohl von TAGraph als auch von TATools verwendet wird.

Andreas

[wp_xyz]

Ich werde jetzt wegen einer "Kleinigkeit" mit Sicherheit nicht an der Unit-Architektur von TAChart herumbasteln, danach funktioniert mit Garantie nichts mehr.

Was mir die ganze Zeit nicht klar war: Warum funktioniert das alles ohne "uses TATools", wenn TAChart auf einem Formular sitzt, warum nicht auf einem Frame?

Nun, wenn man einen TChart aufs Formular klickt, wird automatisch die Package-Unit tachartlazaruspck.pas mit ins "uses" der Projekt-Datei aufgenommen; dort ist TATools eingebunden, und damit kann TChart in seinem Create die Unit TATools finden (auch ohne "uses", denn die Funktionsvariable "OnInitBuiltinTools" ist bei der Initialisierung von TATools mit einer gültigen Adresse belegt worden).

Bei deinem Projekt ist tachartlazaruspkg nicht eingebunden. Schreibe ich es in die uses-Zeile des Projekts, läuft alles wunderbar.

Code: Alles auswählen

program FrameProblem;
 
{$mode objfpc}{$H+}
 
uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms, frmMainFrameTest, frmXXXXmain, frbaseframe, LazLogger,
  frmopfehler, 
  tachartlazaruspkg;   // <--------- NEU 

Erzeuge ich ein eigenes Projekt mit Chart auf einem TFrame, wird tachartlazaruspkg in "uses" aufgenommen. Hast du das evtl. manuell herausgelöscht, oder die Dateien aus verschiedenen Projekten zusammenkopiert?

[af0815]

Betrachte die Unit als losgelöst von einem fixen Programm.

Die Units werden in einer eigenen Umgebung erstellt bzw. getestet (teilweise unittesting) und dann in die eigentliche Applikation aufgenommen. Auch werden die Units/Frames in verschiedenen Programmen verwendet. Man darf somit NICHTS in der Programmdatei (lpr) voraussetzen.

Für mich ist es nicht nachvollziehbar, warum das in der lpr drinnen stehen muss/soll. Genaugenommen wird normalerweise nur die Mainform und der LazLogger drinnengelassen. Das ist identisch mit einem neuen Projekt wo nur ein Formular eingebunden und erzeugt wird. Alle anderen Formulare bzw. Frames werden später zur laufzeit erzeugt. Das kann natürlich auch mit entsprechenden Factories geschehen. Das ist der Hintergrund.

Wenn es in Lazarus runder funktionieren würde, würden die Forms und Frames in dlls kommen und je nachdem dynamisch geladen werden.

Andreas

[Michl]

Was ist damit wenn im initialization Bereich von TAGraph auf eine Dummy-Routine initialisiert wird. Damit kann in der Initialsierung von TATools (oder sonstwo), dann überschrieben werden. Damit bäbe es keine Abhängigkeit von TATools innerhalb von TAGraph.

Das wäre IMHO sauber.

Das habe ich eben mal mit deinem Beispiel probiert. Das Erstellen des Charts funktioniert dann, jedoch wird kurz darauf ein Error geworfen, weil kein gültig Drawer vorhanden ist (TATools wird auch später nirgends eingebunden).

Aber davon abgesehen ist es nicht sauber, ungeprüft eine Funktion aufzurufen, wenn nicht garantiert ist, daß sie vorhanden ist. MMn müsste dann TATools zwingend in die Implementation-Uses-Klausel aufgenommen, eine Exception mit einer besseren Ursachenbeschreibung geworfen oder sonstig das Design geändert werden.

Just my 2 cents.

[Michl]

@wp: Evtl. könnte ja wirklich einfach eine entspechende Exception erstellt werden (Patch anbei - Exception-Text könnte evtl. verbessert werden) und diese Fehlermeldung in die FAQ aufgenommen werden?! Dann könnte der Nächste, der über das Problem stolpert, gezielt nach einer Lösung suchen.

[wp_xyz]

Nein, ich denke, z.B. in einem nogui-Programm braucht man TATools ja überhaupt nicht, und es sollte die Möglichkeit bestehen, TAChart ohne TATools verwenden zu können. Daher habe ich jetzt im Trunk die Funktionsvariable OnInitBuiltinTools gleich bei der Deklaration auf nil gesetzt und rufe diese Funktion entsprechend nur dann auf, wenn die Variable nicht mehr nil ist. Dadurch wird natürlich das BuiltinToolset nicht mehr erzeugt und es kommt zu späteren Laufzeitfehlern, weil man bisher davon ausgegangen ist, dass FBuiltinToolset nie nil ist. Die Laufzeitfehler werden aber nun durch eine zusätzliche Nil-Prüfung abgefangen, und Andreas' Programm läuft nun ohne Crash und ohne Änderung an den verwendeten Units durch.

Bitte ausgiebig testen, bevor ich das in die Backport-Liste für Version 1.8 eintrage (ich hoffe, die Version dauert noch ein bisschen...).

Andreas, bitte beschwere dich nicht, wenn künftig in einem, wie von dir beschrieben, kastrierten Projekt die automatische Zoomfunktion von TAChart nicht mehr funktioniert, denn dafür braucht man das Builtin-Toolset. Ein "normales" Projekt mit tachartlazaruspkg in der Projektunit funktioniert natürlich weiterhin; alternativ kann man auch TATools in die uses-Liste aufnehmen, ohne die Toolset-Komponente aufs Formular zu klicken.

[af0815]

Wenn die Info in die FAQ kommt, gibt's keine Beschwerden
Das mit dem Headless wird für die Reports noch interessant.


Danke an euch beide.

Andreas

[af0815]

Zur Info, es gibt noch weitere Problemchen in Frames. Ich habe nur keine Zeit das tiefer zu Untersuchen.

TAChart und fpSpreadSheet :
Verbinde ich die beiden mittels einer TsWorkbookChartSource, so kann es sein, das die App nicht mehr (richtig) auf Eingaben reagiert. Hebe ich die Verbindung auf und versorge TAChart über ein DS mit denselben Daten, so geht es ohne Probleme. (Auch aktualisierter Trunk). Ich habe die Vermutung, das da sich die Observer der beiden Komponenten in bestimmten Fällen gegenseitig aktivieren können und so den Effekt auslösen.

Was noch dazukommt, das zur Laufzeit zwischen einer ListChartSource und der WorkbookChartSource umgeschalten wird. Das dient dazu das man die Grafik auch optisch parametrieren kann und zu Laufzeit auf die echten Daten zugegriffen wird.

Wenn ich Zeit habe, werde ich versuchen ob dazu ein Beispiel zusammen stellen kann, wo das Problem ersichtlich ist.

Andreas