script-event "onCurrentDocumentSaved" is fired twice

Hello

I noticed that the script-event "onCurrentDocumentSaved" is fired twice, although I pressed the "create" butten in the document dialog only once.

The screenshot shows the Event log since I pressed "create". It does not happen every time. Could not find the reason why it happens. For example a change of the documenttype before clicking "create", seems not to be the reason.

Has anyone an idea why this happens?

In this case the script "Appointment_Print_nachf_DE" creates an activity. In case "oncurrentdocumentsaved" is fired twice there are two activities created.
Our Version is 8.1.6536.16.

Thank you!

RE: script-event "onCurrentDocumentSaved" is fired twice

I can confirm this.
Looks like the result of our Netserver Doc-plugin port..
I have added a tfs issue: 57076

Conrad

 
Af: Conrad Weyns 24. feb 2018

RE: script-event "onCurrentDocumentSaved" is fired twice

I have reproduced this a few times but now that I am digging into it, it is giving me a hard time...
The sequence of events is not exactly new. Looks like it has been like this for years.
(I dislike the CancelChanges because it is merely a hack to force our resident data to reload - it is a lie that should not need to be broadcast).

That said, if the reference (document.extref) returned by the document plugin is different then we need to do a second save.
The only thing that is new compared to the old COM plugin is if the Docplugin retuns a different file name then we need to update the document model once more and do a second save.

I don't expect you are running your own docplugin so, this should not happen in normal circumstances.

A.f.a.i.c.s. the only cause for triggering a second Save is due to either the extref or the filename was changed by the document plugin.

Have you considered hooking on the OnCurrentDocumentCreated event instead of OnCurrentDocumentSaved?

Conrad

Af: Conrad Weyns 1. mar 2018

RE: script-event "onCurrentDocumentSaved" is fired twice

Fixed in next release..
I suggest you consider hooking on the OnCurrentDocumentCreated event if you want to unambiguously know that the document is being created.
(Yes, the physical document is not yet created - never was)
The reason this issue showed up after using the Nertserver Docplugin is that the old VB plugin changed the document.name field behind your back, silently.
If you don't enter anything in the subject field, then the dialog's suggested file name will most likely be re-used. Consequently, the plugin will generate a new unique file name and the client code is then expected to update the document record.

What we do, after the docplugin has created the physical file is now silent for external events.

I may look into re-organizing the code so that the Created & Saved event will be called after the docplugin has done its work but this is not exactly trivial.

Conrad

 

Also no more "dummy" CancelChanges in between..

1: 11:49:09:590 OnCurrentDocumentIdentityChanged (1)
2: 11:49:10:224 OnViewPreShow (1) [VT_I4] 13768956, [VT_BSTR] MainWindow.DocumentDialog
3: 11:49:10:229 OnViewPreShow (1) [VT_I4] 535494, [VT_BSTR] MainWindow.DocumentDialog.DocumentDialogDetailsView
4: 11:49:10:274 OnViewShown (1) [VT_I4] 13768956, [VT_BSTR] MainWindow.DocumentDialog
5: 11:49:10:277 OnViewShown (1) [VT_I4] 535494, [VT_BSTR] MainWindow.DocumentDialog.DocumentDialogDetailsView
6: 11:49:10:417 OnDocumentFieldsChanged (1) [VT_BSTR] SetOurRef, [VT_UI4]0, [VT_BSTR] OUR_REF, [VT_INT]2564
7: 11:49:10:422 OnCurrentDocumentFieldChanged (1) [VT_BSTR] document.OUR_REF
8: 11:49:10:473 OnDocumentFieldsChanged (1) [VT_BSTR] SetName, [VT_UI4]0, [VT_BSTR] NAME, [VT_INT]2562
9: 11:49:10:478 OnCurrentDocumentFieldChanged (1) [VT_BSTR] document.NAME
10: 11:49:10:524 OnDocumentFieldsChanged (1) [VT_BSTR] SetName, [VT_UI4]0, [VT_BSTR] NAME, [VT_INT]2562
11: 11:49:10:529 OnCurrentDocumentFieldChanged (1) [VT_BSTR] document.NAME
12: 11:49:10:555 OnDocumentFieldsChanged (1) [VT_BSTR] SetName, [VT_UI4]0, [VT_BSTR] NAME, [VT_INT]2562
13: 11:49:10:561 OnCurrentDocumentFieldChanged (1) [VT_BSTR] document.NAME
14: 11:49:12:229 OnCurrentDocumentBeforeSave (1)
15: 11:49:12:236 OnCurrentDocumentCompletedChanged (1) [VT_I4] 0, [VT_I4] 3
16: 11:49:12:712 OnDocumentFieldsChanged (1) [VT_BSTR] SaveModel, [VT_UI4]173, [VT_BSTR] REGISTERED, [VT_INT]2571
17: 11:49:12:720 OnCurrentDocumentFieldChanged (1) [VT_BSTR] document.REGISTERED
18: 11:49:12:773 OnCurrentDocumentCreated (1)
19: 11:49:12:779 OnCurrentDocumentSaved (1)
20: 11:49:12:787 OnFilterRestrictionsFor_contactactivity_contactactivityarchive (0) [VT_BSTR] contactactivity, [VT_BSTR] contactactivityarchive, [VT_BSTR] superoffice:contact.activityarchive?db_id=1010000014&document_id=170&contact_id=14, [VT_BSTR] active=True&name=contactId&operator=equals&numvalues=1&value=14|active=True&name=documentId&operator=equals&numvalues=1&value=173
21: 11:49:13:433 OnFilterRestrictionsFor_contactactivity_contactactivityarchive (0) [VT_BSTR] contactactivity, [VT_BSTR] contactactivityarchive, [VT_BSTR] superoffice:contact.activityarchive?db_id=1010000014&document_id=173&contact_id=14, [VT_BSTR] active=True&name=contactId&operator=equals&numvalues=1&value=14|active=True&name=documentId&operator=equals&numvalues=1&value=173
22: 11:49:13:841 OnViewPreHide (1) [VT_I4] 535494, [VT_BSTR] MainWindow.DocumentDialog.DocumentDialogDetailsView
23: 11:49:13:851 OnViewPreHide (1) [VT_I4] 13768956, [VT_BSTR] MainWindow.DocumentDialog
24: 11:49:13:892 OnViewHidden (1) [VT_I4] 535494, [VT_BSTR] MainWindow.DocumentDialog.DocumentDialogDetailsView
25: 11:49:13:912 OnViewHidden (1) [VT_I4] 13768956, [VT_BSTR] MainWindow.DocumentDialog
26: 11:49:14:46 OnArchiveRowSelected (1) [VT_BSTR] contactactivity, [VT_BSTR] contactactivityarchive, [VT_BSTR] document, [VT_BSTR] 173

Af: Conrad Weyns 5. mar 2018