Skip to main content
March 23, 2009
Answered

error in GUMBO document

  • March 23, 2009
  • 4 replies
  • 1185 views
endCompositeOperation () method
public function endCompositeOperation():void
End a group of operations. Whatever operations were done since the last call to beginCompositeOperation are grouped in a CompositeOperation that is then completed (i.e., added to the undo stack or if we are in a nested composite operation, added to the parent operation).


Example

This code snippet shows how to begin, end, and execute an operations block within an EditManager.

var editManager:IEditManager = SelManager as IEditManager;
var insertPos:int = 15;
var insertText:String = "Hello There";
var insertSize:Number = 48;
editManager.beginCompositeOperation();
SelManager.setSelection(insertPos, insertPos);
editManager.insertText(insertText);
SelManager.setSelection(insertPos, insertPos + insertText.length);
var charFormat:CharacterFormat = new CharacterFormat();
charFormat.fontSize = insertSize;
editManager.applyFormat(charFormat);
var op:FlowOperation = editManager.endCompositeOperation();
editManager.doOperation(op);


endCompositeOperation() return void. i think the above line should be : editManager.flushPendingOperations();
This is for new gumbo build.
Am i correct ?
This topic has been closed for replies.
Correct answer robin_briggs
Yes, you are right, this example is wrong. The API for endCompositeOperation was changed, and the sample code was not updated. It's a documentation bug. endCompositeOperation now executes the operation for you; so it could just read:

var editManager:IEditManager = SelManager as IEditManager;
var insertPos:int = 15;
var insertText:String = "Hello There";
var insertSize:Number = 48;
editManager.beginCompositeOperation();
SelManager.setSelection(insertPos, insertPos);
editManager.insertText(insertText);
SelManager.setSelection(insertPos, insertPos + insertText.length);
var charFormat:CharacterFormat = new CharacterFormat();
charFormat.fontSize = insertSize;
editManager.applyFormat(charFormat);
editManager.endCompositeOperation();

4 replies

Adobe Employee
March 25, 2009
This is good information. So you have FlowOperations that don't actually change the TextFlow at all, but are still undoable operations?

One change I've made recently, which will be coming through in Gumbo when they update, is that FlowOperation.doOperation() now just returns a Boolean. Turns out we were only looking at whether the result is null or not. If the operation is unsucessful, it will not be placed on the undo stack, but you will still get a FlowOperationEnd event for it. I hope this doesn't get in the way of what you're using it for.

Knowing a little more about our clients are using the APIs is very helpful when we're considering changes -- the better we understand it, the less likely we are to cause problems for you. Thanks to you both for taking the time to explain.

- robin
March 26, 2009
Hi, Robin.

I like the Boolean return idea for the operations. That will definitely come in handy. And yes, I do have operations that do not modify a text flow at all. Often I'm modifying both the text flow and objects outside of TLF. I'm basically just ignoring the textFlow related properties of the operation base clases and implementing execute and undo/redo. We have some plans in the works to expand on our operations also. (it's been working well so far) I will try to revisit the operations I have in place now in the next week or so and maybe provide you with a little more feedback. I seem to remember feeling like the base classes or interface for the operations could be a little more abstract, and that you could move some of the text specific base properties to an in-between class that the existing TLF operations could extend instead. I'd have to take a closer look to say for sure exactly what I was thinking about at the time.

--Brent
March 24, 2009
especially when to replaceText in many places at once.
March 24, 2009
Regarding composite operations, we are using those fairly heavily right now. We are extending EditManager and have created several custom operations. The composite operation behavior has been extremely useful in providing the ability to group a set of operations into one undo/redo step. Also, some of our operations perform actions on sets of objects that we are running in parallel/on top of TLF classes and text flows.

We have cases where we're overriding doOperation in our EditManager descendent, checking the type of operation, and sometimes start a composite operation, do the TLF operation, and then do a few extra operations that we want to coincide with the TLF operation. This has proven to be very effective for some things like tables, custom 'overlay' positioning, etc.

Also, we are using the id properties for flow elements, and we have been starting to hook into the operation behavior to help establish id's when paragraphs are split, or groups of elements are copied and pasted, etc. We want to check to make sure we have all unique ID's and add one or more change element id operations to certain operations being performed if necessary.

I would be happy to discuss some of this behavior more if you would like more input. I haven't run into too many things in this area that I have not been able to do, and it's definitely been one of the easiest areas of TLF to tap into. I can't remember the details at the moment, but I remember running across a few details that I wished were different about the two base classes for operations. I'd have to revisit that to be more specific.

Thanks!
--Brent
Adobe Employee
March 24, 2009
One thing I'd like to ask -- are you finding that composite operations are helpful? We added them somewhat speculatively,and if they are useful, I'd be interested in finding out more about what you are using them for. Are you writing your own custom operations?

Thanks!
March 24, 2009
i am writing text editor so i need to manipulate text on some events programmatically. Operations help to do that in batch. That's all. I do not want to do add/remove flowelement manually.

thanks for answer.
robin_briggsCorrect answer
Adobe Employee
March 24, 2009
Yes, you are right, this example is wrong. The API for endCompositeOperation was changed, and the sample code was not updated. It's a documentation bug. endCompositeOperation now executes the operation for you; so it could just read:

var editManager:IEditManager = SelManager as IEditManager;
var insertPos:int = 15;
var insertText:String = "Hello There";
var insertSize:Number = 48;
editManager.beginCompositeOperation();
SelManager.setSelection(insertPos, insertPos);
editManager.insertText(insertText);
SelManager.setSelection(insertPos, insertPos + insertText.length);
var charFormat:CharacterFormat = new CharacterFormat();
charFormat.fontSize = insertSize;
editManager.applyFormat(charFormat);
editManager.endCompositeOperation();