Mantis Bugtracker
Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Advanced Details [ Jump to Notes ] [ View Simple ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0007096 [Squeak] Morphic minor always 06-16-08 04:31 06-18-08 00:41
Reporter Ross View Status public  
Assigned To
Priority normal Resolution open Platform
Status new   OS
Projection none   OS Version
ETA none Fixed in Version Product Version 3.10.1
  Product Build
Summary 0007096: PluggableListMorph>>mouseUp: sets index to 0
Description I'm not sure about the "minor;" this problem results in an exception being thrown, and the fix is probably non-trivial given the history of these methods. It is fairly easy to work around the problem in the code of the model for the PluggableListMorph. It seems to me, however, that the model should not be receiving indices of 0 in the first place.

I clicked on a row that was already selected and got an error because of an attempt to access my model list at index 0. I *did* want the selection to be communicated back to the model; the row was selected by default, and the user click indicated it was the right selection.


PluggableListMorph>>mouseUp:
mouseUp: event
        "The mouse came up within the list; take appropriate action"
        
        | row mdr |
        row := self rowAtLocation: event position.
        event hand hasSubmorphs ifFalse: [
                mdr := self mouseDownRow.
                 self mouseDownRow: nil.
                mdr ifNil: [^self]].
        (self enabled and: [model okToChange])
                ifFalse: [^ self].
        "No change if model is locked or receiver disabled"
        row == self selectionIndex
                ifTrue: [(autoDeselect ifNil: [true]) ifTrue:[row == 0 ifFalse: [self
changeModelSelection: 0 "!!!!"] ]]
                ifFalse: [self changeModelSelection: row].
        Cursor normal show

I marked the spot with "!!!!". This leads to the index setter being
called with argument 0 on the underlying model, which produces an error.


The PluggableListMorph (actually, PluggableListMorphPlus, but that's not
where the method is implemented) was built by ToolBuilder.
Steps To Reproduce
Additional Information There have been several bugs about the double-click behavior of items in lists, and various code changes as a result. The implementation of doubleClick: explicitly tests for an index of 0. Note that I was not double-clicking and not interested in the double-click behavior.

I'm using Damien's sq3.10-7159dev08.06.1.zip.

doubleClick: is
ls 5/16/2001 22:28 ¥ PluggableListMorph ¥ events ¥ 6 implementors ¥ in no change set
according to OB, and

mouseUp: is
gvc 8/7/2007 12:45 ¥ PluggableListMorph ¥ *Pinesoft-Widgets-override ¥ 53 implementors ¥ only in
Attached Files

- Relationships

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

related to 0005630new  It's impossible to deselect in the Browser class list pane 
related to 0001347closed  Doubleclick on list entries not working properly 
related to 0002452closed MarcusDenker For double clicking on entrys to work properly, Inspectors and Browsers must explicitly disable autodeselect. 
related to 0000976closed gokr [ENH] autoDeselectInSMLoaderCategoryPane-sjjb 

- Notes
(0012303 - 1483 - 1627 - 1627 - 1627 - 1627 - 1627)
wiz
06-18-08 00:41

 Hi Ross,

Thanks for mentioning the sources in question.
The one I mucked with came before Gary's Pinesoft efforts.

The current situation and spec it that PLM>>mouseUp: will not pass along a reselection to the model.

0 represents the state of nothing selected and is what is expected to be the default. (So that when a selection is made it will be reported.)

autoDeselect true (the default) reports the second selection of an item as a deselection.

autoDeselect false (you have to set this) does not report a reselection to the model only a change of selection.

Clicking down on a list item and then moving the mouse off the list may result in the detection of 0 (deselection). Also clicking on a blank row below the list may have this effect also.

What you wish to do, preselect a row then click on it will result in a deselection being sent to the model (autoDeselect = true ). or no notification to the model of a selection change at all (autoDeselect = false). So the current behavior calls for the list to be unselected at first and then it will notify the model of any change in selection.

The change may include a transition from selection to deselection.
Initial deselection insures that the first change will not be a 0.

The change that Gary made seems to add more filtering to the logic above the part that I described. Since I haven't studied that fully I can't say what it is doing there.

Yours in curiosity and service, Jerome Peace
.
 

- Issue History
Date Modified Username Field Change
06-16-08 04:31 Ross New Issue
06-17-08 23:53 wiz Relationship added related to 0005630
06-17-08 23:54 wiz Relationship added related to 0001347
06-18-08 00:05 wiz Relationship added related to 0002452
06-18-08 00:06 wiz Relationship added related to 0000976
06-18-08 00:41 wiz Note Added: 0012303

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
51 total queries executed.
37 unique queries executed.
Powered by Mantis Bugtracker