Groffy hat geschrieben:
ich muss gestehen, dass ich Dein Konzept nicht so wirklich verstanden habe. Du benutzt den Formulardesigner zur Entwurfszeit, oder erzeugst Du das komplette Formular mit allen benötigten Controls zur Laufzeit? Du nutzt nicht die Datenbindung der Controls sondern befüllst / aktualisierst alle Controls mittels Code, bzw. liest den Inhalt zum Rückschreiben in die Datenbank? Das stelle ich mir bei Grids aber recht aufwendig vor.
Das komplette Formular wird bei mir mittlerweile zur Laufzeit erzeugt. Das macht im Prinzip eine selbstgeschriebene Klasse, die auf einem Panel oder einer Scrollbox einfach nach gewissen Regeln Komponenten positioniert und diese auch gleich mit Daten füllt. Die Regeln basieren dabei auf Tabellenfelder und Typen in der DB, beispielweie wird für ein Datumsfeld automatisch ein TDateEdit Control erzeugt, bei einem Blob Sub_type text ein TMemo usw. Die Positionierung läuft als Standard vertikal von oben nach unten. Mit einem in der Software integrierten Designmodus kann der Anwender die Feldpositionen und Größen anpassen. Diese Infos werden dann als Tags in der DB gespeichert und beim nächsten erzeugen wieder nachgeladen.
Im OnChange Event jedes Controls wird nun automatisch der Datensatz als verändert vermerkt und vor dem Klick auf einen anderen Datensatz per auomatisch erzeugtem "Update or Insert" Befehl von der selbstgeschriebenen Klasse an die DB geschickt. Für die Navigation habe ich immer eine ownerdraw Listbox im Einsatz, die mehrspaltig ist. Der Anwender kann dabei im Designmode selbst entschieden, welche Spalten er sehen kann, aber die Bearbeiten geschieht generell nie im Grid. Oberhalb der Listbox ist ein Suchfeld, mit dem man ähnlich wie in Google alles suchen kann. Bei Masterdetail Beziehungen erscheint dann auch noch ein Treeview, in dem dann ggf auch die Detaildaten erscheinen (angebotspositionen usw.)
Evtl. bekommst du einen ersten Eindruck auf
www.brp-software.com, da gibt es auch eine voll funktionsfähige Einzelplatzversion bzw. Tutorialvideos. Da wir im Moment sehr dicht sind mit Projekten auf BRP Basis ist auf der Webseite nicht alles 100% aktuell, aber sicherlich schon mal sinnvoll für den ersten Eindruck.
Mir ist im Laufe der Jahre in vielen Projekten deutlich geworden, das normal denkende Anwender immer mehr Probleme bekommen, wenn man endlos Eingabeelemente auf einem Bildschirm packt. Pagecontrols verschlimmern das Problem aus meiner Sicht sogar noch.
Datenbearbeitung im Grid mag da hat seine Vorteile haben, hat aber de fakto auch gravierende Nachteile. Wenn man sich Excel mal genau anschaut wird da übrigens auch gar nicht wirklich im Grid editiert, sondern in der Befehlszeile, es wird halt nur der Inhalt von da gleich in die Zelle hineinkopiert, so das es aussieht, als ob man da arbeiten würde, ist aber in Wirklichkeit gar nicht so. Wenn ich irgendwann mal darin einen Vorteil sehe werde ich das evtl auch so ähnlich umsetzen, ist aber im Moment bei keinem Kunden ein Wunsch.
Ich für meinen Teil glaube, das man sich heutzutage bei vielen Projekten eher an die Google Idee (wenige Controls, einfaches Layout) halten sollte, um die Einarbeitungszeit zu minimieren. So viele Vorteile auch immer ein DBGrd von Devexpress oder TMS auch hat, auch da gilt die 90/10 Regel: 90 Prozent aller Anwender bzw Programmierer nutzen nicht mal 10% der Funktionalitäten.
Aus der Sicht des Programmierers ist es natürlich ein gewisser Mehraufwand, den man da treibt, aber das holt man am Ende sehr schnell wieder rein und erst recht dann, wenn man den eigenen Quellcode für mehrere unterschiedliche Kundenprojekte benutzen möchte, die nämlich bei mir nur durch Unterschiede in der DB abgebildet werden.
Verein
Links
Suche