> I think I might have misunderstood your reasoning about #1? If my logic > determines that there should be no transition when the editor is closed, and > I choose to set the immediate flag on endEdit(), then I shouldn't be > surprised when no transition occurs! :)
I just meant that this solution would prevent the use of a transition in this case. For example, I may still want to run a transition when switching the editor to the next row, and I wouldn't be able to if we use an "immediate" flag. However, another option occurred to me that I think might work better. In fact, it actually occurred to me way back when I first made the changes to the editor APIs, but I forgot about it. :-) Using this approach, we can actually go back to simply using edit() and drop isEditing() and endEdit(). The idea is to leave it to the implementation of edit() to determine what to do when an edit is already in progress. For example, if I call edit() and the editor is not currently active, we open() the window and position it over the selected row, beginning the edit. Opening the window may execute a transition, which we want. Later, if edit() is called again while the editor is open, we simply reload its contents with the new data and reposition it over the new row. Finally, when the edit is complete, we close() and run the closing transition. This approach keeps the editor API simple but still offers the caller and/or editor implementor some control over how to handle this case. What do you think? G
