Neue Komponente

[Cool-Tuc]

Hallo alle,

1) Pascal und OOP ist mir nicht unbekannt, aber ich habe eine Frage zur Erstellung zur Komponenten. Ich würde gerne eine visuelle Komponente erstellen und diese soll dann auch in der KomponentenLeiste erscheinen. Funktioniert das so dass ich grundsätzlich ein Package erzeugen muß in das ich dann bel. viele Komponenten hineinpacken kann, also ist z.B. "Common Controls" ein Package welches dann die entsprechenden Komponenten beinhaltet?

2) Von wem sind die Komponenten, die standardmäßig mitinstalliert werden, also z.B. die "TLabeledEdit". Kann man dort sinnvolle Erweiterung einfließen lassen, so dass diese bei der nächsten Version von Lazarus mit installiert werden?

danke

Udo

[creed steiger]

zu 2)
kann man Verbesserungsvorschläge/Änderungswünsche auf der Mailingliste vorstellen/diskutieren

oder über dein Bugtracker einen Patch posten


Edit:im Chat erwischt man auch mal die entsprechenden Maintainer

[pluto]

zu 01: ja. so ist es richtig. Jedenfalls bin ich diesen Weg Gegangen. Ob nun eine eigene Komponente erstellt oder von einer Ableitest spielt in diesen Fall keine Rolle.

Zu 02: Was für Erweiterungen stellst du dir so vor beim "TLabeledEdit"?

[Cool-Tuc]

...so mal nebenbei...bist du der Entwickler...?
...Liste der (meiner Meinung nach) sinnvollen Erweiterungen folgt..

Udo

[pluto]

ich bin kein Kern Entwickler. Ich beschäftige mich in meiner Freizeit mit Lazarus. Habe schon einige kleinere Komponenten geschrieben seit einigen Jahren versuche ich eine größere Komponente zu schreiben.

[Cool-Tuc]

...also ich habe hier nur einige Erweiterungen....

property (published)
- charSet (Alle Zeichen, die eingegeben werden dürfen; alle anderen werden schon bei der Eingabe Ignoriert)
- CharSetNegate (kehrt den obigen ZeichenPool um, kann schneller sein)
- Converts (konvertiert Zeichen während der Eingabe, z.B. ein Punkt gegen ein komma; macht die Eingabe über Ziffernblock einfacher)
- Requirede (Boolean; durch unterschiedliche backgroundcolor wird dem Anwender gezeigt, ob dieses Feld ein Pflichtfeld (Eingabe) ist)
- SQL (Wert der Eingabe, aber für die Übergabe an SQL vorbereitet, also z.B. ein Text mit umschließenden Anführungszeichen, oder ein Double mit Punkt anstelle eine Kommas)
- Value (Wert der Eingabe)
- ValueTyp (Legt den Eingabetyp fest: Text/Integer/Float/Currency/Date/Time)

Methoden
- Valid (Boolean; prüft ob eine Eingabe korrekt ist entsprechende dem ausgewählten ValueType und Required; bei Required=TRUE darf das Feld nicht leer sein)

...außerdem habe ich das Problem, dass beim verschieben der Komponente irgendwann die Beschriftung verschwindet und nicht wieder sichtbar zu machen ist.....warum auch immer...

Udo

[m.fuchs]

Statt dieser doch recht speziellen Erweiterungen, die kaum jemand braucht, fände ich eine Art Decorator- oder Filtersystem besser. So dass die Standardkomponenten um beliebige (auch selbsterstellbare) Objekte erweitert werden, die genau diese Funktion anbieten.

Theoretisch könntest du dir das schon jetzt bauen, in dem sich Objekte an die OnChange-Property hängen.

[m.fuchs]

...also ich habe hier nur einige Erweiterungen....

Manche davon kann man eleganter anders lösen:

- Converts (konvertiert Zeichen während der Eingabe, z.B. ein Punkt gegen ein komma; macht die Eingabe über Ziffernblock einfacher)

http://www.freepascal.org/docs-html/rtl ... rator.html

- Value (Wert der Eingabe)
- ValueTyp (Legt den Eingabetyp fest: Text/Integer/Float/Currency/Date/Time)

Dafür einfach bestehen Eingabekomponenten für Datentypen verwenden: TSpinEdit, TFloatSpinEdit, TColorButton, TDateEdit, ...

- Valid (Boolean; prüft ob eine Eingabe korrekt ist entsprechende dem ausgewählten ValueType und Required; bei Required=TRUE darf das Feld nicht leer sein)

Dafür würde ich mir mal die RTTI-Komponenten ansehen und diese an eine Datenklasse binden. Und das bekommt dann eine Validierungsmethode. Oder DataControls verwenden, die bieten sicherlich auch eine solche Prüfung.

[pluto]

Dafür würde ich mir mal die RTTI-Komponenten ansehen und diese an eine Datenklasse binden. Und das bekommt dann eine Validierungsmethode. Oder DataControls verwenden, die bieten sicherlich auch eine solche Prüfung.

Theoretisch muss dafür nicht mal RTTI Verwendet werden. Im Prinzip könntest du für die Eingabe Komponenten eine allgemeine Methode schreiben. Z.B. Prüfen ob im TEdit richtig eingeben wurde, oder im TComboBox oder auch im TMemo.

Mit der RTTI könnte man es durchaus schöner lösen. Da könntest du Prüfen, ob es bestimmte Eigenschaften gibt wie z.b. Lines von TMemo oder Text von TEdit oder aber auch von TCombobox. Aber der Aufwand ist deutlich höher.

