Domino 9 und frühere Versionen > Entwicklung
Wie kann ich eine Klasse sinnvoll aufbauen ?
TMC:
--- Zitat von: Thomas Völk am 26.06.04 - 17:00:10 ---
--- Zitat von: TMC am 26.06.04 - 16:50:50 ---Nochmal zu diesem Bug (Initial-Values werden nicht neu gesetzt nach dem Speichern):
(....)
--- Ende Zitat ---
du hast die neuen Werte ja schon. du müsstest nur sowas hier in deiner History-Klasse machen, nachdem der Eintrag gemacht wurde:
m_vaInitialFieldValues = m_SavedFieldValues
--- Ende Zitat ---
Jo mei, Du hast natürlich Recht, so geht's:
--- Code: --- Private Sub writeHistory()
'Werte vergleichen und Ergebnisse an den HistoryEntry geben
m_HistoryEntry.Action = m_vDifferences
'History-Eintrag ins Dokument schreiben
Call m_HistoryEntry.write(m_doc)
'Neue Werte in das InitialValue-Array schreiben, für den Fall dass erneut gespeichert wird
m_vaInitialFieldValues = m_SavedFieldValues
End Sub
--- Ende Code ---
animate:
--- Zitat von: TMC am 26.06.04 - 17:09:27 ---In Konstanten (hier: Global Declarations der Maske) sind leider Arrays nicht möglich afaik. Daher schreibe ich die dort in ein String mit Trennzeichen "##", übergebe diese dann an das Objekt "HistoryMonitorDoc", von da aus weiter an das "HistoryMain"-Objekt und im HistoryMain-Objekt wandle ich die dann in ein Array um (mittels der ExtExplode - Function):
--- Code: --- Private Sub getHistoryFields(strNames As String, strTitles As String)
'die zu prüfenden Felder ermitteln
m_vaHistoryFields = ExtExplode(strNames, "##")
m_vaHistoryFieldTitles = ExtExplode(strTitles, "##")
--- Ende Code ---
Bin da aber aufgeschlossen, wenn Du 'ne bessere Idee zur Umsetzung hast :-)
--- Ende Zitat ---
naja, die Frage ist, ob wir hier Konstanten einsetzen müssen.
Ich sehe das so: String-Konstanten setze ich ein, wenn ich die Zeichenfolge, die sie darstellen, an 1-n Stellen verwenden müsste. So vermeide ich Tippfehler und ich kann einen Wert an einer Stelle ändern und das hat Auswirkungen auf alle Stellen, wo dieser Wert verwendet wird.
In diesem Fall käme in meinen Augen die "Befüllung" einer Liste mit den Feldnamen der Deklaration einer Konstanten gleich. (Und ich würde mir damit das hantieren mit irgendwelchen Trennzeichen sparen :) )
Aber das ist Geschmackssache.
TMC:
--- Zitat von: Thomas Völk am 26.06.04 - 17:21:43 ---naja, die Frage ist, ob wir hier Konstanten einsetzen müssen.
Ich sehe das so: String-Konstanten setze ich ein, wenn ich die Zeichenfolge, die sie darstellen, an 1-n Stellen verwenden müsste. So vermeide ich Tippfehler und ich kann einen Wert an einer Stelle ändern und das hat Auswirkungen auf alle Stellen, wo dieser Wert verwendet wird.
In diesem Fall käme in meinen Augen die "Befüllung" einer Liste mit den Feldnamen der Deklaration einer Konstanten gleich. (Und ich würde mir damit das hantieren mit irgendwelchen Trennzeichen sparen :) )
Aber das ist Geschmackssache.
--- Ende Zitat ---
An welchem Ort würdest Du das denn machen? Im Postopen der Maske?
Ich habe ja auch schon hin- und herüberlegt......
Auf die History-Klasse(n) wird man wohl dann von mehreren Seiten zugreifen
A) Wie hier umgesetzt über Postopen der Maske
B) Beispielsweise in einer Workflow-Anwendung, wo man dann z.B. eine Statusänderung reinschreibt wie "Approved document." oder so.
Problem: Wo lege ich z.B. zentral fest, wie viele Einträge die History überhaupt haben darf?
Entweder macht man das imho in der Klasse - oder aber via Setup-Dokument. Welches sich ja auch für die Definition der zu überarbeitenden Feldern anbieten würde.
TMC:
Nochmal zum Errorhandling:
Hab grad sowas versucht:
--- Code: ---Public Class HistoryMain
On Error goto ErrorHandler
--- Ende Code ---
Dann kommt die Meldung:
--- Zitat ---HistoryMain: (Declarations): 10: Statement illegal in CLASS block: ON
--- Ende Zitat ---
Heißt das man müsste das Errorhandling in jede Sub/Function der Klasse einzeln schreiben?
Schade....
animate:
ja, also Setup/Konfigurationsdokument ist immer mein Favorit.
Dann kann da schrauben, ohne an den Code zu müssen.
Wenn ich es im Code machen würde, dann würde ich es in der Maske machen. Wo da genau ist wohl auch Geschmackssache
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln