General XMetaL Discussion

  • KdG

    Saved property

    Participants 9
    Replies 10
    Last Activity 10 years, 10 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.

    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

    Reply

    Derek Read

    Reply to: Saved property

    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).

    Reply

    KdG

    Reply to: Saved property

    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

    Reply

    Derek Read

    Reply to: Saved property

    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.

    Reply

    KdG

    Reply to: Saved property

    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)

    Reply

    Derek Read

    Reply to: Saved property

    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).

    Reply

    Derek Read

    Reply to: Saved property

    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.

    Reply

    KdG

    Reply to: Saved property

    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

    Reply

    Derek Read

    Reply to: Saved property

    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.

    Reply

    KdG

    Reply to: Saved property

    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

    Reply

    Derek Read

    Reply to: Saved property

    Yes, it was addressed for 7.0.0.103

    Reply

  • You must be logged in to reply to this topic.

Lost Your Password?

Products
Downloads
Support