Auswahl über Adress-Dialog erzwingen

[Axel]

Ich will auch mal ein Problem haben. Es gibt hier eine bestehende Anwendung und ich brüte schon fast den ganzen Tag an einer Lösung um die Eingabe von Usernamen wasserdichter zu bekommen. Aber ich habe bisher keine richtige Lösung gefunden.

Innerhalb der Anwendung gibt es in einer Maske mehrere Felder, in dem interne Usernamen aus dem Domino Directory ausgewählt werden sollen. Diesen werden dann entsprechende Benachrichtigungsmails geschickt. Außerdem erfolgen später noch weitere Auswertungsschritte, die sich auf diese Feldern beziehen. Die Felder sind im Moment alle vom Typ Namen und als Auswahl ist der Adressdialog ausgewählt.

Das Ganze funktioniert auch soweit, aber... Es gibt bei uns einige User, die tragen dort händisch Adressen ein, anstatt die Auswahl zu nutzen und da passieren dann eben auch Fehler.

Wie kann ich es nun unterbinden, dass in die Namensfelder direkt was eingetragen werden kann?

Axel

[jBubbleBoy]

Mit eine View - Picklist auf's NAB?

Das ist Idiotensicher

[Axel]

Ja, aber...

Das habe ich schon probiert. Die Sache hat aber einen Hacken. Bestehende Einträge werden nicht in den Adress-Dialog übernommen. Wenn ich bspw. einen User ergänzen will, muss ich alle bereits vorhandenen nochmal auswählen.

Axel

[WernerMo]

Hallo Axel,

den Button mit einem "Dialog" versehen, der folgende Auswahl enthält:
- Eintrag entfernen
- Eintrag hinzufügen
Und dann entsprechend verarbeiten.

Gruß Werner

[BigWim]

Hallo Axel,

und die Eingaben prüfen per DBLookup in einem berechneten Feld ist keine Alternative?

Markus

[Axel]

den Button mit einem "Dialog" versehen, der folgende Auswahl enthält:
- Eintrag entfernen
- Eintrag hinzufügen
Und dann entsprechend verarbeiten.

Das hatte ich mir auch schon überlegt. Ein paar Dialogvarianten habe ich zwar schon getestet aber auch wieder verworfen. Die Variant werde ich auch mal weiterverfolgen.

und die Eingaben prüfen per DBLookup in einem berechneten Feld ist keine Alternative?

Die Idee hört sich auch nicht schlecht an. Ich schau mal was man daraus machen kann.

Axel

[koehlerbv]

Solch ein Konstrukt kommt ggf. auch in Frage:

Code

_original := @Trim (DeinNamensfeld);
_realnames := @NameLookup ([NoUpdate]; _original; "Owner");
@Trim (@Unique (_realnames))

HTH,
Bernhard

PS: Die Sache hatr aber keinen "Hacken", sondern schlimmstenfalls einen "Haken", Axel 

[Axel]

PS: Die Sache hatr aber keinen "Hacken", sondern schlimmstenfalls einen "Haken", Axel 

 

Dein Konstrukt werde ich morgen mal testen.

Axel

[ascabg]

Hallo,

Ich habe mir mal mit 2 kleinen Icons in einem derartigem Fall geholfen.

1. Icon (ein kleines "+"-Zeichen) -> hinzufuegen von Namen

Code

_names := @PickList([Name]);
FIELD <Feldname> := @Unique(@Trim(<Feldname> : @Name([Abbreviate]; _names)));
@True

2. Icon (ein kleines "-"-Zeichen) -> loeschen von Namen aus dem Feld

Code

_names := @Prompt([OkCancelListMult]; "Choose name"; "Please select one or more names to delete from the field <Additional F&A read access for Web reports>."; ""; @Name([Abbreviate]; <Feldname>));
FIELD <Feldname> := @Trim(@Replace(<FeldName>; @Name([Canonicalize]; _names); ""));
@True

Andreas

[Axel]

Hallo Andreas,

die Lösung hat was. Ich werde mich mal mit den ganzen Vorschlägen befassen. Mal sehen was dabei heraus kommt und welche sich am einfachsten in die bestehende Anwendung integrieren lässt.

Axel

[Axel]

An einigen Versuchen habe ich mich für Bernhard's Lösung entschieden. Die Formel habe ich für Felder mit Mehrfachwerten etwas angepasst und in die Eingabevalidierung gesteckt. Scheint soweit mal problemlos zu funktionieren.

Ich werde das mal auf unsere User loslassen, denn die sind in Falscheingaben wesentlich kreativer als ich.   

Danke an alle für die vielen hilfreichen Tipps.

Axel

[koehlerbv]

Hallo Axel,

ich fühle mich nun gebauchpinselt 

Mich interessiert nun aber die "Gegenrichtung": Was hast Du denn für Mehrfachwerte noch angepasst?

Bernhard

[Axel]

So sieht die Formel jetzt aus.

Code

_original := @Trim (@ThisValue);
@For(n:=1; n<=@Elements(_original); n:=n+1;
   @Do( _temp := @NameLookup ([NoUpdate]; _original[n]; "Owner");
                _realnames:= _realnames : _temp));
@Trim (@Unique (_realnames))

Für Verbesserungsvorschläge habe ich immer ein offenes Ohr.

Axel

[Axel]

Ich habe das Ganze gerade noch etwas vereinfacht.

Nun sieht die Formel so aus:

Code

_original := @Trim (@ThisValue);
@Trim (@Unique (@Transform(_original; "_var"; @NameLookup ([NoUpdate]; _var; "Owner"))));

Axel

[koehlerbv]

Die Schleife brauche ich bei mir nicht - @NameLookup wirkt ja auch auf Listen (wie fast alle @functions). Dadurch wird bei mir jeder "frei vergebene Name", der sich nicht im DD wiederfindet, in den Orkus gedrückt. "wanda fisch" wird dagegen - so vorhanden - korrekt in "Wanda Fisch" umgewandelt.

Auch das @Transform habe ich bisher nicht benötigt.

Bernhard

[Axel]

Wo du recht hast , hast du recht.   

Da muss ich vorhin irgendwo einen Fehler drin gehabt haben. Bei Mehrfachwerten habe ich immer nur den letzten Wert zurückbekommen.

Jetzt funktionierts auch ohne For und Transform.

Code

@Trim (@Unique (@NameLookup ([NoUpdate]; @ThisValue; "Owner")));

Axel

[Axel]

Eine kleine Erweiterung musste ich noch einbauen und zwar die Abfrage ob das Feld leer ist.

Das Ganze sieht nun so aus:

Code

@If(@ThisValue != ""; @Trim (@Unique (@NameLookup ([NoUpdate]; @ThisValue; "Owner"))); "")

und macht nun was es soll.

Das Problem war, dass bei leerem Feld logischerweise auch @ThisValue eine leere Zeichenkette zurückliefert und dann ergibt @NameLookup mit diesen Parametern den aktuell angemeldeten Usernamen.

Axel

[koehlerbv]

Sorry, Axel - das hätte ich wirklich bereits im ersten Posting angeben müssen.

Hoffen wir, das der Thread nun in seiner Komplettheit möglichst vielen AtNoteslern nützt.

Bernhard

[Axel]

Sorry, Axel - das hätte ich wirklich bereits im ersten Posting angeben müssen.

Kein Problem. Ich wollte ja nur einen Denkanstoß und keine fertige Lösung.

Axel