General XMetaL Discussion
KdG November 21, 2011 at 11:32 am
Saved propertyNovember 21, 2011 at 11:32 amParticipants 9Replies 10Last Activity 11 years, 2 months ago
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.
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:
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?
KeesDerek Read November 21, 2011 at 8:00 pm
Reply to: Saved propertyNovember 21, 2011 at 8:00 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).KdG November 22, 2011 at 8:10 am
Reply to: Saved propertyNovember 22, 2011 at 8:10 am
XMetaL Author Essential 6.0 SP1 (XMES 6.0 SP1) Version#: 6.0.2.070
XMetaL Author Essential 5.5 Build No: 5.5.093, Version#: 220.127.116.11
Both show the same behavior.
KeesDerek Read November 22, 2011 at 5:46 pm
Reply to: Saved propertyNovember 22, 2011 at 5:46 pm
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.KdG November 23, 2011 at 10:27 am
Reply to: Saved propertyNovember 23, 2011 at 10:27 am
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.ContainerAttribute(“Id”) = “ABCD”;
ActiveDocument.Saved = true;
Application.Alert(“Final status Saved = “+ActiveDocument.Saved)Derek Read November 23, 2011 at 7:04 pm
Reply to: Saved propertyNovember 23, 2011 at 7:04 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).Derek Read November 23, 2011 at 11:40 pm
Reply to: Saved propertyNovember 23, 2011 at 11:40 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.KdG November 24, 2011 at 6:27 pm
Reply to: Saved propertyNovember 24, 2011 at 6:27 pm
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,
KeesDerek Read November 24, 2011 at 9:24 pm
Reply to: Saved propertyNovember 24, 2011 at 9:24 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.KdG June 26, 2012 at 8:13 am
Reply to: Saved propertyJune 26, 2012 at 8:13 am
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)
- You must be logged in to reply to this topic.