Open GoogleCodeExporter opened 9 years ago
It turns out it's not as simple as processing the undo/redo events when isLocal
is true because we don't know which events are the result of an undo/redo.
Original comment by ma...@google.com
on 6 Feb 2014 at 1:15
I've done it in other Realtime projects by just setting a flag, e.g.
var fromUndo = false;
In the call from the GUI:
fromUndo = true;
model.undo(); (or redo();)
In the event listener:
if(isLocal && fromUndo) {
(update Blockly)
fromUndo = false;
}
Not pretty, but it's worked fine so far. Remote events won't remove or be
affected by the flag, so there shouldn't be a race condition unless the event
bubbling is so slow that the user has time to trigger another local event.
Original comment by dinin...@gmail.com
on 6 Feb 2014 at 5:43
Unfortunately, the flag setting technique doesn't work if you use compound
realtime operations, since the undo (or redo) method may trigger multiple
events. In that case, you can't just reset the flag on the first 'fromUndo'
event you see.
Original comment by ma...@google.com
on 6 Feb 2014 at 6:20
Original comment by ma...@google.com
on 14 Feb 2014 at 12:25
You can surround the undo/redo call with a try-finally block that sets and
resets the flag. This works because the realtime API guarantees that all the
undo/redo generated events will come within the execution of the undo/redo call.
Original comment by ma...@google.com
on 14 Feb 2014 at 12:28
This issue was updated by revision r1637.
We're getting closer to undo/redo support. There are
still some issues around atomicity of undo which can be fixed with
either a change in how the underlying Google Drive Realtime compound
operations work or by doing some explicit modeling of the undo stack
by our code.
R=neil.fraser@gmail.com
Review URL: https://codereview.appspot.com/66170044
Original comment by ma...@google.com
on 21 Feb 2014 at 7:33
Original issue reported on code.google.com by
ma...@google.com
on 23 Jan 2014 at 6:39