Requesting some deeper than usual information

[ebenton]

Greeting Adepters,

This post is asking for a little more detailed information about Editor's inner workings than we usually see here, but like the saying goes, "If you don't ask, you don't get."

We have created an application which uses PTC Arbortext Editor for editing of XML documents. It initiates a document editing session and is notified of any save action by means of DocumentSaving event. We have Editor customizations that perform a set of data extraction and persistence operations that are executed as part of any document save request. The main application listens for the DocumentSaving event to refresh itself according to the current document state and the extracted data.

We have run into a sequencing issue related to the invocation of DocumentSaving event and the execution of our Editor save customization. When a save request is made by the user, Arbortext Editor will immediately raise the DocumentSaving event. Our save customizations do not get executed until after the event handler of the listener has completed. This results in the main application refreshing itself with data that does not represent the current state of the document as it exists within the Editor.

Is there a way of controlling how or when the DocumentSaving event is invoked by the Editor in order to allow our save customizations to be executed before the event is invoked?

[ClayHelberg]

Hi Ed-

I'm not sure about explicitly controlling the order of callbacks and AOM events. (It's not clear whether your Editor customizations are ACL using callbacks or AOM using event listeners.)

One approach you might consider trying: instead of basing your customizations on callbacks or events, you might be able to intercept the save triggers directly, so you can do your close-out operations, and then trigger the DocumentSaving event by explicitly calling save() (or ADocument.save()). In other words something like this:

alias FileSave my_save();

function my_save(doc = current_doc()) {
# do my custom stuff
prep_doc_for_save(doc);
# do the save and generate the DocumentSaving event
doc_save(doc);
}

You would probably have to alias a handful of commands, including FileSave, FileSaveAs, FileSaveAll, as well as any customizations you may have that can trigger a save in some other way.

--Clay

[naglists]

I don't think you are using save callbacks ... but could you use a save
callback to create a different event than DocumentSaving and listen for
that instead?


On Wed, Feb 25, 2015 at 11:09 AM, Clay Helberg <->
wrote:

> Hi Ed--
>
>
>
> I'm not sure about explicitly controlling the order of callbacks and AOM
> events. (It's not clear whether your Editor customizations are ACL using
> callbacks or AOM using event listeners.)
>
>
>
> One approach you might consider trying: instead of basing your
> customizations on callbacks or events, you might be able to intercept the
> save triggers directly, so you can do your close-out operations, and then
> trigger the DocumentSaving event by explicitly calling save() (or
> ADocument.save()). In other words something like this:
>
>
>
> alias FileSave my_save();
>
>
>
> function my_save(doc = current_doc()) {
>
> # do my custom stuff
>
> prep_doc_for_save(doc);
>
> # do the save and generate the DocumentSaving event
>
> doc_save(doc);
>
> }
>
>
>
> You would probably have to alias a handful of commands, including
> FileSave, FileSaveAs, FileSaveAll, as well as any customizations you may
> have that can trigger a save in some other way.
>
>
>
> --Clay
>
>
>
> *From:* Benton, Ed L [
> don't ask, you don't get."
>
>
>
> We have created an application which uses PTC Arbortext Editor for editing
> of XML documents. It initiates a document editing session and is notified
> of any save action by means of DocumentSaving event. We have Editor
> customizations that perform a set of data extra...