GUI - Framework

[hanspeter]

Hallo,

ich habe eine Anfrage in der ein Kunde die Oberfläche eines älteren Programms etwas modernisieren will.
Er möchte dazu die Tools und Componenten von Developer Express verwenden.
Von ExpressQuantumGrid mal abgesehen,bin ich am Überlegen, ob der Kunde besser beraten ist, wenn er FireMonkey verwendet.
Alternativ auch die alten Komponenten belassen und stattdessen unter XE2 Themes verwenden.
Was ist Eure Meinung?


Mit Gruß
Peter

[himitsu]

Gibt es schon einen VCL-FM-Konverter?


Wenn man bei der VCL bleibt, dann wird es vermutlich weniger Arbeit.
Und wenn er das Progamm nicht unter Mac/Linux ausführen will oder kann (falls es der restliche Programmcode überhaupt erlaubt), dann hat FM doch eigentlich keine Vorteile?
Wie sieht es überhaupt inzwischen mit den DBGrids in FM aus?

[stahli]

Soll es bunter aussehen, oder spielt auch eine bessere Funktionalität eine Rolle?
Man müsste sicherlich berücksichtigen, welchen Umfang das Projekt hat (DB? Komplexität?).
Wer bezahlt denn die Änderung? Besteht der Kunde auf bestimmten Komponenten?

[mkinzler]

Zitat:

Zitat von himitsu (Beitrag 1142277)

Gibt es schon einen VCL-FM-Konverter?

Ja, sogar mehrere
http://pascalcoder.blogspot.com/sear.../MonkeyGroomer
http://www.midaconverter.com/

[hanspeter]

Zitat:

Zitat von stahli (Beitrag 1142282)

Soll es bunter aussehen, oder spielt auch eine bessere Funktionalität eine Rolle?
Man müsste sicherlich berücksichtigen, welchen Umfang das Projekt hat (DB? Komplexität?).
Wer bezahlt denn die Änderung? Besteht der Kunde auf bestimmten Komponenten?

Das Framework ist vorgegeben, wobei ich nicht so ganz glücklich mit dem Express Quantum Grid bin.
Das ist mir noch als kompliziert in der Bedienung und träge in Erinnerung.
Die Änderung zahlt der Kunde und es geht wohl um eine "modernere" Oberfläche, da das Projekt noch im Delphi 3 Stil daherkommt.

Peter

[himitsu]

Also, um Prinzip kann man dem Teil auch einfach ein GUI-Manifest verpassen ... und schon sieht es ebenfalls "neuer" aus. :stupid:

[Bummi]

Zitat:

Das Framewprk ist vorgegeben, wobei ich nicht so ganz glücklich mit dem Express Quantum Grid bin.
Das ist mir noch als kompliziert in der Bedienung und sehr träge in Erinnerung

Die Performance hat mit den letzen Updates deutlich zugelegt, in die Bedienung muss man sich einmal einarbeiten, dann geht es locker.
Ich habe das ganze soweit in meinen Templates implementiert, dass ich mich um Feldveröffentlichungen, im/exporte, Filter, Speicherung von Zuständen im Rahmen der weiteren Entwicklung nicht kümmern muss (natürlich kann wo nötig).
Um all das abzubilden was damit möglich ist ist ansonsten doch ein immenser Aufwand nötig.

[blackfin]

Um einer alten Anwendung "mal schnell" zu einem neueren Aussehen zu verhelfen, eignet sich auch VCLSkin.
Hab ich schon öfters verwendet. Hier und da mal ein kleiner "Tweak", aber generell laufen die meisten Anwendungen damit "Out of the Box" geskinnt, ohne was am Code verändern zu müssen.

[mquadrat]

Ich würd auch bei der VCL bleiben. Ggf mal einen Blick in die Windows 7 Interface Guidelines werfen und danach ausrichten.

[neo4a]

Zitat:

Zitat von hanspeter (Beitrag 1142267)

Von ExpressQuantumGrid mal abgesehen,bin ich am Überlegen, ob der Kunde besser beraten ist, wenn er FireMonkey verwendet.

Ich bin mir ziemlich sicher, dass bei beiden Ansätzen Du unterm Strich eine Neuprogrammierung realisierst. Dafür sind deren Konzepte einfach zu modern.

Geht es in der Tat nur um die Optik, dann bist Du bereits auf das Skinning hingewiesen worden. AlphaSkin bietet m.E. eine etwas leichtere Unterstützung von VCL- und ThirdParty-Controls. Demgegenüber bietet BusinessSkinForm die für meinen Geschmack etwas bessere Office-2010-Optik.

Obwohl beide Libs "out-of-the-box" funktionieren, muss man trotzdem mit Darstellungsproblemen rechnen, die bei AlphaSkins etwas gravierender sind, weil die auch etwas mehr Bling-Animationen machen und dabei schon mal gern einzelne Bereiche/Frames beim wiederholten Skinning "vergessen".

Alles in allem hängt es auch vom gewünschten Perfektionsgrad und der Erwartungshaltung ab. Selbst Office2010 skinnt ja nur das Hauptformular, während die Dialoge alle in der OS-Optik daher kommen. (Besonders "schick" sind in diesem Zusammenhang die UserForms von Excel. Wer es noch kann, fühlt sich da sofort an Windows 2000 erinnert.)

[exilant]

Zitat:

Zitat von Bummi (Beitrag 1142328)

Die Performance hat mit den letzen Updates deutlich zugelegt, in die Bedienung muss man sich einmal einarbeiten, dann geht es locker.
Ich habe das ganze soweit in meinen Templates implementiert, dass ich mich um Feldveröffentlichungen, im/exporte, Filter, Speicherung von Zuständen im Rahmen der weiteren Entwicklung nicht kümmern muss (natürlich kann wo nötig).
Um all das abzubilden was damit möglich ist ist ansonsten doch ein immenser Aufwand nötig.

Lahm ist es aber immer noch. Ich bin froh, dass ich das Quantum Grid aus meinen Anwendungen eleminiert habe. Es ist wirklich sehr leistungsfähig, aber nicht mit vertretbarem Aufwand beherrschbar. Seit geraumer Zeit setze ich auf die Grids von TMS mit einigen eigenen Erweiterungen. Damit kriege ich alles hin was ich resp. der Benutzer braucht. Und das in einem Bruchteil der Zeit die ich für Devex Quantum einsetzen musste. Fremdkomponenten sollen mir bei minimalem Arbeitsaufwand maximale Entlastung bringen. Bei den Quantumgrids gibt es für maximalen Mehraufwand ein wenig "Eye Candy" für den User und fast nichts für den Entwickler. (IMHO)

[Bummi]

@exilant

Eyecandy ist mir weniger wichtig als Funktionalität und Zuverlässigkeit.
Ich denke TMS kann man nicht wirklich mit den Expresskomponenten vergleichen.

Ich will hier keinen Flamewar lostreten, daher enthalte ich mich weiterer Kommentare zu diesem Thema.

[dataspider]

Zitat:

Zitat von exilant (Beitrag 1142385)

Lahm ist es aber immer noch.

Nur, wenn du es falsch machst.

Sorry...

Frank

[neo4a]

Zitat:

Zitat von dataspider (Beitrag 1142407)

Zitat:

Zitat von exilant (Beitrag 1142385)

Lahm ist es aber immer noch.

Nur, wenn du es falsch machst.

Sorry...

Frank

Es ist sauschnell, wenn nicht mehr Datensätze als in obiger Antwort Worte enthalten sind. SCNR.

[dataspider]

Zitat:

Zitat von neo4a (Beitrag 1142410)

Es ist sauschnell, wenn nicht mehr Datensätze als in obiger Antwort Worte enthalten sind. SCNR.

...oder wenn man GridMode auf True setzt und sich etwas mit der GridModeDemo beschäftigt.

Frank

[neo4a]

Zitat:

Zitat von dataspider (Beitrag 1142416)

Zitat:

Zitat von neo4a (Beitrag 1142410)

Es ist sauschnell, wenn nicht mehr Datensätze als in obiger Antwort Worte enthalten sind. SCNR.

...oder wenn man GridMode auf True setzt und sich etwas mit der GridModeDemo beschäftigt.

Frank

Okay, die Worte lasse ich in die Kalkulation mit einfließen ;)

[Der.Kaktus]

bin auch mit VCLSKIN sehr zufrieden..man muss nix aendern.

[exilant]

Zitat:

Zitat von Bummi (Beitrag 1142405)

@exilant

Eyecandy ist mir weniger wichtig als Funktionalität und Zuverlässigkeit.
Ich denke TMS kann man nicht wirklich mit den Expresskomponenten vergleichen.

Ich will hier keinen Flamewar lostreten, daher enthalte ich mich weiterer Kommentare zu diesem Thema.

Ich will natürlich auch keinen Flamewar. Über dieses Verhalten sind wir hier ja auch normalerweise erhaben :-)
Aber da hier auch Erfahrungen mit dem Quantumgrid thematisiert wurden habe ich meine deutlich mit "IMHO" gekennzeichnete Meinung kundgetan. Ich dachte das dürfte ich als Noch- und Ex-Anwender von Quantum. Jeder hat halt so seine Schwerpunkte bei der Auswahl von Komponenten. Silver Bullets gibt es nicht. TMS ist auch keine.

[hanspeter]

Zitat:

Zitat von neo4a (Beitrag 1142375)

