This happens because all selections are cleared when a cell enters edit mode. It is difficult to work around this because at the time the BeforeEnterEditMode event fires, the selection has already been cleared, so you can't cache it therein. Furthermore, when the Before/AfterSelectChange events fires, no context is given in the event arguments to indicate that reason the selection is changing, so while you can cache the selection therein, you don't have a cue by which to know whether to ignore that firing.

I vaguely remember hacking around this once but it was messy; I had to do something like handle MouseDown and set a flag to see if that MouseDown triggered both a selection change and an edit mode session, in which case you *assumed* than the selection was changed because of an edit mode session beginning (I don't necessarily recommend you do this).

The best solution to the problem would be freedom of control over whether selection is cleared when an edit mode session begins, or a property added to the BeforeSelectChangeEventArgs class that gives you the reason the event fired, one of the reasons being that an edit mode session is beginning. You might want to log a feature request for this.