Mit DDE (Domino Designer for Eclipse) kann man LotusScript Code (z.B. in Bibliotheken) auch fehlerhaft abspeichern und später korrigieren. Dieses kann einen Entwickler durchaus im Arbeitsfluss unterstützen, wenn klar ist, dass noch Codeänderungen anderer Stelle in diesem Zusammengang erforderlich sind.
Nun hatte ich erwartet, dass eine anschließende vollständige (erfolgreiche) Kompilation der Anwendung entweder mich auf verbliebene Fehler hinweist oder die Anwendung anschließend sauber bereinigt ist. Leider (wie so oft in diesen Tagen) wurde ich enttäuscht: Die erfolgreiche Kompilation der Anwendung belässt diese trotzdem in einem unsauberen Zustand! Der Code entspricht nicht dem gewünschten Stand. Funktionstests ergeben ein falsches Ergebnis.
Hintergrundinformation:
Beim Abspeichern "mit Fehlern" legt der DDE den fehlerhaften Script-Code in ein weiteres Feld "$LotusScript_error" des Gestaltungselementes ab. Bei einer erfolgreichen Kompilation wird stets der zuletzt erfolgreich gespeicherte SourceCode aus dem Feld "$LotusScript" in das Feld "$LotusScript_O" übertragen.
Es wäre schön:
... wenn mir der Designer durch ein entsprechendes Symbol kenntlich machen würde, in welcher Bibliothek noch fehlerhafter LotusScriptCode enthalten ist
... wenn der Designer die Felder mit dem fehlerhaften LotusScript Code prüft und während der Kompilation in den aktuellen LotusScript Code überführt und des Feld mit dem fehlerhaften Code löscht
... wenn der Designer während der Kompilation einen Hinweis gibt, welche Bibliotheken nicht korrekt kompiliert werden können, weil noch fehlerhaft gespeicherter Code enthalten ist
Posts Tagged: ‘LotusScript’
Domino Designer kompiliert nicht vollständig
Mit DDE (Domino Designer for Eclipse) kann man LotusScript Code (z.B. in Bibliotheken) auch fehlerhaft abspeichern und später korrigieren. Dieses kann einen Entwickler durchaus im Arbeitsfluss unterstützen, wenn klar ist, dass noch Codeänderungen anderer Stelle in diesem Zusammengang erforderlich sind.
Nun hatte ich erwartet, dass eine anschließende vollständige (erfolgreiche) Kompilation der Anwendung entweder mich auf verbliebene Fehler hinweist oder die Anwendung anschließend sauber bereinigt ist. Leider (wie so oft in diesen Tagen) wurde ich enttäuscht: Die erfolgreiche Kompilation der Anwendung belässt diese trotzdem in einem unsauberen Zustand! Der Code entspricht nicht dem gewünschten Stand. Funktionstests ergeben ein falsches Ergebnis.
Hintergrundinformation:
Beim Abspeichern "mit Fehlern" legt der DDE den fehlerhaften Script-Code in ein weiteres Feld "$LotusScript_error" des Gestaltungselementes ab. Bei einer erfolgreichen Kompilation wird stets der zuletzt erfolgreich gespeicherte SourceCode aus dem Feld "$LotusScript" in das Feld "$LotusScript_O" übertragen.
Es wäre schön:
... wenn mir der Designer durch ein entsprechendes Symbol kenntlich machen würde, in welcher Bibliothek noch fehlerhafter LotusScriptCode enthalten ist
... wenn der Designer die Felder mit dem fehlerhaften LotusScript Code prüft und während der Kompilation in den aktuellen LotusScript Code überführt und des Feld mit dem fehlerhaften Code löscht
... wenn der Designer während der Kompilation einen Hinweis gibt, welche Bibliotheken nicht korrekt kompiliert werden können, weil noch fehlerhaft gespeicherter Code enthalten ist
Nun hatte ich erwartet, dass eine anschließende vollständige (erfolgreiche) Kompilation der Anwendung entweder mich auf verbliebene Fehler hinweist oder die Anwendung anschließend sauber bereinigt ist. Leider (wie so oft in diesen Tagen) wurde ich enttäuscht: Die erfolgreiche Kompilation der Anwendung belässt diese trotzdem in einem unsauberen Zustand! Der Code entspricht nicht dem gewünschten Stand. Funktionstests ergeben ein falsches Ergebnis.
Hintergrundinformation:
Beim Abspeichern "mit Fehlern" legt der DDE den fehlerhaften Script-Code in ein weiteres Feld "$LotusScript_error" des Gestaltungselementes ab. Bei einer erfolgreichen Kompilation wird stets der zuletzt erfolgreich gespeicherte SourceCode aus dem Feld "$LotusScript" in das Feld "$LotusScript_O" übertragen.
Es wäre schön:
... wenn mir der Designer durch ein entsprechendes Symbol kenntlich machen würde, in welcher Bibliothek noch fehlerhafter LotusScriptCode enthalten ist
... wenn der Designer die Felder mit dem fehlerhaften LotusScript Code prüft und während der Kompilation in den aktuellen LotusScript Code überführt und des Feld mit dem fehlerhaften Code löscht
... wenn der Designer während der Kompilation einen Hinweis gibt, welche Bibliotheken nicht korrekt kompiliert werden können, weil noch fehlerhaft gespeicherter Code enthalten ist
Domino Designer kompiliert nicht vollständig
Mit DDE (Domino Designer for Eclipse) kann man LotusScript Code (z.B. in Bibliotheken) auch fehlerhaft abspeichern und später korrigieren. Dieses kann einen Entwickler durchaus im Arbeitsfluss unterstützen, wenn klar ist, dass noch Codeänderungen anderer Stelle in diesem Zusammengang erforderlich sind.
Nun hatte ich erwartet, dass eine anschließende vollständige (erfolgreiche) Kompilation der Anwendung entweder mich auf verbliebene Fehler hinweist oder die Anwendung anschließend sauber bereinigt ist. Leider (wie so oft in diesen Tagen) wurde ich enttäuscht: Die erfolgreiche Kompilation der Anwendung belässt diese trotzdem in einem unsauberen Zustand! Der Code entspricht nicht dem gewünschten Stand. Funktionstests ergeben ein falsches Ergebnis.
Hintergrundinformation:
Beim Abspeichern "mit Fehlern" legt der DDE den fehlerhaften Script-Code in ein weiteres Feld "$LotusScript_error" des Gestaltungselementes ab. Bei einer erfolgreichen Kompilation wird stets der zuletzt erfolgreich gespeicherte SourceCode aus dem Feld "$LotusScript" in das Feld "$LotusScript_O" übertragen.
Es wäre schön:
... wenn mir der Designer durch ein entsprechendes Symbol kenntlich machen würde, in welcher Bibliothek noch fehlerhafter LotusScriptCode enthalten ist
... wenn der Designer die Felder mit dem fehlerhaften LotusScript Code prüft und während der Kompilation in den aktuellen LotusScript Code überführt und des Feld mit dem fehlerhaften Code löscht
... wenn der Designer während der Kompilation einen Hinweis gibt, welche Bibliotheken nicht korrekt kompiliert werden können, weil noch fehlerhaft gespeicherter Code enthalten ist
Nun hatte ich erwartet, dass eine anschließende vollständige (erfolgreiche) Kompilation der Anwendung entweder mich auf verbliebene Fehler hinweist oder die Anwendung anschließend sauber bereinigt ist. Leider (wie so oft in diesen Tagen) wurde ich enttäuscht: Die erfolgreiche Kompilation der Anwendung belässt diese trotzdem in einem unsauberen Zustand! Der Code entspricht nicht dem gewünschten Stand. Funktionstests ergeben ein falsches Ergebnis.
Hintergrundinformation:
Beim Abspeichern "mit Fehlern" legt der DDE den fehlerhaften Script-Code in ein weiteres Feld "$LotusScript_error" des Gestaltungselementes ab. Bei einer erfolgreichen Kompilation wird stets der zuletzt erfolgreich gespeicherte SourceCode aus dem Feld "$LotusScript" in das Feld "$LotusScript_O" übertragen.
Es wäre schön:
... wenn mir der Designer durch ein entsprechendes Symbol kenntlich machen würde, in welcher Bibliothek noch fehlerhafter LotusScriptCode enthalten ist
... wenn der Designer die Felder mit dem fehlerhaften LotusScript Code prüft und während der Kompilation in den aktuellen LotusScript Code überführt und des Feld mit dem fehlerhaften Code löscht
... wenn der Designer während der Kompilation einen Hinweis gibt, welche Bibliotheken nicht korrekt kompiliert werden können, weil noch fehlerhaft gespeicherter Code enthalten ist
Domino Designer kompiliert nicht vollständig
Mit DDE (Domino Designer for Eclipse) kann man LotusScript Code (z.B. in Bibliotheken) auch fehlerhaft abspeichern und später korrigieren. Dieses kann einen Entwickler durchaus im Arbeitsfluss unterstützen, wenn klar ist, dass noch Codeänderungen anderer Stelle in diesem Zusammengang erforderlich sind.
Nun hatte ich erwartet, dass eine anschließende vollständige (erfolgreiche) Kompilation der Anwendung entweder mich auf verbliebene Fehler hinweist oder die Anwendung anschließend sauber bereinigt ist. Leider (wie so oft in diesen Tagen) wurde ich enttäuscht: Die erfolgreiche Kompilation der Anwendung belässt diese trotzdem in einem unsauberen Zustand! Der Code entspricht nicht dem gewünschten Stand. Funktionstests ergeben ein falsches Ergebnis.
Hintergrundinformation:
Beim Abspeichern "mit Fehlern" legt der DDE den fehlerhaften Script-Code in ein weiteres Feld "$LotusScript_error" des Gestaltungselementes ab. Bei einer erfolgreichen Kompilation wird stets der zuletzt erfolgreich gespeicherte SourceCode aus dem Feld "$LotusScript" in das Feld "$LotusScript_O" ĂĽbertragen.
Es wäre schön:
... wenn mir der Designer durch ein entsprechendes Symbol kenntlich machen wĂĽrde, in welcher Bibliothek noch fehlerhafter LotusScriptCode enthalten ist
... wenn der Designer die Felder mit dem fehlerhaften LotusScript Code prüft und während der Kompilation in den aktuellen LotusScript Code überführt und des Feld mit dem fehlerhaften Code löscht
... wenn der Designer während der Kompilation einen Hinweis gibt, welche Bibliotheken nicht korrekt kompiliert werden können, weil noch fehlerhaft gespeicherter Code enthalten ist
Nun hatte ich erwartet, dass eine anschließende vollständige (erfolgreiche) Kompilation der Anwendung entweder mich auf verbliebene Fehler hinweist oder die Anwendung anschließend sauber bereinigt ist. Leider (wie so oft in diesen Tagen) wurde ich enttäuscht: Die erfolgreiche Kompilation der Anwendung belässt diese trotzdem in einem unsauberen Zustand! Der Code entspricht nicht dem gewünschten Stand. Funktionstests ergeben ein falsches Ergebnis.
Hintergrundinformation:
Beim Abspeichern "mit Fehlern" legt der DDE den fehlerhaften Script-Code in ein weiteres Feld "$LotusScript_error" des Gestaltungselementes ab. Bei einer erfolgreichen Kompilation wird stets der zuletzt erfolgreich gespeicherte SourceCode aus dem Feld "$LotusScript" in das Feld "$LotusScript_O" ĂĽbertragen.
Es wäre schön:
... wenn mir der Designer durch ein entsprechendes Symbol kenntlich machen wĂĽrde, in welcher Bibliothek noch fehlerhafter LotusScriptCode enthalten ist
... wenn der Designer die Felder mit dem fehlerhaften LotusScript Code prüft und während der Kompilation in den aktuellen LotusScript Code überführt und des Feld mit dem fehlerhaften Code löscht
... wenn der Designer während der Kompilation einen Hinweis gibt, welche Bibliotheken nicht korrekt kompiliert werden können, weil noch fehlerhaft gespeicherter Code enthalten ist
Domino Designer kompiliert nicht vollständig
Mit DDE (Domino Designer for Eclipse) kann man LotusScript Code (z.B. in Bibliotheken) auch fehlerhaft abspeichern und später korrigieren. Dieses kann einen Entwickler durchaus im Arbeitsfluss unterstützen, wenn klar ist, dass noch Codeänderungen anderer Stelle in diesem Zusammengang erforderlich sind.
Nun hatte ich erwartet, dass eine anschließende vollständige (erfolgreiche) Kompilation der Anwendung entweder mich auf verbliebene Fehler hinweist oder die Anwendung anschließend sauber bereinigt ist. Leider (wie so oft in diesen Tagen) wurde ich enttäuscht: Die erfolgreiche Kompilation der Anwendung belässt diese trotzdem in einem unsauberen Zustand! Der Code entspricht nicht dem gewünschten Stand. Funktionstests ergeben ein falsches Ergebnis.
Hintergrundinformation:
Beim Abspeichern "mit Fehlern" legt der DDE den fehlerhaften Script-Code in ein weiteres Feld "$LotusScript_error" des Gestaltungselementes ab. Bei einer erfolgreichen Kompilation wird stets der zuletzt erfolgreich gespeicherte SourceCode aus dem Feld "$LotusScript" in das Feld "$LotusScript_O" übertragen.
Es wäre schön:
... wenn mir der Designer durch ein entsprechendes Symbol kenntlich machen würde, in welcher Bibliothek noch fehlerhafter LotusScriptCode enthalten ist
... wenn der Designer die Felder mit dem fehlerhaften LotusScript Code prüft und während der Kompilation in den aktuellen LotusScript Code überführt und des Feld mit dem fehlerhaften Code löscht
... wenn der Designer während der Kompilation einen Hinweis gibt, welche Bibliotheken nicht korrekt kompiliert werden können, weil noch fehlerhaft gespeicherter Code enthalten ist
Nun hatte ich erwartet, dass eine anschließende vollständige (erfolgreiche) Kompilation der Anwendung entweder mich auf verbliebene Fehler hinweist oder die Anwendung anschließend sauber bereinigt ist. Leider (wie so oft in diesen Tagen) wurde ich enttäuscht: Die erfolgreiche Kompilation der Anwendung belässt diese trotzdem in einem unsauberen Zustand! Der Code entspricht nicht dem gewünschten Stand. Funktionstests ergeben ein falsches Ergebnis.
Hintergrundinformation:
Beim Abspeichern "mit Fehlern" legt der DDE den fehlerhaften Script-Code in ein weiteres Feld "$LotusScript_error" des Gestaltungselementes ab. Bei einer erfolgreichen Kompilation wird stets der zuletzt erfolgreich gespeicherte SourceCode aus dem Feld "$LotusScript" in das Feld "$LotusScript_O" übertragen.
Es wäre schön:
... wenn mir der Designer durch ein entsprechendes Symbol kenntlich machen würde, in welcher Bibliothek noch fehlerhafter LotusScriptCode enthalten ist
... wenn der Designer die Felder mit dem fehlerhaften LotusScript Code prüft und während der Kompilation in den aktuellen LotusScript Code überführt und des Feld mit dem fehlerhaften Code löscht
... wenn der Designer während der Kompilation einen Hinweis gibt, welche Bibliotheken nicht korrekt kompiliert werden können, weil noch fehlerhaft gespeicherter Code enthalten ist
Domino Designer kompiliert nicht vollständig
Mit DDE (Domino Designer for Eclipse) kann man LotusScript Code (z.B. in Bibliotheken) auch fehlerhaft abspeichern und später korrigieren. Dieses kann einen Entwickler durchaus im Arbeitsfluss unterstützen, wenn klar ist, dass noch Codeänderungen anderer Stelle in diesem Zusammengang erforderlich sind.
Nun hatte ich erwartet, dass eine anschließende vollständige (erfolgreiche) Kompilation der Anwendung entweder mich auf verbliebene Fehler hinweist oder die Anwendung anschließend sauber bereinigt ist. Leider (wie so oft in diesen Tagen) wurde ich enttäuscht: Die erfolgreiche Kompilation der Anwendung belässt diese trotzdem in einem unsauberen Zustand! Der Code entspricht nicht dem gewünschten Stand. Funktionstests ergeben ein falsches Ergebnis.
Hintergrundinformation:
Beim Abspeichern "mit Fehlern" legt der DDE den fehlerhaften Script-Code in ein weiteres Feld "$LotusScript_error" des Gestaltungselementes ab. Bei einer erfolgreichen Kompilation wird stets der zuletzt erfolgreich gespeicherte SourceCode aus dem Feld "$LotusScript" in das Feld "$LotusScript_O" ĂĽbertragen.
Es wäre schön:
... wenn mir der Designer durch ein entsprechendes Symbol kenntlich machen wĂĽrde, in welcher Bibliothek noch fehlerhafter LotusScriptCode enthalten ist
... wenn der Designer die Felder mit dem fehlerhaften LotusScript Code prüft und während der Kompilation in den aktuellen LotusScript Code überführt und des Feld mit dem fehlerhaften Code löscht
... wenn der Designer während der Kompilation einen Hinweis gibt, welche Bibliotheken nicht korrekt kompiliert werden können, weil noch fehlerhaft gespeicherter Code enthalten ist
Nun hatte ich erwartet, dass eine anschließende vollständige (erfolgreiche) Kompilation der Anwendung entweder mich auf verbliebene Fehler hinweist oder die Anwendung anschließend sauber bereinigt ist. Leider (wie so oft in diesen Tagen) wurde ich enttäuscht: Die erfolgreiche Kompilation der Anwendung belässt diese trotzdem in einem unsauberen Zustand! Der Code entspricht nicht dem gewünschten Stand. Funktionstests ergeben ein falsches Ergebnis.
Hintergrundinformation:
Beim Abspeichern "mit Fehlern" legt der DDE den fehlerhaften Script-Code in ein weiteres Feld "$LotusScript_error" des Gestaltungselementes ab. Bei einer erfolgreichen Kompilation wird stets der zuletzt erfolgreich gespeicherte SourceCode aus dem Feld "$LotusScript" in das Feld "$LotusScript_O" ĂĽbertragen.
Es wäre schön:
... wenn mir der Designer durch ein entsprechendes Symbol kenntlich machen wĂĽrde, in welcher Bibliothek noch fehlerhafter LotusScriptCode enthalten ist
... wenn der Designer die Felder mit dem fehlerhaften LotusScript Code prüft und während der Kompilation in den aktuellen LotusScript Code überführt und des Feld mit dem fehlerhaften Code löscht
... wenn der Designer während der Kompilation einen Hinweis gibt, welche Bibliotheken nicht korrekt kompiliert werden können, weil noch fehlerhaft gespeicherter Code enthalten ist
Quick-Tipp: Automatische Telefonwahl über das Softphone “Phoner” aus IBM Notes heraus – eine einfache Anleitung
Phoner
ist ein Freeware-Programm von Heiko Sommerfeldt, das Gesprächsverbindungen
in das Festnetz, zu Mobiltelefonen und zu VoIP-Gegenstellen ermöglicht.
Das Programm kann als Softphone für analoge Teilnehmeranschlüsse, digitale
ISDN-Teilnehmeranschlussleitungen oder für IP-Telefonie auf stationären
und mobilen Computern benutzt werden.
Prinzipiell ist es möglich für den Phoner in einen Lotusscript-Script ein OLE Automation object "Phoner.CPhoner" anzulegen, diesem eine Nummer zu übergeben und eine Telefonruf zu starten. Dieses brachte uns auf die Idee die Widgets- und Live-Text-Funktionalität des Standard-Notes-Clients zu verwenden, um über Livetext erkannte Telefonnummern direkt für einen Telefon-Call zu nutzen.
Beschreibung der Lösung
Die Erstellung eines Notes-Widget aus einer Maske ist in der Notes-Hilfe beschrieben. Über ein solches Widget lässt sich ein Feld einer sich öffnende Notes-Maske mit der über Livetext identifizierte Telefonnummer befüllen. Prinzipiell muss abgewartet werden, bis das Widget das Feld befüllt hat. Dieses haben wir dann wie folgt gelöst:
Dim uidoc As NotesUIDocument
Dim callTimer As NotesTimer
Sub Postopen(Source As Notesuidocument)
Set uidoc = source
' erstelle und initialisiere Timer
Set callTimer = New NotesTimer(1, "rufe Telefonnummer an")
On Event Alarm From callTimer Call CallTimerHandler
End Sub
Sub CallTimerHandler(Source As NotesTimer)
Dim telefonnummer As String
' nur einmal ausführen, deshalb Timer gleich deaktivieren
source.Enabled = False
' Telefonnummer normalisieren
telefonnummer = NormalisiereTelefonnummer(uidoc.FieldGetText("Telefonnummer"))
Call uidoc.FieldSetText("Telefonnummer", telefonnummer)
If telefonnummer <> "" Then
Call RufeTelefonnummerAn(telefonnummer)
' und Dokument wieder schließen
Call uidoc.Document.ReplaceItemValue("SaveOptions", "0")
Call uidoc.Close
End If
End Sub
Function NormalisiereTelefonnummer(Byval telefonnummer As String) As String
' entferne Leerzeichen, /, -, ( und )
telefonnummer = Replace(telefonnummer, Split(" , /, -, (, )", ", "), "")
' entferne die 0 nach der Landesvorwahl (zumindest erst einmal für die deutsche Landesvorwahl)
If Left$(telefonnummer, 3) = "+49" And Left$(telefonnummer, 4) = "+490" Then
telefonnummer = "+49" & Mid$(telefonnummer, 5, 100)
End If
NormalisiereTelefonnummer = telefonnummer
End Function
Sub RufeTelefonnummerAn(telefonnummer As String)
Dim Phoner As Variant
If telefonnummer <> "" Then
Set Phoner = CreateObject("Phoner.CPhoner")
Phoner.MakeCall(telefonnummer)
End If
End Sub
Und siehe da, der Phoner wählt die Nummer aus dem Livetext an:
Hinweis: Der Phoner muss dazu schon vorher gestartet worden sein.
Prinzipiell ist es möglich für den Phoner in einen Lotusscript-Script ein OLE Automation object "Phoner.CPhoner" anzulegen, diesem eine Nummer zu übergeben und eine Telefonruf zu starten. Dieses brachte uns auf die Idee die Widgets- und Live-Text-Funktionalität des Standard-Notes-Clients zu verwenden, um über Livetext erkannte Telefonnummern direkt für einen Telefon-Call zu nutzen.
Beschreibung der Lösung
Die Erstellung eines Notes-Widget aus einer Maske ist in der Notes-Hilfe beschrieben. Über ein solches Widget lässt sich ein Feld einer sich öffnende Notes-Maske mit der über Livetext identifizierte Telefonnummer befüllen. Prinzipiell muss abgewartet werden, bis das Widget das Feld befüllt hat. Dieses haben wir dann wie folgt gelöst:
Dim uidoc As NotesUIDocument
Dim callTimer As NotesTimer
Sub Postopen(Source As Notesuidocument)
Set uidoc = source
' erstelle und initialisiere Timer
Set callTimer = New NotesTimer(1, "rufe Telefonnummer an")
On Event Alarm From callTimer Call CallTimerHandler
End Sub
Sub CallTimerHandler(Source As NotesTimer)
Dim telefonnummer As String
' nur einmal ausführen, deshalb Timer gleich deaktivieren
source.Enabled = False
' Telefonnummer normalisieren
telefonnummer = NormalisiereTelefonnummer(uidoc.FieldGetText("Telefonnummer"))
Call uidoc.FieldSetText("Telefonnummer", telefonnummer)
If telefonnummer <> "" Then
Call RufeTelefonnummerAn(telefonnummer)
' und Dokument wieder schließen
Call uidoc.Document.ReplaceItemValue("SaveOptions", "0")
Call uidoc.Close
End If
End Sub
Function NormalisiereTelefonnummer(Byval telefonnummer As String) As String
' entferne Leerzeichen, /, -, ( und )
telefonnummer = Replace(telefonnummer, Split(" , /, -, (, )", ", "), "")
' entferne die 0 nach der Landesvorwahl (zumindest erst einmal für die deutsche Landesvorwahl)
If Left$(telefonnummer, 3) = "+49" And Left$(telefonnummer, 4) = "+490" Then
telefonnummer = "+49" & Mid$(telefonnummer, 5, 100)
End If
NormalisiereTelefonnummer = telefonnummer
End Function
Sub RufeTelefonnummerAn(telefonnummer As String)
Dim Phoner As Variant
If telefonnummer <> "" Then
Set Phoner = CreateObject("Phoner.CPhoner")
Phoner.MakeCall(telefonnummer)
End If
End Sub
Und siehe da, der Phoner wählt die Nummer aus dem Livetext an:
Hinweis: Der Phoner muss dazu schon vorher gestartet worden sein.
LotusScript: db.search in Abhängigkeit vom SUMMARY Flag
Es hat mich heute ein wenig Zeit gekostet,
den Fehler in einer unser Kundenanwendungen zu finden.
Die LotusScript Funktion db.search hat nicht alle Dokumente gefunden, die der Kunde erwartet hatte. Ein Blick auf die Eigenschaften eines der fehlenden Dokumente zeigte uns die Ursache
Bei einem der Felder, die wir in der Suchabfrage verwendet hatten, fehlte das "SUMMARY" Flag. Dieses Flag regelt normaller weise, ob der Feldinhalt in einer Ansicht angezeigt werden kann.
Offensichtlich verwendet db.search die gleichen Mechanismen für die Suche wie der Indexer für die Ansicht.
Nachdem wir die Ursache gefunden hatten, war es eine Leichtigkeit mit einem kleinen Agent die Summary-Flags wieder zu setzen.
Die LotusScript Funktion db.search hat nicht alle Dokumente gefunden, die der Kunde erwartet hatte. Ein Blick auf die Eigenschaften eines der fehlenden Dokumente zeigte uns die Ursache
Bei einem der Felder, die wir in der Suchabfrage verwendet hatten, fehlte das "SUMMARY" Flag. Dieses Flag regelt normaller weise, ob der Feldinhalt in einer Ansicht angezeigt werden kann.
Offensichtlich verwendet db.search die gleichen Mechanismen für die Suche wie der Indexer für die Ansicht.
Nachdem wir die Ursache gefunden hatten, war es eine Leichtigkeit mit einem kleinen Agent die Summary-Flags wieder zu setzen.
Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgefĂĽhrt
Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien fĂĽr LotusScript-Klassen
So musste ich jĂĽngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgefĂĽhrt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgefĂĽhrt wird.
So sollte z.B. folgender Code
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
- Verwendung von abgeleiteten Klassen
- Umfangreiche Fehlerbehandlung in allen Methoden
- Verwendung von Codeschablonen im Domino Designer fĂĽr Eclipse (DDE)
So musste ich jĂĽngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgefĂĽhrt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgefĂĽhrt wird.
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
MessageBox "BaseClass",,"New"
End Sub
Sub Delete
MessageBox "BaseClass",,"Delete"
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
MessageBox "DerivedClass",,"New"
End Sub
Sub Delete
MessageBox "DerivedClass",,"Delete"
End Sub
End Class
So sollte z.B. folgender Code
Public Sub CreateClass
Set currentClass = New DerivedClass (1)
Delete currentClass
End Sub
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt
Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien für LotusScript-Klassen
So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird.
So sollte z.B. folgender Code
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
- Verwendung von abgeleiteten Klassen
- Umfangreiche Fehlerbehandlung in allen Methoden
- Verwendung von Codeschablonen im Domino Designer für Eclipse (DDE)
So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird.
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
MessageBox "BaseClass",,"New"
End Sub
Sub Delete
MessageBox "BaseClass",,"Delete"
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
MessageBox "DerivedClass",,"New"
End Sub
Sub Delete
MessageBox "DerivedClass",,"Delete"
End Sub
End Class
So sollte z.B. folgender Code
Public Sub CreateClass
Set currentClass = New DerivedClass (1)
Delete currentClass
End Sub
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt
Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien für LotusScript-Klassen
So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird.
So sollte z.B. folgender Code
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
- Verwendung von abgeleiteten Klassen
- Umfangreiche Fehlerbehandlung in allen Methoden
- Verwendung von Codeschablonen im Domino Designer für Eclipse (DDE)
So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird.
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
MessageBox "BaseClass",,"New"
End Sub
Sub Delete
MessageBox "BaseClass",,"Delete"
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
MessageBox "DerivedClass",,"New"
End Sub
Sub Delete
MessageBox "DerivedClass",,"Delete"
End Sub
End Class
So sollte z.B. folgender Code
Public Sub CreateClass
Set currentClass = New DerivedClass (1)
Delete currentClass
End Sub
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt
Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien für LotusScript-Klassen
So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird.
So sollte z.B. folgender Code
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
- Verwendung von abgeleiteten Klassen
- Umfangreiche Fehlerbehandlung in allen Methoden
- Verwendung von Codeschablonen im Domino Designer für Eclipse (DDE)
So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird.
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
MessageBox "BaseClass",,"New"
End Sub
Sub Delete
MessageBox "BaseClass",,"Delete"
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
MessageBox "DerivedClass",,"New"
End Sub
Sub Delete
MessageBox "DerivedClass",,"Delete"
End Sub
End Class
So sollte z.B. folgender Code
Public Sub CreateClass
Set currentClass = New DerivedClass (1)
Delete currentClass
End Sub
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgeführt
Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien für LotusScript-Klassen
So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird.
So sollte z.B. folgender Code
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
- Verwendung von abgeleiteten Klassen
- Umfangreiche Fehlerbehandlung in allen Methoden
- Verwendung von Codeschablonen im Domino Designer für Eclipse (DDE)
So musste ich jüngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgeführt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgeführt wird.
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
MessageBox "BaseClass",,"New"
End Sub
Sub Delete
MessageBox "BaseClass",,"Delete"
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
MessageBox "DerivedClass",,"New"
End Sub
Sub Delete
MessageBox "DerivedClass",,"Delete"
End Sub
End Class
So sollte z.B. folgender Code
Public Sub CreateClass
Set currentClass = New DerivedClass (1)
Delete currentClass
End Sub
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
Destruktor der Basisklasse einer abgeleiteten Klasse wird nicht ausgefĂĽhrt
Bei objektorientierter Entwicklung unter Verwendung von abgeleiteten Klassen kann man sich auch manchmal selbst im Weg stehen. So geschehen, wenn man einige (sonst sehr probate) Entwurfsprinzipien fĂĽr LotusScript-Klassen
So musste ich jĂĽngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgefĂĽhrt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgefĂĽhrt wird.
So sollte z.B. folgender Code
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.
- Verwendung von abgeleiteten Klassen
- Umfangreiche Fehlerbehandlung in allen Methoden
- Verwendung von Codeschablonen im Domino Designer fĂĽr Eclipse (DDE)
So musste ich jĂĽngst die Ursache finden, warum bei abgeleiteten Klassen der Destruktur (Sub Delete) der Basisklasse nicht ausgefĂĽhrt wird, obwohl der Desktruktor der abgeleiteten Klasse sehr wohl ausgefĂĽhrt wird.
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
MessageBox "BaseClass",,"New"
End Sub
Sub Delete
MessageBox "BaseClass",,"Delete"
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
MessageBox "DerivedClass",,"New"
End Sub
Sub Delete
MessageBox "DerivedClass",,"Delete"
End Sub
End Class
So sollte z.B. folgender Code
Public Sub CreateClass
Set currentClass = New DerivedClass (1)
Delete currentClass
End Sub
Zunächst den Konstruktor von "BaseClass" und danach von "DerivedClass" während der Instanziierung und der Desktruktur von "DerivedClass" gefolgt vom Destruktor der "BaseClass" durchlaufen werden.
Hat man sich jedoch ein CodeTemplate im Designer angelegt, um jede Methode einer Klasse mit Fehlerbandlung auszustatten, so entsteht z.B. folgender Code
Class BaseClass
Public Status As String
Public Sub new (intNumber As Integer)
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "BaseClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Class DerivedClass As BaseClass
Public Sub New (intNumber As Integer), BaseClass (intNumber)
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"New"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
Sub Delete
On Error GoTo ErrorBubble
MessageBox "DerivedClass",,"Delete"
SingleExit:
Exit Sub
'......................................................................................................
ErrorBubble:
Error Err, Error & Chr(13) & { --> in } & TypeName(Me) & {.} & GetThreadInfo (LSI_THREAD_PROC) & { : } & Erl
Resume SingleExit
End Sub
End Class
Hierdurch schleicht sich allerdings ein "Exit Sub" in die Destruktor Methode der abgeleiteten Klasse ein. Während dieses im Konstruktor keine Seiteneffekte hat, führt dieses beim Destruktor dazu, dass die Methode der Basisklasse nicht mehr ausgeführt wird.