Das Notes Forum

Lotus Notes / Domino Sonstiges => Projekt Bereich => Help-Desk Applikation !!Help!! => Thema gestartet von: Lauff am 08.03.06 - 09:18:09

Titel: Absturz bei Bearbeiten
Beitrag von: Lauff am 08.03.06 - 09:18:09

Hallo,

an einigen Rechnern konnt es zu einem Absturz wenn man in einer Ansicht (zb. Open by Date) auf den Button bearbeiten klickt.
Dieses Fehler ist mit LN6.5.3 unter Win2003 und WinXP reproduzierbar. Gesichert ist er bisher nur mit einer LN-ID aufgetaucht. Weitere Tests laufen. Die Logfiles des LS-Debugger habe ich angehängt.

Weiterhin ist mir aufgefallen, das sich bei mir LN schließt, wenn ich ein Ticket öffen, das auch in der Vorschau zu sehen ist. Dieses wiederum geht nur auf meine PC, dafür zuverläsig.

Wichtig ist aber der erste Fehler.

Titel: Re: Absturz bei Bearbeiten
Beitrag von: Thomas Schulte am 08.03.06 - 09:26:28

Also der zweite Punkt funktioniert bei mir LN6.5.4 CC5 ohne Probleme.

Das andere schau ich mir heute Abend einmal an.

Titel: Re: Absturz bei Bearbeiten
Beitrag von: Lauff am 08.03.06 - 10:36:02

Habe das jetzt auf noch weiteren PC getestet dort geht es auch (bzw. halt nicht).

Sidn XP PCs. Logs anbei.

Titel: Re: Absturz bei Bearbeiten
Beitrag von: Thomas Schulte am 08.03.06 - 11:59:41

Bezieht sich der letzte Post auf Fehler 1 oder Fehler 2??

Titel: Re: Absturz bei Bearbeiten
Beitrag von: Lauff am 08.03.06 - 15:01:50

Äh sorry, wäre ja auch wichtig gewesen.

Fehler 1

Titel: Re: Absturz bei Bearbeiten
Beitrag von: Thomas Schulte am 08.03.06 - 16:37:38

Auch wenn es jetzt nicht wirklich jemandem hilft. Das scheint ein generelles Problem der Anwendung mit 6.5.3 zu sein. Unter 6.5.4 CC5 funktioniert das. Und was auch interessant ist, das ist scheinbar nur ein Problem wenn man das Dokument direkt im Edit Modus öffnen will, also mit "Strg-B" oder eben dem Button "Bearbeiten".

Das gleiche gilt übrigens auch für die Arbeit mit Mail Templates. Wenn man unter 6.5.3 ein neues Mail erstellt und dann aus den Templates eines auswählt, dann wird der Client gnadenlos abgeschossen. Das passiert deswegen, weil wir ein wenig Komfort für den Anwender einbauen wollten und deswegen den Aufruf uiwksp.editdocument(true,Notesdocument) gewählt haben. Damit wird das Uidoc im Editmodus geöffnet und der NSD Fehler erscheint. Wenn ich jetzt diesen Aufruf der im Postopen steckt auf uiwksp.editdocument(false,doc) ändere, dann bekomme ich diesen Fehler nicht.

Es scheint so, das Notes in Help in dieser Version dann ein Problem hat, wenn das Uidoc, das geöffnet werden soll vorher schon einmal geöffnet wurde. Auch die Verwendung von uidoc.close(true) die ja ein sofortiges Schließen des Uidocs erzwingt hat hier keine Auswirkungen. Irgendwie kommt der Client da mit seiner eigenen Speicherallocation durcheinander.

Bekannte Workarounds:
Wenn 6.5.3 eingesetzt werden muss.
für den Fehler bei der Vorschau:
Wenn die Vorschau aktiv ist nicht auf bearbeiten oder strg-b klicken. sondern das Dokument mit einem Doppelklick öffnen und dann erst in den Bearbeitungsmodus wechseln.
für den Fehler beim Mail Template:
Anpassen der Maske BugMail, me_uidoc.editdocument(false,me_doc) im Postopen Event eintragen.
Upgrade auf V6.5.4 CC5
damit scheinen diese Fehler behoben zu sein.
Upgrade auf V6.5.5
Das habe ich noch nicht gegen diese Fehler getestet.
Downgrade auf V6.5.2
allerdings gibt es da andere Fehler (haben wir hier im Forum schon ein paar Mal diskutiert).
Einsatz von V7.0.0
Das scheint auch zu laufen.

