The problem is that there is no universal solution that handles all cases.
Picture the person navigating with the keyboard instead of the mouse, as I do
much of the time. As I use the arrow keys to navigate from cell to cell in
your grid, I certainly do not want checkboxes checking and unchecking
themselves, nor combo boxes automatically popping down, while I am navigating.
I need to take some second action to actually cause editing. That first mouse
click is equivalent to moving in to the cell with an arrow key: it is a focus
selector, not an action selector.
···
On Wed, 28 Aug 2002 07:20:39 -0700, "Steve Holden" <sholden@holdenweb.com> wrote:
Is it only me, or does the wxGrid behavior seem a little perverse?
I click once on a cell in the "Severity" column and it's selected. Only when
I click agaion does it become a pulldown, and I have to click a third and a
fourth time to actually select anything.
I click on a checkbox, the cell selects, and I have to click a second time
to change the checkbox's state. This isn't what I'd call "ease of use".
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
Let's see if we can come up with some more-or-less universal semantics:
EVT_GRID_CELL_LEFT_CLICK -> if not drag (yes, that's annoying to figure out) and not Shift-down or Ctrl-down, then start editor, pass the mouse event to "StartingClick" of the appropriate editor instance. Set selector regardless.
EVT_KEYBOARD_MOVE -> don't start editor, just set selector
EVT_KEYBOARD_NONMOVE -> start editor unless otherwise handled and call StartingKey (which is basically what happens now)
EVT_KEYBOARD_F2 -> start editor explicitly, w/ no initial key event (choice of F2 is based on Lotus and Excel, should be re-configurable, of course), basically catch the keyboard event and call ShowCellEditControl() on the grid instance.
The effect of this is to eliminate the mouse-based selector action in favour of auto-triggering the editor in those cases. Is this a problem? I don't really think so, but it might be best to make it a style or attribute-controlled distinction so those wanting mouse-based single-cell selectors can use that mode of operation (there are a few cases where this is the most natural mode of operation in my systems, BTW).
I'm guessing you could even do it without rewriting anything at the grid level save for distinguishing between selection and click events? Don't have time to play with it just now, but seems doable.
As a note, it becomes more difficult to "stop editing" the grid. Basically everywhere you click in the grid will start editing something, so you're almost always going to have a control active. Potentially making a click-while-editor-visible different than click-while-editor-not-visible would be another usefully parameterised effect.
Enjoy yourselves,
Mike
Tim Roberts wrote:
···
On Wed, 28 Aug 2002 07:20:39 -0700, "Steve Holden" <sholden@holdenweb.com> > wrote:
Is it only me, or does the wxGrid behavior seem a little perverse?
I click once on a cell in the "Severity" column and it's selected. Only when
I click agaion does it become a pulldown, and I have to click a third and a
fourth time to actually select anything.
I click on a checkbox, the cell selects, and I have to click a second time
to change the checkbox's state. This isn't what I'd call "ease of use".
The problem is that there is no universal solution that handles all cases.
Picture the person navigating with the keyboard instead of the mouse, as I do much of the time. As I use the arrow keys to navigate from cell to cell in your grid, I certainly do not want checkboxes checking and unchecking themselves, nor combo boxes automatically popping down, while I am navigating. I need to take some second action to actually cause editing. That first mouse click is equivalent to moving in to the cell with an arrow key: it is a focus selector, not an action selector.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
I'm dealing with run-of-the-mill errors that happen in a database-driven app. For example, a user updates a value in the grid, but the table base's setvalue comes back with an exception.
So far, it seems that the wxWindows app doesn't crash on an unhandled exception. It actually behaves pretty well. But: 1) I don't know if I can count on this behavior, and 2) I want to provide good user feedback.
It looks though, like I'll have to put my exception handling code in the table base, which I don't like; To my way of thinking, it shouldn't have anything to do with view-related features. Anyone have a way of handling this that they like?
I'm dealing with run-of-the-mill errors that happen in a database-driven
app. For example, a user updates a value in the grid, but the table
base's setvalue comes back with an exception.
So far, it seems that the wxWindows app doesn't crash on an unhandled
exception. It actually behaves pretty well. But: 1) I don't know if I
can count on this behavior, and 2) I want to provide good user feedback.
In general, things won't get any worse than they are now <wink>
It looks though, like I'll have to put my exception handling code in the
table base, which I don't like;
wxPython apps often have several layers of C++ --> Python --> C++ --> Python
calls, and as such it is difficult to reliably get Python exceptions up
through the layers of C++. So it is best to handle exceptions in the same
layer of Python where they happen.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!