[imojenisys]

Closes #1299.

The Object Browser's class, member and search lists named their rows by their view models' type. A row's peer names it by its item's ToString(), and these view models have none of their own. The dump drops a type name, so these rows had no name, select by value couldn't find them, and inspect_element named the selection "ListItem".

OBClassViewModel, OBMemberViewModel and OBSearchResultViewModel now name themselves by their names, as OBLibraryViewModel beside them already does.

Review

One adversarial reviewer, using headless probes and a survey of every ListBox and ComboBox in the IDE.

Finding	Severity	Outcome
The first version also named any unnamed row by the text it shows, but only in the dump; paths, Resolve and select match on the peer's name, so the dump showed a name no tool accepted	Medium-high	Dropped the fallback. No IDE list other than the Object Browser's has this shape. A fallback would have to change the matcher too, and it picked up placeholders, button captions and access-key markers
A selected row scrolled out of view reads Items[i].ToString()	Medium	Fixed for these lists by the ToStrings
Records and generics over framework types slip past the type-name check in a row's name (the Language/Region combos' open rows)	Low-medium	Pre-existing; dropdown selections were fixed in #1288; rows left
OBSearchResultViewModel could name itself with its location to tell same-named hits apart	Low	Kept to the name, which is what a caller selects by; duplicates get [#n] paths as before

The reviewer confirmed that nothing else uses these view models' ToString: logging, sorting and filtering read .Name. No test asserts a type name, and screen-reader names improve too.

Mutation-checked: removing OBClassViewModel.ToString fails the test. Integration 1447 passes.

🤖 Generated with Claude Code