Hier werde ich aber keinen ESR stellen. Sollte jemand keine Möglichkeit haben in Upgrade zu fahren, dann kann er ein diesen Fehler betreffendes ESR stellen, ich bin gerne bereit, dann die Fehlersuche bei IBM zu unterstützen.

Titel: Re: Absturz bei Bearbeiten
Beitrag von: Thomas Schulte am 10.03.06 - 10:31:15

OK ein wenig weiter geforscht und das Ergebnis ist:
Das scheint ein Problem der ClassHistory zu sein das in Kombination mit der Vorschau, bzw. dann wenn ein Mail Template verwendet wird unter 6.5.3 zuschlägt.
und zwar wird beim postopen Event einer Maske in !!Help!! die Feldüberwachung gestartet:

Code

' find a config document for history watching for this form
	Configstring = GetConfigDocByKey ("WatchFieldHistoryBugReport")
	Set g_history = New History
	Call g_history.PostopenStartObservation(Source, Split(Configstring,";"))

nimmt man diesen Block da jetzt raus, dann hat man auch keinen Fehler mehr. Allerdings auch keine Überwachung.
Lässt man den Ganze im Debugger laufen, dann passiert der NSD Fehler nicht.
Sobald man es direkt aufruft oder im Debugger auf Fortfahren klickt bekommt man den NSD.

Von Ablauf ist das bei der eingeschalteten Vorschau so, das der Client das Dokument im Lesemodus öffnet und damit die ClassHistory Überwachung feuert. Dann mach ich das Dokument im Bearbeitungsmodus auf und jetzt feuert der noch einmal während der Client im Hintergrund den Speicher für das vorherige ClassHistory Objekt noch freigibt. Und genau da zerlegt es ihn dann.

Also entweder kann ich das vermeiden oder ich muss in irgendeiner Form die Zerstörung des History Objektes beschleunigen.

Ich seh nur in Moment leider nicht wie das gehen soll.

Titel: Re: Absturz bei Bearbeiten
Beitrag von: -Michael- am 10.03.06 - 18:26:26

Hi,

Thomas hat mich per Mail gefragt, ob ich mir das mal anschauen kann, da die History Klasse von mir ist...

Bruce Elgort hatte mir vor ein paar Monaten mal eine Mail geschickt, weil unter ND7 die Klasse nicht funktionierte:

Zitat

Michael,

I am using and loving your history class lss.  I have ran into one problem that I cannot figure out.  I have a form in a database that only seems to log changes using the history class when I debug it.  If I turn off the debugger and try to makechanges none get logged.  It's the strangest thing.  I use the code in the same database in a different form and it works great.  Any hints?

Regards,

Bruce

Mein Lösungsvorschlag:

Zitat

Hello Bruce,

That's strange. I am using the class in more than 15 forms in different
databases and did not yet see such strange behavior.

Well, in the "PostOpenStartObservation" sub (that is usually called in
the Post Open event of a form), there is the following code line:
       On Event Querymodechange From m_uidoc Call ProcessQuerymodeChange

I am using this to avoid using extra code in the QuerymodeChange event.
So maybe here is something not working as it should. I would try to
comment out this line and add a code in the Querymodechange event of the
form:
-> Call History.ProcessQuerymodeChange(Source, Continue)

Since this sub is private, you should change it in the history class
from:
   Private Sub ProcessQuerymodeChange(Source As NotesUIDocument,
Continue As Variant)
to:
   Public Sub ProcessQuerymodeChange(Source As NotesUIDocument,
Continue As Variant)

Hope this helps.

Bei Bruce hatte das geholfen. Ich habe das Gefühl, dass das hier bei Euch auch die Lösung sein könnte. Probiert es einfach mal aus. Ich kann es nicht testen, da ich hier nur einen 6.5.4er Client installiert habe, mit dem es ja funktioniert...

Grüße,
Michael