On May 13, 2008, at 6:21 PM, David Barrett wrote: > True, but even an application would need to "undo" in transactions, > I'd > think. Like, if a user drags a widget from column A to B, it > generates > an INSERT in one column and a DELETE in another. Pressing Undo once > would leave it in both columns, which is probably unexpected. >
And undo/redo mechanism typically groups actions together by user input event. The application is typically event driven. It sits idle waiting for a user event, such as a mouse click. That event might trigger a cascade of related events, some of which involve database changes. All database changes associated with that one event are undone together. You know that you have reached the end of your event cascade when the event loop goes idle again. For processing gestures (drags, and other inputs that involve multiple events spread out over time) you acquire a lock or a "grab" at the beginning of the gesture, hold it throughout the gesture, then release it when the gesture completes. You do not finish the undo package until the end of the gesture. So the complete rule for when you stop one undoable entry and start a new one is: you are idle (no pending events) and you are not holding a grab. D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
