General XMetaL Discussion
XMetaL Community Forum › General XMetaL Discussion › Join multiple changes into a single change/update event in XMetaL Author
-
Progresso March 5, 2010 at 3:56 pm
Join multiple changes into a single change/update event in XMetaL Author
March 5, 2010 at 3:56 pmParticipants 3Replies 4Last Activity 12 years, 11 months agoProduct: XMetaL Author 4.6.12.152 SP2
OS: Windows XP Professional SP3, EnglishHi,
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 onceIs 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
BoP.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.
Derek Read March 9, 2010 at 12:40 am
Reply to: Join multiple changes into a single change/update event in XMetaL Author
March 9, 2010 at 12:40 amIf 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).
dcramer March 9, 2010 at 2:27 am
Reply to: Join multiple changes into a single change/update event in XMetaL Author
March 9, 2010 at 2:27 amWhen does the current version (6.0) come out again? That sentence hurts my head 😉
Derek Read March 9, 2010 at 5:47 am
Reply to: Join multiple changes into a single change/update event in XMetaL Author
March 9, 2010 at 5:47 amAh, 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
Progresso March 19, 2010 at 12:02 am
Reply to: Join multiple changes into a single change/update event in XMetaL Author
March 19, 2010 at 12:02 amThank 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 -
AuthorPosts
- You must be logged in to reply to this topic.