Pages: 1
Print
Author Topic: Saved property  (Read 6756 times)
KdG
Member

Posts: 19


WWW
« on: November 21, 2011, 05:32:59 AM »

We recently upgraded from 4.6 to 6.0. And now we run into a problem that has been described before on this forum, however without a solution. It has to do with macro document changes saving and undo.

Case:
We open and save a documents from a database using macro's.
Upon saving we set some document metadata before sending the content to the database and saving the file locally
The macro uses the following order:
...
rng.ContainerAttribute("datetime")=dt
ActiveDocument.Save();
ActiveDocument.Saved=true;

Now when the macro finishes XMetaL still marks the document as not saved, because of the attribute update, although is was saved properly.
When closing the document XMetaL presents an unwanted "Save changes" dialog.

How can we prevent this?

Regards,
 Kees
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #1 on: November 21, 2011, 02:00:38 PM »

Please let us know the full version of the software that you are running (6.0.x.xxx) and which product it is (XMetaL Author Enterprise, XMetaL Author Essential).
Logged
KdG
Member

Posts: 19


WWW
« Reply #2 on: November 22, 2011, 02:10:06 AM »

Hi Derek,

We use
XMetaL Author Essential 6.0  SP1 (XMES 6.0  SP1) Version#: 6.0.2.070
and  
XMetaL Author Essential  5.5 Build No:  5.5.093, Version#: 5.5.0.221

Both show the same behavior.

Regards,
 Kees
« Last Edit: November 22, 2011, 02:28:26 AM by KdG » Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #3 on: November 22, 2011, 11:46:28 AM »

It sounds like a bug was introduced that is affecting one of the APIs. Probably due to interaction with some other new feature introduced somewhere in the 5.0 to 5.5 time frame.

I suspect there must be a very specific set of steps to reproduce this issue as I cannot reproduce it yet by simply calling ActiveDocument.Saved = true (on a Journalist sample document). This will need some more testing. I'll try to set something up that mimics your script and allows this attribute to be set (assuming that is the trigger).

If you could submit a support case to XMetaL Support that includes your full customization, or ideally a version of it with everything you can remove that still reproduces the issue, that would make things go a lot faster. Please include a sample XML document and the exact steps the user must perform, from opening a document right up until the issue occurs.

« Last Edit: November 22, 2011, 11:48:05 AM by Derek Read » Logged
KdG
Member

Posts: 19


WWW
« Reply #4 on: November 23, 2011, 04:27:50 AM »

Hi Derek,

This can be reproduced with the journalist sample file "CamerasInFocus.xml".

When you execute the script below (simply paste it into the document) the file ends up marked as "not saved".
You can see this from the Save-button in the buttonbar, which appears as active (blue), although the file was saved properly by the script.

// XMetaL Script Language JSCRIPT:
var rng = ActiveDocument.Range;
rng.MoveToDocumentStart();
rng.MoveToElement("Article")
rng.ContainerAttribute("Id") = "ABCD";
ActiveDocument.Save();
ActiveDocument.Saved = true;
Application.Alert("Final status Saved = "+ActiveDocument.Saved)

« Last Edit: November 23, 2011, 04:33:38 AM by KdG » Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #5 on: November 23, 2011, 01:04:52 PM »

Good example. Reproducible here immediately. Thanks.

Looks to me like it is an issue triggered by the "undo after save" feature introduced with 5.x that is the cause.

When you call ActiveDocument.Save() the document is actually being saved, and the status of ActiveDocument.Saved property seems to be set  to true (at least for an instant), however there is a mismatch going on somewhere that causes the Saved property either to not be remembered as true, or that is causing it to be undone. The GUI is only updated when the script is finished running (that's normal) and so by that time the saved state is already wrong (when the toolbar icons are being set for those that indicate status).

I will file a defect report so that dev can look at it.

Immediate fix that should hopefully resolve the issue is to disable the "undo after save" feature with an INI setting or API property. Your users did not have this feature with 4.6 so they might not miss it. These are undocumented as we expected everyone to love the new undo capability and not want to disable it, but since it breaks your script...

The INI setting is this:
always_undo_clear_after_save = true

The API is:
Application.AlwaysUndoClearAfterSave = true
It is probably best called in an application start-up event. You may try setting it in a document-level event too. In either case it disables the undo after save feature for the entire application (for all documents regardless of document type).

I would recommend using only one of the above (you only need one). Because they are undocumented I'm not sure how they interact with each other (which takes precedence). They were likely added because the new undo past save feature was really hard to code and test so dev wanted a way to bypass it in an emergency (which is the case here).
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #6 on: November 23, 2011, 05:40:25 PM »

Looks like these are actually documented in the current XMetaL Developer docs. However, it states that the default value is true, when it is in fact false.
Logged
KdG
Member

Posts: 19


WWW
« Reply #7 on: November 24, 2011, 12:27:11 PM »

Hi Derek,

Disabling the "always undo clear after save" solves the problem indeed.
I will ask the users what they want to lose; the 'undo after save', or the 'do you want to save' message.

You filed a report for the developers. Is there a chance that I will ever hear of an outcome or update?
Iow what can I do to do hear if or when it is solved?

Regards and thanks,
 Kees
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #8 on: November 24, 2011, 03:24:40 PM »

If you file a support case through the regular channels then I can put a note in the defect to contact you if it is resolved. Basically what I need is an email address and company name for that.

You also have the option to check the release notes included with the next release.
Logged
KdG
Member

Posts: 19


WWW
« Reply #9 on: June 26, 2012, 02:13:52 AM »

Dear Derek,

Am I correct that this issue is solved in XMetaL 7?
So AlwaysUndoClearAfterSave=true is not necessary any longer?

(This defect was logged with tracking number PROD00034021)

Regards,
 Kees
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #10 on: June 26, 2012, 10:29:58 AM »

Yes, it was addressed for 7.0.0.103
Logged
Pages: 1
Print
Jump to:  

email us