Notes-Fehler 0c:16

[Barbara]

Hallo Zusammen,
ich habe in einem Dokument ein eingebettetes Objekt (Excel), das ich per Button öffne:

Set xlapp=createObject("Excel.Application")
Set rtitem = doc.GetFirstItem( "Vertrag" )
If ( rtitem.Type = RICHTEXT ) Then
Set object= rtitem.GetEmbeddedObject("Vertraege")   
End If
Set handle=object.activate (True)

Funktioniert so weit auch gut. Heute kommt eine Meldung eines Users, dem beim Versuch das Objekt zu öffnen die Fehlermeldung "Notes-Fehler 0c:16" angezeigt wird. Bei einem anderen Client öffnet das Objekt klaglos.

Hat jemand diese Fehlermeldung schon einmal gesehen? Wo setze ich bei der Fehlersuche an?

Gruß
Barbara   

[Axel]

Hast du schon mal die chache.ndk auf dem entsprechenden Rechner gelöscht?

Könnte auch sein, dass die Excel-Installation und/oder die Notes-Client - Installation auf dem betreffenden Rechner einen Knacks hat.

Was anderes fällt mir bei der "vielsagenden" Fehlermeldung (liegt aber nicht an dir) im Moment nicht ein.



Axel

[koehlerbv]

Mit der Fehlermeldung kann nicht mal NEMDisplayError aus der API etwas anfangen ... Die Fehlernummer habe ich bisher in ganz unterschiedlichen Zusammenhängen gefunden: Ein Bug in 6.5.5 (wenn in zwei Events konkurrierend der EditMode verändert werden soll) und 6.5.5 beim Öffnen eines Besprechungstermins.

Ein Blick auf die Client-Version würde aber ggf. lohnen (6.5.5 ist nicht empfehlenswert, weil richtig buggy).

Bernhard

[Thomas Schulte]

Naja das mit der 6.5.5 kann man so nicht sagen. Die Urversion vielleicht aber mit der CCH4 läuft das Teil ziemlich stabil.

[Axel]

...(6.5.5 ist nicht empfehlenswert, weil richtig buggy).

Kann ich aber so nicht bestätigen. Das Teil läuft eigentlich recht stabil. Wir setzen di Version inzwischen flächendeckend ein.


Axel

[botschi]

Vielleicht liegt es an unterschiedlichen Office-Versionen der Arbeitsplätze.
Ich habe vor ein paar Jahren Probleme beim Im- oder Export mit Office2000 gehabt. Wir haben es unter Office97 entwickelt und als der Kunde Monate später Office2000 installiert hatte, gings los...

Hat gedauert, bis wir auf die Spur kamen...

Matthias

[Barbara]

Viele Ideen zum überprüfen, werde ich auch tun. Ich kann noch Eines draufsetzen.
Man kann "Folge"-Dokumente erstellen, in die das Objekt übernommen wird (keine Antwortdoks). Macht mein User dieses, dann öffnet das Objekt wieder klaglos. Im Ursprungsdokument kommt die Fehlermeldung. Da kommt doch Freude auf...

Barbara

[Axel]

Dann würde ich aber vermuten, dass das Dokument einen Schalg (ähm, Schlag) hat.

Axel


PS: Immer diese Wechstabenverbuchsler.

[m3]

Dann würde ich aber vermuten, dass das Dokument einen Schalg hat.

Dem sitzt sozusagen der Schlag im Nacken.  

Barbara: Schau Dir das Dok doch mal mit NotesPeek an, ev. siehst Du ja was "seltsames".

[botschi]

Oder die cache löschen.
Oder die bookmark mal umbenennen. Wir haben schon die abenteuerlichsten Fehler gehabt, die wegen einem defekten Lesezeichen auftraten.

Wenn es nur einen User betrifft liegt die Vermutung nahe, dass dieser User ein Probem mit dem Client hat.

[just.do.it]

Hallo,

wo wir schon beim Thema "seltsame Phänomene " sind.  Das komprimieren des Arbeitsbereiches wirkt auch manchmal Wunder. 

Gruß
Dirk

[Barbara]

So, ich habe den Fehler eingegrenzt.
1. Er tritt nur bei 6.5.5 auf.
2. Jetzt muss ich etwas ausholen. Diese Dokumente sind unter bestimmten Bedingungen nicht bearbeitbar (Querymodechange). Da viele User das Objekt zum Bearbeiten öffnen ohne sich zu vergewissern, dass sie im Editmode sind, schaltet der Button automatisch um. Und durchläuft dabei den Querymodechange. Ist das Bearbeiten verboten - voilá kommt der Fehler.
If uidoc.EditMode=False Then uidoc.EditMode=True
If uidoc.EditMode=False Then ......

Jetzt muss ich erst mal in mein stilles Kämmerlein und nach einer Lösung suchen. 

Danke für's mitdenken

Barbara

[Barbara]

Ich habe die Bedingungen für das Bearbeiten in den Button mit eingebaut. Wenn jetzt die Aufforderung zum Umschalten kommt, läuft der Querymodechange ohne Abbruch durch und die Fehlermeldung bleibt aus. Getestet auf 6.5.2; 6.5.4; 6.5.5; 7.0.1

Gruß
Barbara

[eknori]

Antwort steht in der KnowledgeBase:

In IBM Lotus Notes Client 6.5.5 the following error occurs when a user is working in a Notes document:

"Notes Error - #0C:16".

The user may be opening the document, recalculating it, sending it, saving it, closing it, etc.  Whether the document was originally opened in Read mode verses Edit mode may affect whether or not the error is observed.  This issue was not observed in prior 6.x releases of the Notes Client or 7.x releases of the Notes Client.

The issue occurs in cases where the form's QueryModeChange sets Continue=False, and another form event is coded to change the Edit mode via LotusScript using the EditMode property (of the NotesUIDocument class).  The issue can be observed in cases where EditMode is being set to True or False depending on the sequence of steps.

The error does not actually trigger when the code Continue=False is executed, but actually when the flow of control passes back to the event which set the EditMode property.

A basic example that demonstrates the issue is below.

Given a form that contains the following code in the events noted:

Sub Postopen(Source As Notesuidocument)
   Source.EditMode=True
End Sub

Sub Querymodechange(Source As Notesuidocument, Continue As Variant)
   Continue=False
End Sub

If you create a document with the above form, save it and close it, and then re-open it in Read mode the error will occur.  If the PostOpen event set EditMode to False then the error would occur in cases where you opened the document in Edit mode initially.

Lösung:

This problem was reported to Quality Engineering as SPR # MFOE6E8STJ, and a fix is being researched.

A cumulative client hotfix (CCH) is available for Notes Client 6.5.5 that fixes the issue reported in SPR# MFOE6E8STJ.  Since hotfixes do not receive the extensive testing that maintenance releases and fix packs do, customers are encouraged to implement workarounds until this fix is in a generally available release.  However, if workarounds are not possible and you still need a fix, please contact IBM Technical Support to request the CCH containing the fix for this issue.

Workaround:
Rather than performing conditional checks designed to halt a mode change within the QueryModeChange event, you can design similar checks within the events that are setting the EditMode property such that they avoid setting it when undesired.

For example, if the QueryModeChange event contained a conditional check:

If <condition> then
  Continue=False
End If

Then remove the above code and apply the same logic to the event setting EditMode:

If Not <condition> Then
  source.editmode=...
End If