Posts Tagged: ‘LotusScript’

Domino Designer kompiliert nicht vollständig

20. Januar 2014 Posted by Manfred Meise

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

Domino Designer kompiliert nicht vollständig

20. Januar 2014 Posted by Manfred Meise

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

Domino Designer kompiliert nicht vollständig

20. Januar 2014 Posted by Manfred Meise

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

Domino Designer kompiliert nicht vollständig

20. Januar 2014 Posted by Manfred Meise

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

Domino Designer kompiliert nicht vollständig

20. Januar 2014 Posted by Manfred Meise

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

Domino Designer kompiliert nicht vollständig

20. Januar 2014 Posted by Manfred Meise

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

automatische Telefonwahl über das Softphone “Phoner” aus IBM Notes heraus – eine einfache Anleitung

2. September 2013 Posted by Bernd Garrels

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.
Prinzipielle 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:

A picture named M2

Hinweis: Der Phoner sollte schon geöffnet sein.

Quick-Tipp: Automatische Telefonwahl über das Softphone “Phoner” aus IBM Notes heraus – eine einfache Anleitung

2. September 2013 Posted by Bernd Garrels

Quick-Tipp
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:

A picture named M2

Hinweis: Der Phoner muss dazu schon vorher gestartet worden sein.

LotusScript: db.search in Abhängigkeit vom SUMMARY Flag

18. Juli 2013 Posted by Bernd Hort

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

Screenshot Summary flag
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

6. Juni 2013 Posted by Manfred Meise

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
  • 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

6. Juni 2013 Posted by Manfred Meise

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
  • 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

6. Juni 2013 Posted by Manfred Meise

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
  • 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

6. Juni 2013 Posted by Manfred Meise

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
  • 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

6. Juni 2013 Posted by Manfred Meise

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
  • 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

6. Juni 2013 Posted by Manfred Meise

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
  • 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.