[m.fuchs]

Nein, ich meinte die RTTI-Controls. Da kann man EIngabefelder an bestimmte Properties einer Klasse (also der entsprechenden Datenklasse) binden. Auf dieser Basis wäre dann auch ein Validierung möglich.

[pluto]

Das wäre natürlich die einfachste Möglichkeit... zugegeben, ich habe bis her den OI verwenden von den RTTI Komponenten, aber die Möglichkeiten scheinen doch sehr Interessant zu sein. Die Komponenten müssen aber erst Installiert werden.

[Cool-Tuc]

...keiner versteht mich (glaube ich)
Ich denke z.B. an "Required", und zwar aus Sicht des Anwenders; dieser soll in seiner Maske sofort an der Hintergrundfarbe des entsprechenden Controlls erkennen, ob es ein Pflichtfeld ist. Dieses würde ich auf jeden Fall im Controll unterbringen und nicht jedesmal die entsprechende Farbe einstellen wollen. Es soll nicht erst beim Speichern die Meldung bekommen, dass etwas fehlt...

Oder "charSet"; warum soll ich nicht direkt im Controll eingeben, dass der Anwender nur z.B. "a..j" und "4..8" eingeben darf. Das kann ich direkt im Controll abfangen und brauche es nicht bei jedem Controll auf der Maske im "OnChange" programmieren...

Wie/Was die Anbindung an andere Objekte/Klassen nachher angeht, das ist eine ganz andere Sache (glaube ich)...

Aber trotzdem Danke für die interessanten Denkanstöße...es gibt halt viele Wege nach Rom...

Ich kann es ja mal mit Kleinigkeiten versuchen....ob es Sinn macht oder nicht...und erzähl es euch dann nachher...

Udo

[pluto]

Deine Idee ist z.b. jetzt alle Eingabe Komponenten die du verwendest, sollen eine Eigenschaft "Required" haben. Die wenn sie auf True ist, angibt, dass es ein Muss-Feld ist.
Und ist die Eingabe nicht ausgefüllt oder Falsch ausgefüllt soll es der Nutzer erkennen können, wie im Internet üblich...

Im Prinzip ist das ganz leicht hinzubekommen. Du erstellst eine neue Komponente und leitest sie von der TEdit Komponente ab. Nur so als Beispiel.
Dann überschreibst du die Change Methode und färbst die Hintergrund Farbe entsprechend.

Ich hoffe du kannst mir Folgen.

[m.fuchs]

...keiner versteht mich (glaube ich)

Aber sicher verstehe ich dich, nur das was du benötigst sind absolute Spezialfälle. Also exklusiv für dich. Ich denke da eher weiter und versuche allgemeine Lösungen zu schaffen.

Ich denke z.B. an "Required", und zwar aus Sicht des Anwenders; dieser soll in seiner Maske sofort an der Hintergrundfarbe des entsprechenden Controlls erkennen, ob es ein Pflichtfeld ist. Dieses würde ich auf jeden Fall im Controll unterbringen und nicht jedesmal die entsprechende Farbe einstellen wollen. Es soll nicht erst beim Speichern die Meldung bekommen, dass etwas fehlt...

Ok, dann bräuchte man die Property Required und eine namens RequiredBackgroundColor, damit die Entwickler auch entscheiden können, welche die entsprechende Farbe für notwendige Daten ist. Damit hast du also nix gewonnen. Oder man definiert die Farbe irgendwo zentral. Wo und wie? Pro Form? Pro Applikation? ...

So oder so hat es den Nachteil, dass es die bestehende Controls weiter aufbläht. Hier sollte man lieber ableiten.

Oder "charSet"; warum soll ich nicht direkt im Controll eingeben, dass der Anwender nur z.B. "a..j" und "4..8" eingeben darf. Das kann ich direkt im Controll abfangen und brauche es nicht bei jedem Controll auf der Maske im "OnChange" programmieren...

Auch das ist ein Feature, welches nur in (wenigen) bestimmten Fällen gebraucht wird. Hier wäre eine Ableitung von TEdit schon der bessere Weg. Oder eben gleich eine Möglichkeit Eingabecontrols um Filter und Verifikatoren zu erweitern.

Ich stelle mir das so vor: Du hast ein TEdit und packst in seiner Erweiterungsliste folgendes (rein fiktiv): TMailAdressDecorator (prüft ob der eingegebene Wert eine Mailadresse ist) und TRequiredDecorator (zeigt an dem Eingabefeld eine Info an, dass es ein Pflichtfeld ist und prüft beim Speichern/Absenden/wasauchimmer ob es wirklich belegt ist. Ebenso gibt es dann auch Dekoratoren für Telefonnummern, URL, Postleitzahlen, etc. Und natürlich kann man eigene schreiben, die immer wiederverwendet werden.

Und idealerweise gruppiert man einen Haufen dieser Eingabecontrols und lässt aus ihren Inhalten automatisch ein Objekt generieren. Das sollten dann vielleicht gleich alles in abgeleiteten Klassen passieren, am Ende hat man dann ein kleines Framework um schnell das MVC-Pattern umzusetzen. Dürfte dann jede Menge Programmieraufwand ersparen, da man alle Prüfroutinen nur noch "zusammenstöpseln" und nicht mehr programmieren muss.

BTW: Falls sich noch Leute finden so etwas für Lazarus zu implementieren: ich wäre dabei.

[Cool-Tuc]

...ich glaube wir meinen das Gleiche, gehen nur anders an die Sache heran...

ich fange mal einfach an... ach ja, die Property "Required" steht...

Udo