Im CPAN habe ich das Modul Tk::FilterEntry gefunden, welches teilweise gleiche Funktionalitaet besitzt. Vielleicht wirfst du einen Blick in dieses Modul? Wenn du meinst, dass dein Modul trotzdem eine Daseinsberechtigung hat, dann solltest du vielleicht einen Abschnitt im Pod fuer aehnliche Module widmen.

Ich habe gerade mal geguckt, welche Entry-aehnlichen Module fuer Tk es gibt und bin auf diese Liste gekommen:

The root:
Tk::Entry
Tk::LabEntry

Comboboxes:
Tk::BrowseEntry
Tk::ComboEntry
Tk::PopEntry (?)
Tk::LabPopEntry (?)
Tk::JBrowseEntry
Tk::MenuEntry

Date related:
Tk::DateEntry
Tk::Date

File related:
Tk::FileEntry
Tk::PathEntry
Tk::PathEntry::Dialog

Spinboxes:
Tk::Spinbox
Tk::NumEntry
Tk::NumEntryPlain

History/autocompletion:
Tk::HistEntry
Tk::MatchEntry

Special/custom filtering:
Tk::FilterEntry
Tk::HexEntry
Tk::HexEntryPlain
Tk::IPEntry

Obscure:
Tk::FcyEntry
Tk::FloatEntry

Wahrscheinlich solltest du im Pod auf alle filternden Module verweisen.

Uebrigens: qr{} gibt es auch in perl 5.005. Wenn du dann auf "use warnings" verzichtest (und das kann man guten Gewissens), dann ist das Modul out-of-the-box fuer 5.005 einsetzbar.

so, habe jetzt die doku angepasst, und bin auch auf die vor-/nachteile gegenueber Tk::FilterEntry eingegangen: http://download.fabiani.net/cpan/Tk-EntryCheck-0.01.tar.gz\n\n

<!--EDIT|Strat|1083923217-->

das klingt interessant; ich schau's mir bei gelegenheit mal an

Hast Du es inzwischen eigentlich auf CPAN gestellt?

Hi Leute,

da ich gerade an einer groesseren Tk-Anwendung rumschreibe, hat es mich genervt, dass die Ueberpruefung der Eingaben in ein Entry-Feld so umstaendlich ist. Dafuer habe ich gerade ein neues Modul namens Tk::EntryCheck geschrieben, das ein Wrapper um Tk::Entry ist und den Zugriff auf -validate und -validatecmd erleichtert, indem es die folgenden neuen Optionen bereitstellt:

Verwendung:


Installation:
1. Download von http://download.fabiani.net/cpan/Tk-EntryCheck-0.01.tar.gz
2. Entpacken:
 Linux: tar xvzf EntryCheck-0.01.tar.gz
 Windows: z.B. mit Winzip
3. In das Verzeichnis wechseln
4. perl Makefile.PL PREFIX=/path/to/testmodules
5. make (oder unter Windows: nmake)
6. make test (oder unter Windows: nmake test)
7. make install (oder unter windows: nmake install)

das PREFIX in 4. hat den Vorteil, dass man da ein eigenes Modulverzeichnis angeben kann und so die Perl-Lib-Verzeichnisse sauber bleiben.

Doku: ist eingebettet und kann z.B. mit

nach html konvertiert werden...

Da ich es gerne nach CPAN hochladen will, bitte ich um Tests und Meinungen.

[quote=ptk,06.05.2004, 19:04]Im CPAN habe ich das Modul Tk::FilterEntry gefunden, welches teilweise gleiche Funktionalitaet besitzt.
[/quote]
Ja, es hat Aehnlichkeiten, ist aber bezueglich der Validierung genauso kompliziert wie Tk::Entry, weil es auf -validatecmd basiert. Da ist meins um einiges einfacher zu handeln, weil es ein sehr einfaches Interface bereitstellt, und deshalb sehe ich dafuer schon eine Daseinsberechtigung, vor allem fuer die Leute, die da nicht so geuebt sind (und wenn jemand die volle Breitseite haben will, kann er ja trotzdem die Parameter -validate und -validatecmd mitgeben), und vielleicht hilft es ja dem einen oder anderen Programm, dass fehlerhafter input gleich von anfang an zurueckgewiesen werden kann... denn auf grund von mangelhafter validierung koennen leicht sicherheitsluecken auftreten, oder durch zu spaete validierung das programm zu komplex werden...

[quote=ptk,06.05.2004, 19:04]
...
Wahrscheinlich solltest du im Pod auf alle filternden Module verweisen.
[/quote]
Gute Idee
[quote=ptk,06.05.2004, 19:04]
Uebrigens: qr{} gibt es auch in perl 5.005. Wenn du dann auf "use warnings" verzichtest (und das kann man guten Gewissens), dann ist das Modul out-of-the-box fuer 5.005 einsetzbar.[/quote]
danke, bezueglich qr war ich mir nicht mehr sicher, und war zu faul, ein 5.005er zu installieren und es zu testen ;-)\n\n

<!--EDIT|Strat|1083868736-->

Im Pod solltest du =over =item =back statt "x)" verwenden.

Eine schnelle Demo-Moeglichkeit waere nett. Am besten ist es, wenn man das Makefile um ein "make demo" erweitert. Weiterhin koennte man die Demonstration auch "widget"-tauglich machen und in das demos-Verzeichnis installieren lassen. Das Makefile.PL zu Tk::Date koennte dir ein paar Anregungen geben.

Mein erster Versuch einer Pattern-Spezifikation sah so aus:
-pattern => qr/^\d{1,3}(\.(\d{1,3}(\.(\d{1,3}(\.(\d{1,3})?)?)?)?)?)?$/
Zuerst habe ich mich gewundert, warum das nicht geht, und dann die Manpage gelesen :-)

Noch eine weitere Idee, aber ich habe keine Ahnung, wie man das implementieren koennte: es gibt ein OO-Pattern namens "mixin". Damit koennen "Features" in eine Klasse eingebunden werden, ohne dass man inhertiance verwenden muss. So etwas wuerde sich auch hier anbieten, wenn man z.B. gleichzeitig ein Entry braucht, das eine History-Funktion wie in HistEntry und eine Check-Funktion wie in EntryCheck hat. Zurzeit muss man dafuer Code duplizieren, aber schoener waere es, wenn man einfach sagen koennte:

package Tk::HistEntryCheck;
use base "Tk::Entry";
use mixin "Tk::HistEntry::mixin";
use mixin "Tk::EntryCheck::mixin";
...

Keine Ahnung, wie man so etwas fuer Tk-Widgets implementieren kann. Fuer "normale" OO-Module funktioniert das CPAN-Modul mixin jedenfalls sehr gut.

Modul geht ab! Wirklich bequem und vorallem easy. Danke Strat :)

ja, siehe http://search.cpan.org/~strat/

ah :)

Da steht "License unknown" ?!

Und es fehlt wohl ein 'is' im Satz

x) EntryCheck just checks each char if it in a characterclass, whereas FilterEntry checks the whole content with a regular expression, so it is more helpful when checking for special formats

und ich glaube "character class" schreibt man getrennt

zu 'x)' siehe ptk:
[quote=ptk,07.05.2004, 13:29]Im Pod solltest du =over =item =back statt "x)" verwenden.[/quote]\n\n

<!--EDIT|Crian|1093356882-->