PluggableMultiColumnListMorph>getListItem:

The SoundLibraryToolMorph breaks if you try to get the yellow menu.

The root cause is likely to do with the amazingly convoluted pile of code that gets run to try to add menu options from every morph in the entire universe, whether related to the tool or not. That appears to be something to do with EToys but I don’t know and don’t much care. Just take a look at Morph>yellowButtonActivity: And maybe Morph>allStringsAfter:

The lower level issue is that the #getListItem: code pays no attention to the way that the list is actually a list of lists that contain (supposedly) related items and so asking a list of 2 list of 18 entries for the 4th entry will never really work out well. I was about to try out a fix for that when I noticed that the code seems to be unable to make up its mind whether the list is of actual objects that will be used later or simply pre-cooked strings. Should this return a collection of each entry in the corresponding row, like #getListRow:, or a list of string for each of those, or a string composited from those? Does anyone know what this is *meant* to do?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His seat back is not in the full upright and locked position.

Hi Tim,

"Instead of"

rows := #(
        ( 1 2 )
        ( Brooks Robert )
        ( Brooks Victoria )
        ( Burton Geraldine )
        ( Chason Rhoda )
        ( Chason Robert )
        ( Chung Bernard )
        ( Holder Crystal )
).

"PluggableMultiColumnListMorph needs"

columns := #(
        ( 1 Brooks Brooks Burton Chason Chason Chung Holder )
        ( 2 Robert Victoria Geraldine Rhoda Robert Bernard Crystal )
).

morph := PluggableMultiColumnListMorph
        on: columns
        list: #value
        selected: nil
        changeSelected: nil.

window := PluggableSystemWindow
        labelled: 'PluggableMultiColumnListMorph'.

window
        addMorph: morph
        fullFrame:
                (LayoutFrame
                        fractions: (0@0 corner: 1.0@1.0)
                        offsets: (0@0 corner: 0@0)).

window openInWorld.



Best Regards,

Milan Vavra

Oh, I know that part ok; the SoundLibraryTool list is a pair of collections wrapped in a collection, so we’re not getting it wrong there.

The problem starts in #yellowButtonActivity: where #buildYellowButtonMenu: starts going after nested menu items and that leads to Morph>allStringsAfter: which as Yoda would say “leads to paaaaaiiiiin”
If you try it out you’ll see how it goes; and the problem is what should a multi-column list return for #getListItem: ? Once you start looking at that you notice that the result is being used in a way that assumes string-ness in some places and not in others. See, for example PluggableListMorph>getListItem: and follow back through what might be in the ‘list’ ivar, or the result from #getList, and indeed from the model perform: … stuff which is forced to string-ness.

The simplest answer I can think of - and it’s a long way from a proper, well thought out solution - is to over-ride #getListItem: and return the relevant item from just the first list. This avoids concerns about what composite items might exist and how to present it.

And all this simply gets thrown away! The menu code is just building that entire complex of morph userStrings to see if it is empty! And it only even happens if your image has the ridiculous ‘generalizedYellowButtonMenu’ preference enabled, which surely must be one of the least  options I’ve ever seen.

I suspect that some thought about the proper use of the userStrings concept might be useful here. Is it really sensible for a morph representing a list of items to provide a potentially huge string concatenating the content of each list item?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MII: Mask all Interrupts and then Interrupt