Hi, today I had some problems with a MultiSelectionDataSetView (maybe the class name is not 100% corretly written - I don't have the IDE at home). I created an ApplicationModel containing a MultipleSelectionDataSetView. Everything worked fine until I testet the behavior I expected when using the keyboard for navigating. The <tab>-key works well, the editor-cell is the next editable cell. But when I tried the <shift>-<tab>-key combination to move backwards I got an error. The view now doesn't know anymore its editcell.
The first workaround I found was inserting a Delay in the DataSetView's method where the error occured. I found out that this error disappeared when I managed to release the <shift>-key before the end of this Delay. Going deeper into the code I found the method "editAt:......:" (sorry, don't know the name of the second parameter) in class MultiSelectionDataSetView. At the end of this method there's a block which is only evaluated when there's no meta key pressed. Within this block the editCell for the view is initialized - so without performing this block the editCell (or is it editorCell) of the view is nil.
My question is: Why is the code in this block only evaluated when no meta key is pressed. I cannot find any (serious) sense to do so. I removed the ifTrue: statement and the code is now evaluated regardless of the state of any meta key. Now it seems to work fine but I fear that I've ignored some important thing which makes necessary that the code within this block is only executed if no meta key is pressed. Can anybody help me (and hopefully tell me that there's really no sense for the ifTrue: statement)?
Andreas Wild wrote: > Hi, > today I had some problems with a MultiSelectionDataSetView (maybe the > class name is not 100% corretly written - I don't have the IDE at home). > I created an ApplicationModel containing a MultipleSelectionDataSetView. > Everything worked fine until I testet the behavior I expected when using > the keyboard for navigating. The <tab>-key works well, the editor-cell > is the next editable cell. But when I tried the <shift>-<tab>-key > combination to move backwards I got an error. The view now doesn't know > anymore its editcell.
[...]
> My question is: Why is the code in this block only evaluated when no > meta key is pressed. I cannot find any (serious) sense to do so.
I have no image started, but guessing I'd say the same code might be used when using the mouse+keyboard for multi-selection (shift-clicking). When multiple elements are selected no selected cell should be editable...
> I > removed the ifTrue: statement and the code is now evaluated regardless > of the state of any meta key. Now it seems to work fine but I fear that > I've ignored some important thing which makes necessary that the code > within this block is only executed if no meta key is pressed. Can > anybody help me (and hopefully tell me that there's really no sense for > the ifTrue: statement)?
Test multi-selection with the mouse with your modification in place...
>I have no image started, but guessing I'd say the same code might be >used when using the mouse+keyboard for multi-selection (shift-clicking). >When multiple elements are selected no selected cell should be editable...
Yup, that's it!
And So It Goes Sames ______________________________________________________________________
Samuel S. Shuster [|] VisualWorks Engineering, GUI Project Go Smalltalk!
>My question is: Why is the code in this block only evaluated when no >meta key is pressed. I cannot find any (serious) sense to do so. I >removed the ifTrue: statement and the code is now evaluated regardless >of the state of any meta key. Now it seems to work fine but I fear that >I've ignored some important thing which makes necessary that the code >within this block is only executed if no meta key is pressed. Can >anybody help me (and hopefully tell me that there's really no sense for >the ifTrue: statement)?
As Reinout said, it is all about mouse vs keyboard. When you are mousing, it comes through the same method as does the keyboard way. The code was written with the impression that it couldn't differentiate between when the user was pressing a Shift or Ctrl Mouse click and a Shifted Keyboard. If you remove that ifFalse: the problem will be that the Shift and Ctrl Mouse clicks will suddenly make fields start being edited... not what was wanted.
A fix would be to have the controller remember if it came to have a Shift or Ctrl from a mouse event or a keyboard event. Not easily done.
My suggestion is to NOT remove that final ifFalse: statement!
And So It Goes Sames ______________________________________________________________________
Samuel S. Shuster [|] VisualWorks Engineering, GUI Project Go Smalltalk!
