[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [platform-swt-dev] Overrriding default behaviors
- From: "Erik Poupaert" <erik.poupaert@xxxxxxxxx>
- Date: Thu, 20 Feb 2003 17:11:35 +0100
- Delivered-to: email@example.com
- Importance: Normal
>>> I tried it, but it doesn't quite do the trick. AFTER I finish handling
>>> the TrasverseEvent (positioning the combo in the item 0) it does the
>>> default dehaviour, and the combo goes to the item 1.
I think I know why the problem doesn't occur in my grid. When the user
pushes ARROW_DOWN or ARROW_UP, the grid goes to a method
setCell(row+1,column) or setCell(row-1,colum).
There it will destroy the combo anyway:
Control oldEditor = mEditor.getEditor();
if (oldEditor != null)
Then, the new controleditor is created, and it gets the focus. The cell in
the grid that contained the combo hasn't been updated anyway and shows the
old value. So nothing has happened, when the user presses ARROW_UP or
I've also got an Editing flag in my table. If the user has typed any
acceptable keystroke on a particular row, the table goes in Editing mode.
That means that the row selector shows a pen, and also, that a setCell() to
a different row will first trigger the update procedure.
You have this moving of values that you must control tightly: editor
control --> table control --> underlying model. Something goes from the
editor to the table, only after tight verification; and it only goes to the
underlying model after cancelUpdate() and handleUpdate() have returned true.