Plattformübergreifend - Augenauswischerei ...?

[jik]

Zitat von Rollo62:

Ich habe mir vor kurzem die Steema TeeGrid Komponente angeschafft.
Die scheint alles das zu haben, was ich brauche und ist nicht gleich so ein DevExpress oder TMS Monster.

Danke für den Hinweis. Darf ich dich gleich was fragen?
1. Zwar scheint das Grid auch Unterknoten haben zu können, aber nur eine oder mehrere Ebenen? EDIT: scheints sie auch zu können
2. Grafiken im Header möglich?
3. Spalten mit Checkboxen und/oder Grafiken möglich?
4. Weil VCL dabeisteht: Plattformübergreifend ...? EDIT: Habs schon gesehen: ja

[Rollo62]

Zitat von jik:

Danke für den Hinweis. Darf ich dich gleich was fragen?
1. Zwar scheint das Grid auch Unterknoten haben zu können, aber nur eine oder mehrere Ebenen? EDIT: scheints sie auch zu können
2. Grafiken im Header möglich?
3. Spalten mit Checkboxen und/oder Grafiken möglich?
4. Weil VCL dabeisteht: Plattformübergreifend ...? EDIT: Habs schon gesehen: ja

Ich hab extra nochmal reingeschaut.
1. Es gibt anscheinend nur bis zu 1 Level SubColumns zu haben. Es gibt verschiedene Master-Detail und SubBands Beisiele, die aber noch nicht alle aktuell hier funktionieren.
Ich weiß auch nicht, warum die nicht einfach alles mit Sqlite oder anderen Daten machen, warum ODBC?
Sowas nervt, wenn die Demos nicht out-of-the-box laufen.
2. Grafiken im Header sehe ich keine Möglichkeit, es gibt viele Farb- Font usw, aber Bitmaps oder dergleichen im Header scheinen zu fehlen.
3. Ja, es gibt Checkbox und auch auch eins mit TeeCharts in den Spalten. Das habe ich mal auf bis 10000 Zeilen hochgezogen und viel mehr Stützpunkte, das war noch recht flott.
Also werden Grafiken auch ohne Probleme laufen, wenn es nicht gerade 15MB Images sind.
Prinzipiell ist es so umgesetzt:

Delphi-Quellcode:

procedure TFormCellEditors.SetupCustomEditors;
begin
  // Custom cell editor controls (default is TEdit):

  TeeGrid1.Columns['Height'].EditorClass:=TTrackBar;

  TeeGrid1.Columns['BirthDate'].EditorClass:=TDateEdit;

  TeeGrid1.Columns['Vehicle'].EditorClass:=TComboBox;

  TeeGrid1.Columns['EyeColor'].EditorClass:=TComboColorBox;

  TeeGrid1.Columns['Holidays'].EditorClass:=TCheckBox;

  TeeGrid1.Columns['Happiness'].EditorClass:=TNumberBox;
end;

Man kann anscheinend ziemlich beliebige Komponenten da reinwerfen, habe ich aber noch nicht weiter getestet.

Ich brauche das für kleine, Spreadsheet-ähnliche Ausgaben, wo ein StringGrid zu simpel ist.
Genau da passt es gut rein.
Es ist auch ein Spreadsheet-Sample dabei, allerdings nutzt das TeeBI Expressions dafür, welche wohl nicht im Paket dabei sind.
Hab ich noch nicht gecheckt wofür das gut ist, kaufen kann man das anscheinend nicht direkt.
Muss ich mich mal näher mit beschäftigen, es scheint aber nur ein paar Formel-Expression Klassen zu sein, so wird es zumindest im Example benutzt.

[Redeemer]

Zitat von Mavarik:

Zitat von jik:

4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Nein - D5 ist gruselig wenn wenigstens D2007 - aber was willst Du mit den alten Zeug?

Was ist denn bei D2007 so toll? D2009 ist mit Unicode und Generics meiner Meinung nach die bedeutendste Version von VCL-Delphi.

[himitsu]

Genau das ist es ja.

2006/2007 als die letzten Versionen ohne Unicode, für den (ersten) Upgrade von noch viel älteren Versionen.

[dummzeuch]

Zitat von Redeemer:

Zitat von Mavarik:

Zitat von jik:

4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Nein - D5 ist gruselig wenn wenigstens D2007 - aber was willst Du mit den alten Zeug?

Was ist denn bei D2007 so toll? D2009 ist mit Unicode und Generics meiner Meinung nach die bedeutendste Version von VCL-Delphi.

D2007 ist sehr stabil, was man von Delphi 2009 und diversen späteren Versionen meiner Erfahrung nach nicht behaupten kann. Und "kein Unicode" heißt für viele schlichtweg "Strings sind einfacher". Ich habe noch diverse Projekte in Delphi 2007 und viele davon werde ich vermutlich auch nie updaten.
Aber da mögen Erfahrungen abweichen, je nachdem welche Art von Programmen man schreibt, und es ist auch nicht wirklich das Thema hier.

[DSCHUCH]

Hallo, ohne hier jetzt den ganzen Thread gelesen zu haben:

aber wir haben unsere VCL Anwendung mit Wine auch unter Linux am Laufen. Mit FastReport sowie DevExpress. Inwiefern das mit MAC klappt, kA. Vielleicht einen Versuch wert.

VG.

[jik]

Hallo Dschuch,

ja, das haben wir natürlich auch, beim Mac oft mit Parallels oder Crossover. Aber es sind drei Dinge auf einmal: Plattformübergreifend, 64bit und Unicode - es handelt sich um ein Programm für Schriftsteller. Und ich dachte, es wäre vielleicht mal Zeit ...

Aber leider sieht die Sache so aus, dass wir problemlos plattformübergreifend werden könnten, hätten wir keine Fremdkomponenten. Und genau die machen den Strich durch die Rechnung: Developer Express, Sergey Tkachenko mit seinem wirklich tollen Editor TRichViewEdit und dem seitenweisen Wrapper TSRichViewEdit sowie die Komponente zur direkten PDF-Erzeugung. Für keine der drei gibt es eine plattformübergreifende Lösung, weder bei Delphi 12 noch bei Lazarus.

Während Lazarus eine recht angenehme IDE hat, ist Delphi mittlerweile mit so viel Zeug überfrachtet, was wir maximal zu 2% nutzen könnten, dass ich sogar zu Lazarus tendiert hätte. Nur weiß ich nun eben leider, was ich zu Beginn dieses Threads noch nicht wusste: Es geht schlichtweg nicht. Also weiterhin Wine, Parallels (oder andere VMs) und Crossover. Und viele Anwender, die nicht kaufen, weil sie eine Live-Anwendung unter ihrem OS wollen.

Viele Grüße
Martin

[QuickAndDirty]

Sound less like a Delphi-issue and more like a skill issue...
Ich würde mich auf einen konstruktiven Weg konzentrieren und die Probleme angehen.
1. Die Idee kennen lernen und lernen Nutzen aus den Werkzeugen zu ziehen.
2. Persistenz und Logik aus der Oberfläche in eigene units verlagern.
3. Eine neue Oberfläche in FMX bauen, evtl. eigene komponenten bauen.

Statt dessen, ein Umstieg auf Lazarus ist vermutlich auch möglich.
Beides erfordert eben Arbeit in das Projekt zu stecken die man seit
Jahren oder Jahrzenten versäumt hat aufzuwenden.
Diese technischen Schulden und die Zinsen und Zinseszinsen dieser Schulden müssen eben abgearbeitet werden.
Mit Lazarus hätte man dann zumindest eine kostenfreie IDE und damit steigt vielleicht die Motivation
in Zukunft das Projekt regelmässig zu warten, damit es mit den Veränderungen der Sprache und des
Ökosystems an Komponenten schritthält.

Dann steht evtl. noch zu entscheiden ab wievielen Jahrzenten an Vernachlässigung einer Codebasis man soviel technische schulden angehäuft hat , dass man sie auch abschreiben kann und was neues anfängt, in einer möglicherweise populäreren Sprache.
Vielleicht in C++ mit dem QTCreator.
Oder als WebApp / Universal App oder ähnliche auf allen Systemen laufende Anwendung.

Wenn das haupt Problem die TRichEdit Kompenente ist and daran die existenz der ganze Anwendung hängt,
sollte man sich vielleicht überlegen diese Komponente generel inhouse neu zu bauen um Abhängigkeiten zu verringern.