Verknüpfungsoperatoren als Variable möglich?

[Alexander 28]

Der Anwender soll ein Feld auf einen bestimmten Inhalt hin überprüfen. Hierbei hat er zwei Möglichkeiten die im Rahmen einer UND-Verknüpfung oder einer ODER-Verknüpfung greifen.

Als Beispiel: In dem Feld steht "Regen" und "Sommer" dann ist die Regel wahr, steht in dem Feld aber nur Regen oder Sommer ist sie falsch. Der Anwender soll nun aber selbst festlegen können, ob eine UND oder eine ODER Verknüpfung verwendet werden soll. Ich möchte ihm ein Optionsfeld zur Verfügung stellen, über welches er dieses einstellen kann. Wenn ich das Ganze dann aber in Skript verarbeite liefert das If-Konstrukt immer einen Fehler zurück.

Beispiel:

Code

Dim session As New NotesSession
Dim workspace As New NotesUIWorkspace
Dim uidoc As NotesUIDocument 
Dim db As NotesDatabase 
Dim doc As NotesDocument 
Dim varoperator As String
Set uidoc = workspace.CurrentDocument
Set db = session.CurrentDatabase
Set doc = uidoc.Document 

varoperator  = doc.Verknuepfungsart(0)

if doc.Subject(0) like "Sommer" varoperator doc.Subject(0) like "Regen" then
....
End if

Ich habe auch schon Variant, Long, Integer etc. probiert, leider ohne Erfolg!
Als Workaround müsste ich über Case Funktion zunächst die Verknüpfungsart abfragen und dann das komplette If-Konstrukt zweimal schreiben.

Hatte gehofft, dass ich es vielleicht etwas schlanker hinbekommen!?

[Pyewacket]

Das geht so nicht, an der Stelle wo du varoperator schreibst wird eben
eine Vergleichsoperation erwartet und keine Variable.

Du musst das wohl oder übel so schreiben:

if varoperator = "AND" then
 if-Abfrage mit AND verknüpft
else 'dann steht OR drin
 if-Abfrage mit OR verknüpft
end if


Voraussetzung ist dass da nur AND oder OR drinstehen kann (vorherige Prüfung)

Der Vergleich mit Like dürfte so auch nicht gehen, Like "Sommer" bedeutet daß exakt nur "Sommer" drinstehen darf,
wenn ich deine Problemstellung verstehe muss irgendwo in dem item das Wort vorkommen.
Das kannst du entweder mit  Like "*Sommer*" abfragen oder  du ermittelst mit INSTR die Position von "Sommer" innerhalb des Textes,
wird 0 zurückgeliefert kommt das Wort nicht vor.

[koehlerbv]

Operatoren sind Sprachelemente und daher nicht in Variablen unterzubringen, sie müssen literal angegeben werden.
A-Bär: Via dem LS-Statement bzw. Function Execute kannst Du zur Laufzeit Code in einer Zeichenkette zusammenbauen, welches dann erst ausgeführt wird.

Allerdings: Wenn es "nur" um die Unterscheidung von zwei Fällen AND or OR   geht, dann spart man sich mit Execute nichts, genaz im Gegenteil (Stichwort: Variablendeklaration für "inside Execute" und natürlich die Bildung des Execute-Strings selbst.

Etwas einfacher kann man es sich evtl. mit einem Evaluate-Statement machen. Vorteil in Deinem fall: Wenn der Juhser den Operator via Keyword-Field eingeben kann ("AND / OR" or "beides" / "eines" or ...), dann kannst Du die Operatoren gleich als Aliase hinterlegen und bei der Evaluate-String-Bildung verwenden.

HTH,
Bernhard

[Pyewacket]

Execute und Evaluate hatte ich absichtlich weggelassen.
Man kann damit tolle Sachen machen aber verständlicher wird es dadurch nicht unbedingt.
Wir hatten mal eine Horror-Applikation am Hals, ca 40% des Codes war dynamisch erzeugt
bzw. in Parameterdokumenten abgelegt. Das war dann zuviel des Guten, ein Alptraum da
durchzusteigen und der ursprüngliche Entwickler war natürlich schon lange weg.

Peter

[koehlerbv]

Vollkommene Zustimmung, Peter. Man kann sehr hilfreiche und auch sehr lesbare Sachen insbesondere mit Evaluate und Konfigurationsdokumenten hierzu machen - wenn man das dosiert und passend einsetzt.
Ansonsten gilt: Alles, was exzessiv betrieben wird (und dann in der Regel methodisch noch nicht mal erklärt werden kann), und alles, was nicht / mies dokumentiert ist, ist nur scheinbar "genial". In meinen 30 Jahren Programmiererdasein, davon 23 Jahre mit Notes, habe ich noch NIE brauchbaren und vor allem zuverlässigen Code gesehen, der nicht ausreichend anerkannten Regeln wie vor allem *einfacher* Nachvollziehbarkeit, Kommentierung und situativ passenden Regeln entsprochen hätte.

Bernhard

[Alexander 28]

Hallo Bernhard, hallo Peter. Herzlichen Dank für eure Gedanken und Vorschläge. Ich werde es nun doch so machen, wie ich es im Posting ja bereits angekündigt habe und ein Case-Konstrukt nutzen. Wenn ich dann die einzelnen Elemente über eine separate Funktion abarbeite, dürfte sich die Anzahl der Codezeilen doch recht übersichtlich gestalten.

Code

Select Case doc.operator(0)
Case "OR"
...
Case "AND"
...
End Select