Zur Beurteilung der verfügbaren Funktionen unterschiedlich Notes-Clients in den aktuellen Versionen hat IBM eine übersichtlicher Gegenüberstellung publiziert:
http://www-01.ibm.com/support/docview.wss?uid=swg27040248
Funktionale Gegenüberstellung von Client-Funktion (IBM Notes, IBM iNotes & IBM SmartCloud Notes web)
Deutsche Notes/Domino Versionen schreiben falsche Log-Dokumente
Domino Entwickler verwenden gelegentlich die LotusScript-Klasse "NotesLog" um z.B. mit der "LogAction" Methode in eine entsprechende Datenbank zu schreiben. Hierbei schreibt jedoch ein Notes/Domino Release 9.0.1 Client einen falschen Wert ("Akton" statt "Action") in das Feld "A$LOGTYPE" der Protokolldokumente.
Das Ergebnis sieht dann wie folgt aus:
Durch Umstellen z.B. des Clients auf die englische Benutzeroberfläche werden LogDokumente sauber generiert und angezeigt:
Das Ergebnis sieht dann wie folgt aus:
Durch Umstellen z.B. des Clients auf die englische Benutzeroberfläche werden LogDokumente sauber generiert und angezeigt:
Deutsche Notes/Domino Versionen schreiben falsche Log-Dokumente
Domino Entwickler verwenden gelegentlich die LotusScript-Klasse "NotesLog" um z.B. mit der "LogAction" Methode in eine entsprechende Datenbank zu schreiben. Hierbei schreibt jedoch ein Notes/Domino Release 9.0.1 Client einen falschen Wert ("Aktion" statt "Action") in das Feld "A$LOGTYPE" der Protokolldokumente.
Das Ergebnis sieht dann wie folgt aus:
Durch Umstellen z.B. des Clients auf die englische Benutzeroberfläche werden LogDokumente sauber generiert und angezeigt:
Das Ergebnis sieht dann wie folgt aus:
Durch Umstellen z.B. des Clients auf die englische Benutzeroberfläche werden LogDokumente sauber generiert und angezeigt:
Deutsche Notes/Domino Versionen schreiben falsche Log-Dokumente
Domino Entwickler verwenden gelegentlich die LotusScript-Klasse "NotesLog" um z.B. mit der "LogAction" Methode in eine entsprechende Datenbank zu schreiben. Hierbei schreibt jedoch ein Notes/Domino Release 9.0.1 Client einen falschen Wert ("Aktion" statt "Action") in das Feld "A$LOGTYPE" der Protokolldokumente.
Das Ergebnis sieht dann wie folgt aus:
Durch Umstellen z.B. des Clients auf die englische Benutzeroberfläche werden LogDokumente sauber generiert und angezeigt:
Das Ergebnis sieht dann wie folgt aus:
Durch Umstellen z.B. des Clients auf die englische Benutzeroberfläche werden LogDokumente sauber generiert und angezeigt:
Deutsche Notes/Domino Versionen schreiben falsche Log-Dokumente
Domino Entwickler verwenden gelegentlich die LotusScript-Klasse "NotesLog" um z.B. mit der "LogAction" Methode in eine entsprechende Datenbank zu schreiben. Hierbei schreibt jedoch ein Notes/Domino Release 9.0.1 Client einen falschen Wert ("Aktion" statt "Action") in das Feld "A$LOGTYPE" der Protokolldokumente.
Das Ergebnis sieht dann wie folgt aus:
Durch Umstellen z.B. des Clients auf die englische Benutzeroberfläche werden LogDokumente sauber generiert und angezeigt:
Das Ergebnis sieht dann wie folgt aus:
Durch Umstellen z.B. des Clients auf die englische Benutzeroberfläche werden LogDokumente sauber generiert und angezeigt:
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
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
mailto Links starten Internet Explorer statt Lotus Notes
Obwohl die Installation des Lotus Notes 8.5.3 Clients vollständig und richtig ist, funktionieren "mailto" links (z.B. auf Webseiten, im Mail oder im Browser). Nicht statt dessen öffnet sich undentlich oft der Internet Explorer 11.
Die Installation des Lotus Notes Clients wurde auf einem Cirtix-Server (Windows 2008R2 mit aktuellen Windows Updates) genutzt.
Die erste Kontrolle galt dem "Standardprogrammen" in der Systemsteuerung. Diese sahen vollständig aus.
Bei der Kontrolle der Registry waren zahlreiche erwarte Einträge auch wirklich (richtig) vorhanden. Lediglich in einem Zweig fehlten einige Einträge:
Nach Hinzufügen diese Einträge kann man dann auch wieder Lotus Notes über "mailto-Links" starten.
Die Installation des Lotus Notes Clients wurde auf einem Cirtix-Server (Windows 2008R2 mit aktuellen Windows Updates) genutzt.
Die erste Kontrolle galt dem "Standardprogrammen" in der Systemsteuerung. Diese sahen vollständig aus.
Bei der Kontrolle der Registry waren zahlreiche erwarte Einträge auch wirklich (richtig) vorhanden. Lediglich in einem Zweig fehlten einige Einträge:
[HKEY_CLASSES_ROOT\mailto]
"URL Protocol"=""
@="URL:MailTo-Protokoll"
"EditFlags"=hex:02,00,00,00
"FriendlyTypeName"="@C:\\Windows\\system32\\ieframe.dll,-910"
[HKEY_CLASSES_ROOT\mailto\DefaultIcon]
@="C:\\IBM\\Lotus\\Notes\\notes.exe,0"
[HKEY_CLASSES_ROOT\mailto\shell]
@="open"
[HKEY_CLASSES_ROOT\mailto\shell\open]
[HKEY_CLASSES_ROOT\mailto\shell\open\command]
@="\"C:\\IBM\\Lotus\\Notes\\notes.exe\" -defini \"%1\""
Nach Hinzufügen diese Einträge kann man dann auch wieder Lotus Notes über "mailto-Links" starten.
mailto Links starten Internet Explorer statt Lotus Notes
Obwohl die Installation des Lotus Notes 8.5.3 Clients vollständig und richtig ist, funktionieren "mailto" links (z.B. auf Webseiten, im Mail oder im Browser). Nicht statt dessen öffnet sich undentlich oft der Internet Explorer 11.
Die Installation des Lotus Notes Clients wurde auf einem Cirtix-Server (Windows 2008R2 mit aktuellen Windows Updates) genutzt.
Die erste Kontrolle galt dem "Standardprogrammen" in der Systemsteuerung. Diese sahen vollständig aus.
Bei der Kontrolle der Registry waren zahlreiche erwarte Einträge auch wirklich (richtig) vorhanden. Lediglich in einem Zweig fehlten einige Einträge:
Nach Hinzufügen diese Einträge kann man dann auch wieder Lotus Notes über "mailto-Links" starten.
Die Installation des Lotus Notes Clients wurde auf einem Cirtix-Server (Windows 2008R2 mit aktuellen Windows Updates) genutzt.
Die erste Kontrolle galt dem "Standardprogrammen" in der Systemsteuerung. Diese sahen vollständig aus.
Bei der Kontrolle der Registry waren zahlreiche erwarte Einträge auch wirklich (richtig) vorhanden. Lediglich in einem Zweig fehlten einige Einträge:
[HKEY_CLASSES_ROOT\mailto]
"URL Protocol"=""
@="URL:MailTo-Protokoll"
"EditFlags"=hex:02,00,00,00
"FriendlyTypeName"="@C:\\Windows\\system32\\ieframe.dll,-910"
[HKEY_CLASSES_ROOT\mailto\DefaultIcon]
@="C:\\IBM\\Lotus\\Notes\\notes.exe,0"
[HKEY_CLASSES_ROOT\mailto\shell]
@="open"
[HKEY_CLASSES_ROOT\mailto\shell\open]
[HKEY_CLASSES_ROOT\mailto\shell\open\command]
@="\"C:\\IBM\\Lotus\\Notes\\notes.exe\" -defini \"%1\""
Nach Hinzufügen diese Einträge kann man dann auch wieder Lotus Notes über "mailto-Links" starten.
mailto Links starten Internet Explorer statt Lotus Notes
Obwohl die Installation des Lotus Notes 8.5.3 Clients vollständig und richtig ist, funktionieren "mailto" links (z.B. auf Webseiten, im Mail oder im Browser). Nicht statt dessen öffnet sich undentlich oft der Internet Explorer 11.
Die Installation des Lotus Notes Clients wurde auf einem Cirtix-Server (Windows 2008R2 mit aktuellen Windows Updates) genutzt.
Die erste Kontrolle galt dem "Standardprogrammen" in der Systemsteuerung. Diese sahen vollständig aus.
Bei der Kontrolle der Registry waren zahlreiche erwarte Einträge auch wirklich (richtig) vorhanden. Lediglich in einem Zweig fehlten einige Einträge:
Nach Hinzufügen diese Einträge kann man dann auch wieder Lotus Notes über "mailto-Links" starten.
Die Installation des Lotus Notes Clients wurde auf einem Cirtix-Server (Windows 2008R2 mit aktuellen Windows Updates) genutzt.
Die erste Kontrolle galt dem "Standardprogrammen" in der Systemsteuerung. Diese sahen vollständig aus.
Bei der Kontrolle der Registry waren zahlreiche erwarte Einträge auch wirklich (richtig) vorhanden. Lediglich in einem Zweig fehlten einige Einträge:
[HKEY_CLASSES_ROOT\mailto]
"URL Protocol"=""
@="URL:MailTo-Protokoll"
"EditFlags"=hex:02,00,00,00
"FriendlyTypeName"="@C:\\Windows\\system32\\ieframe.dll,-910"
[HKEY_CLASSES_ROOT\mailto\DefaultIcon]
@="C:\\IBM\\Lotus\\Notes\\notes.exe,0"
[HKEY_CLASSES_ROOT\mailto\shell]
@="open"
[HKEY_CLASSES_ROOT\mailto\shell\open]
[HKEY_CLASSES_ROOT\mailto\shell\open\command]
@="\"C:\\IBM\\Lotus\\Notes\\notes.exe\" -defini \"%1\""
Nach Hinzufügen diese Einträge kann man dann auch wieder Lotus Notes über "mailto-Links" starten.
mailto Links starten Internet Explorer statt Lotus Notes
Obwohl die Installation des Lotus Notes 8.5.3 Clients vollständig und richtig ist, funktionieren "mailto" links (z.B. auf Webseiten, im Mail oder im Browser). Nicht statt dessen öffnet sich undentlich oft der Internet Explorer 11.
Die Installation des Lotus Notes Clients wurde auf einem Cirtix-Server (Windows 2008R2 mit aktuellen Windows Updates) genutzt.
Die erste Kontrolle galt dem "Standardprogrammen" in der Systemsteuerung. Diese sahen vollständig aus.
Bei der Kontrolle der Registry waren zahlreiche erwarte Einträge auch wirklich (richtig) vorhanden. Lediglich in einem Zweig fehlten einige Einträge:
Nach Hinzufügen diese Einträge kann man dann auch wieder Lotus Notes über "mailto-Links" starten.
Die Installation des Lotus Notes Clients wurde auf einem Cirtix-Server (Windows 2008R2 mit aktuellen Windows Updates) genutzt.
Die erste Kontrolle galt dem "Standardprogrammen" in der Systemsteuerung. Diese sahen vollständig aus.
Bei der Kontrolle der Registry waren zahlreiche erwarte Einträge auch wirklich (richtig) vorhanden. Lediglich in einem Zweig fehlten einige Einträge:
[HKEY_CLASSES_ROOT\mailto]
"URL Protocol"=""
@="URL:MailTo-Protokoll"
"EditFlags"=hex:02,00,00,00
"FriendlyTypeName"="@C:\\Windows\\system32\\ieframe.dll,-910"
[HKEY_CLASSES_ROOT\mailto\DefaultIcon]
@="C:\\IBM\\Lotus\\Notes\\notes.exe,0"
[HKEY_CLASSES_ROOT\mailto\shell]
@="open"
[HKEY_CLASSES_ROOT\mailto\shell\open]
[HKEY_CLASSES_ROOT\mailto\shell\open\command]
@="\"C:\\IBM\\Lotus\\Notes\\notes.exe\" -defini \"%1\""
Nach Hinzufügen diese Einträge kann man dann auch wieder Lotus Notes über "mailto-Links" starten.