Modifikation der Forms durch den Enduser

[Guido R.]

Hallo !

Ich möchte den Usern meiner Software ermöglichen, das Design und den Inhalt der Forms (MDIChildren) nach eigenem Gusto anpassen zu können.
Ideal wäre es, wenn nach Klick auf einen Button des übergeordneten MDIForms das aktuelle MDIChild in einen "Bearbeitungsmodus" geht (Grid auf der Form eingeblendet, Controls verschieb- und veränderbar) und ein Objektinspektor, sowie eine Komponentenpalette erscheint, so dass z.B. Reiter einer TabControl hinzugefügt, neue (DB)Edits auf die Form gelegt werden können etc.

Gibt es Komponenten, die da behilflich sein könnten (die Jedis stellen zumindest einen gescheiten Objektinspektor dafür zur Verfügung) ? - Hat schon jmd. Erfahrung bei so einem Projekt gesammelt ?

Gruß
Guido R.

[mkinzler]

http://www.fw-web.de/dfmedit_beta.php

[shmia]

Neue Controls auf einer Benutzeroberfläche brauchen immer auch eine Anbindung an die Logik der Anwendung.
Einfach nur dem Benutzer zu erlauben das Formular nach eigenem Geschmack zu editieren, das wird in aller Regel scheitern.
Es kommt auch immer auf die Zielgruppe der Benutzer an. Wer ist deine Zielguppe?
Normale 0815-Benutzer sind mit dieser Freiheit überfordert.
Ich würde dir also von deinem Plan abraten; lieber etwas weniger Flexibilität aber dafür getestete Qualität anbieten.

[dataspider]

Hi,

ich kenne eigentlich nur Kaufkomponenten.
Denn zum Formulardesigner benötigt man dann meist auch einen Scripter für die Logik.

Bekannt ist mir das ScripterStudio Pro von TMS.
Dann gibt es noch einen Formdesigner von LMD (LMD DesignPack) und ein paar andere (Greatis FormDesigner etc.).
Allerdings fehlen mir für eine Empfehlung die Erfahrungen.
Mit TMS habe ich schon mal experimentiert, aber im Einsatz ist es noch nicht.

Frank

[Guido R.]

Der Einwand von Shmia ist durchaus berechtigt.
Logisch wäre somit, die möglichen Felder anzuzeigen und bei Drag&Drop auf die Form eine entsprechende Contol zu erzeugen, wie es Delphi selbst beim Ziehen von DB-Feldern auf eine Form tut und darüber hinaus allgemeine Controls (Panels, PageControls etc.) zur Verfügung zu stellen.
Ich habe auch mal eine Komponente gesehen, die einem Programm eine Pascal-Script-Funktionalität erlaubt. Damit wäre es dann möglich z.B. Buttons anzulegen, die mit den verfügbaren Daten irgendetwas machen. (Beispiel aus WaWi : mit der EAN nach dem selben Artikel bei einer Preissuchmaschine recherchieren, oder eine Adresse im Browser mit Google Maps anzeigen zu lassen)...

Die Zielgruppe ist nicht das Problem. Dieses Feature soll nicht generell freigeschaltet werden.

Grundsätzlich stellt sich erst mal die Frage, wie speicher ich die Struktur einer Form in einer Datenbank ab und wie rufe diese Struktur auf, wenn die Form erzeugt wird.

[WM_CLOSE]

Schreibe doch direkt das dfm, es is normalerweise als ressource in der exe hinterlegt.

[dpxis]

Hatte das Thema auch mal.

Das Designen zur Laufzeit ist weniger das Thema. Dafür gibts fertige Components bzw. Librarys. Bei mir kam Greatis zum Einsatz.

Wichtiger ist wirklich die Sache mit dem Speichern. Schnell wird nämlich klar, dass das simple Speichern und Laden einer .dfm zwar sehr einfach und zuverlässig machbar ist (siehe DFM-Editor), aber dafür nicht zukunftssicher. Solltest du deine App erweitern (Update), z.B. neue Buttons samt Events im Formular platzieren, wird der EndUser nicht ohne Weiteres da dran kommen...

Ich habe in meinem Projekt beim Designen des Forms durch den Anwender nur die Abweichungen vom Ursprung erfasst und diese beim Erzeugen des Forms wieder hergestellt.

Dafür habe ich ein neues Form, das die Grundlage für meine MDIChilds sein sollte, erzeugt. Dieses hat einen neuen constructor Create() über den du nach "inherited Create()" dein Fenster schön wieder herstellen kannst. Nebenbei kann man hier auch die Position des Childs beeinflussen. Und über dieses Template werden die eigentlichen MDIChilds per Application.CreateForm() erzeugt.

[WM_CLOSE]

Zitat:

Zitat von dpxis (Beitrag 1086711)

Hatte das Thema auch mal.
Wichtiger ist wirklich die Sache mit dem Speichern. Schnell wird nämlich klar, dass das simple Speichern und Laden einer .dfm zwar sehr einfach und zuverlässig machbar ist (siehe DFM-Editor), aber dafür nicht zukunftssicher.

Könntest du das näher erklären?

[dpxis]

Zitat:

Zitat von WM_CLOSE (Beitrag 1086723)

Könntest du das näher erklären?

Gern. Bei mir war es eine Datenbank-Anwendung. Und da ist es ja in der Regel so, dass die Designs eben in der DB "liegen" und fleißig an der Anwendung weiter "gewerkelt" wird.

Falls du z.B. bei deiner Weiterentwicklung nun ein OnShow-Event hinzufügst, existiert dies ja in einer gespeicherten DFM-Datei nicht und das Ereignis wird demzufolge nicht ausgeführt.

[Guido R.]

Also ich hab mir mal die Webseiten der verschiedenen hier genannten Anbieter mal angesehen und mir gefällt bislang das Scripter Studio Pro von TMS am meisten, insbesondere, da wir bereits Komponenten von TMS einsetzen.

Hat schon jemand Erfahrung mit dieser Komponentensammlung ?