Ich bin mir ziemlich sicher, dass bei beiden Ansätzen Du unterm Strich eine Neuprogrammierung realisierst. Dafür sind deren Konzepte einfach zu modern.

Geht es in der Tat nur um die Optik, dann bist Du bereits auf das Skinning hingewiesen worden. AlphaSkin bietet m.E. eine etwas leichtere Unterstützung von VCL- und ThirdParty-Controls. Demgegenüber bietet BusinessSkinForm die für meinen Geschmack etwas bessere Office-2010-Optik. )

Es gehr auch um die Ablösung der BDE, das Ganze in der Office 2010 Optik.
Wenn der Aufwand in Richtung Neuprogrammierung geht, ist sofort Delphi aus dem Spiel.
Delphi Entwicklung ist in der Firma schon vor einigen Jahren eingestellt worden. Hier geht es um die Aufarbeitung von Altlasten.

Gruß Peter

[Bummi]

Zitat:

Wenn der Aufwand in Richtung Neuprogrammierung geht, ist sofort Delphi aus dem Spiel

Ich kenne eure Software (Umfang/Art der Implementierung) nicht, wenn ich von meinen Altprojekten ausgehe, läuft es bei den genannten Ziel faktisch auf eine Neuprogrammierung hinaus.

[hanspeter]

[QUOTE=Bummi;1142523

Ich kenne eure Software (Umfang/Art der Implementierung) nicht, wenn ich von meinen Altprojekten ausgehe, läuft es bei den genannten Ziel faktisch auf eine Neuprogrammierung hinaus.[/QUOTE]

Sehe ich inzwischen auch so.
Ich hatte Delphi-prism noch ins Spiel gebracht.
Hier stosse ich aber auf noch mehr Ablehnung.
(In der Firma sind eine Reihe C# Programmierer aber keiner mehr der Pascal verwenden kann oder will.)

Peter

[Ralf Kaiser]

Zitat:

Zitat von hanspeter (Beitrag 1142524)

(In der Firma sind eine Reihe C# Programmierer aber keiner mehr der Pascal verwenden kann oder will.)

Wobei gerade dieses Argument (also die benutzte Hochsprache) unter .net/c#/Prism absolut keine Rolle mehr spielt. C# Entwickler können ohne Probleme Prism-Assemblies verwenden und umgekehrt!

[Furtbichler]

Lustig, der Kunde will etwas Moderneres. Kenn ich: "Machense mal schön bunt. Und mehr Grafik. Irgendwie".

So gesehen, ist ein Skin wirklich ausreichend. Allerdings kann ich mir wirklich vorstellen, das der Kunde auch eine verbesserte Funktionalität wünscht.

Ob nun C# oder Delphi ist zunächst einerlei. Da man das Teil vermutlich neu stricken wird, kann man auch Java nehmen. Da gilt es, sinnvoll zu entscheiden. Da hier die C#-Programmierer in der Überzahl sind, sollte man auch C# nehmen.

Nachdem man sich auf die Plattform geeinigt hat, sollte ein ordentliches Framework her. Sowohl Winforms als auch die VCL sind hier etwas altbacken. Ich persönlich setze auch auf DevEx, aber unter .NET gibt es doch reichlich Alternativen, z.B. Infragistics, ComponentFactory, XCeed (design!)

Legt euch dann fest und arbeitet euch ein. Macht am besten in Teams kleine Beispielprojekte und diskutiert intensiv die Erkenntnisse. Dann haben sich alle schnell eingearbeitet.

Allerdings: Wenn die Datenerfassung an sich nur auf Text beruht und eher dialogorientiert ist (im Gegensatz zur Tabelleneingabe als Grid), würde ich mir überlegen, ob nicht ein ergonomisches Redesign mit normalem WinForms/VCL/FM/WPF/Ajax/SWING (you name it - we have it) ausreichend ist.

Letztendlich gilt: Ergonomie schlägt Design.
Allerdings gilt auch: Einem hübschen Design verzeiht man funktionale Fehler eher.

Daraus folgt: Erst ergonomisch gestalten und dann hübsch machen.

[Daniel]

Das ist ja alles schön und gut - aber scheinbar fern der Realität. :roll:

Dieses Thema beginnt mit dem Satz "ich habe eine Anfrage in der ein Kunde die Oberfläche eines älteren Programms etwas modernisieren will."

Es liegt möglicherweise gar nicht im Interesse des Kunden, seine Anwendung von Grund auf neu aufzubauen. Ich denke, dass dass Ratschläge für gänzlich neue Plattformen weit über das Ziel hinausschießen - dies wäre vom zeitlichen und damit auch vom finanziellen Aufwand etwas grundsätzlich anderes, als eine Modernisierung der UI. Alles neu zu machen mit der Maßgabe "jetzt aber richtig" ist ein nettes Vorhaben - aber der Kunde muss es schon wollen.