General XMetaL Discussion

XMetaL Community Forum General XMetaL Discussion Join multiple changes into a single change/update event in XMetaL Author

  • Progresso

    Join multiple changes into a single change/update event in XMetaL Author

    Participants 3
    Replies 4
    Last Activity 12 years, 6 months ago

    Product: XMetaL Author 4.6.12.152 SP2
    OS:  Windows XP Professional SP3, English

    Hi,

    In XMetaL Author 4.6 we use a 'document macro' to perform a custom made function that changes the document many places in one go.  For instance, a 100 different XML elements in one go.

    Unfortunately, this has two bad effects:
    – the document panel (Tags On view) flickers for quite a long time
    – if the user wants to undo the action he/she needs to repeat undoing a 100 times (!) instead of just once

    Is there a way that these effects can be avoided?

    That is, I need to group these multiple changes into a single change/update event.  Like temporarily setting a “PostponeUpdate” flag as it is possible in various other programming environments.

    I have tried to make the changes directly in the DOM tree instead of through ActiveDocument.Range etc., but this makes no major difference.

    Any ideas will be much appreciated.

    Thanks
    Bo

    P.S.:  In case the problem cannot be solved now in version 4.6 I would like to know if it can be solved in in version 5.x/6.x.  I should report this to my client, since they will upgrade to the newest XMetaL version at the end of 2010.

    Reply

    Derek Read

    Reply to: Join multiple changes into a single change/update event in XMetaL Author

    If your script is inside an MCR file contained within a single macro then all actions performed will be undone with one Undo action (ie: Ctrl+Z) by the user. Perhaps you have run into a similar issue to the one reported here: http://forums.XMetaL.com/index.php/topic,550.0.html

    Your issue with flickering is typically caused by the use of the Selection object. We provide a similar object called Range which shares almost all the same properties and methods but has two major advantages:

    1. There can only ever be one Selection object (it represents the user's 'real' selection), whereas you can have as many Range objects as you like.

    2. The Selection object is always visible (ie: when you move it you are moving the user's 'real' selection) and it is always interacting with the document directly and visibly, whereas for the most part (except for specific properties and methods like Range.Select and when content is being inserted) Ranges are invisible.

    If you feel you must use Selection, or where you do use Ranges but manipulations to the document are still rendered to the user during the running of your script (and you see flickering) you may work around this using the ActiveDocument.FormattingUpdating API to turn off updates to the document for a portion of a particular macro. Following example us from the Programmer's Guide:

    ActiveDocument.FormattingUpdating = false;
    // ... many operations requiring formatting updates
    ActiveDocument.FormattingUpdating = true;

    You must be careful that your script is always able to complete to the point where this API is set back to true within the same macro, otherwise, “formatting updating” will stay turned off for that document and unpredictable behavior may also occur. Basically what this means is that you cannot set this API to false in one macro and then turn it back on in a different macro or a subsequent run of the same macro, and if a macro terminates prematurely due to a runtime error you will have a similar problem (so test for possible causes of failure using “if” and / or “try…catch” or the equivalent in the scripting language you are using).

    Yet another alternative is to build up a tree of DOM nodes (contained within one node) then insert that single node at the end of your script.

    FYI: The 4.x releases of our products are no longer supported. We support the current release (6.0) and one full release back (5.0).

    Reply

    dcramer

    Reply to: Join multiple changes into a single change/update event in XMetaL Author

    When does the current version (6.0) come out again? That sentence hurts my head 😉

    Reply

    Derek Read

    Reply to: Join multiple changes into a single change/update event in XMetaL Author

    Ah, yes. To clarify this a little more:

    XMetaL Author Enterprise 6.0 has been released and has been shipping for several months.
    XMetaL Author Essential 6.0 is coming (very soon).

    So, I suppose because there was no “XMetaL Author [u]Enterprise[/u] 4.6”, the closest thing to “XMetaL Author 4.6” today would be “XMetaL Author [u]Essential[/u]”, which means we may still be supporting the 4.6 release for a few more weeks, because “XMetaL Author [u]Essential[/u]” is not yet shipping.

    At which point it probably would be good to clarify which is which in case this information is not easy to find in our marketing stuff: http://forums.XMetaL.com/index.php/topic,681

    Reply

    Progresso

    Reply to: Join multiple changes into a single change/update event in XMetaL Author

    Thank you Derek,

    Your reply helped me a lot.

    I have now changed the code thus grouping multiple events into a single undoable action inside a single macro.

    In a couple of places I needed to control the flickering with ActiveDocument.FormattingUpdating=false/true

    All this was resolved neatly, with only one remaining problem:

    When I prompted the user with Application.Confirm() before performing a large number of DOM modifications, the processing became MUCH slower than without the prompt.

    It seems like the mere appearance of a modal dialog creates problems.

    I solved the problem by creating an XFT window with yes/no buttons, and performing the large number om DOM modifications from within the window.

    Best regards
    Bo

    Reply

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

Lost Your Password?

Products
Downloads
Support