[Solved]Object Inspector multi select bug

[Tony Stone]

In Lazarus Lazarus 4.99 (rev main_4_99-44-g2d7ef84dab) FPC 3.3.1 x86_64-linux-gtk2 I think I found a bug with the object inspector.  Unless I am missing something obvious?


To reproduce drop 3 TPanels on a form, some TMemos maybe and that should be enough to reproduce this I think.  In the object inspector I select the 3 TPanels USING THE CTRL+CLICK and all of the properties show still because the 3 selected items have the same properties.

HOWEVER when I select the same 3 TPanels using Shift+Click it shows about half of the properties!  I will file a bug report but I want to make sure this isn't some intended behavior.  Let me know please if you see the same issues?

[Joanna from IRC]

That’s interesting, could it be the properties that they have in common? I think I tried something like this a long time ago. I’m curious what the properties shown are.

Also you might have a typo ->big instead of bug?

[Tony Stone]

Like I said just try it.  See if YOU SEE the same issue I am seeing if you don't mind.  When selecting using ctrl-key it shows ALL of the properties in common(which in this case is all properties since it is 3 objects of the same type).  But when selecting multiple items of the same type with the shift key it is not including all of the properties such as bevel and many others.  So I mean B. U. G. if this is not in fact expected behavior.  I am strugling to see why it would be expected.  I will test it on my Windows machine and see if it does the same thing.


Just checked on my windows machine and it also behaves odd like this.  Unless I am missing something obvious it is supposed to be doing different when doing multi select with shift vs ctrl.

[Martin_fr]

Using 4.99 with 3.2.3 / Win 10 64 bit: I can not reproduce.

In the OI component tree the 3 panels are on top, and below that are the memos (the memos are on the form, not in any of the panels).

I can use
- ctrl in the OI-tree to select (3 clicks)
- shift in the OI tree to select (2 clicks, 2nd with shift)
- shift on the designer (3 clicks)

And I see all properties.


Of course if a memo has one of the panels as parent, and is listed inside that panel, and I use shift in the OI-tree, then that memo gets selected. (Except if the memo is inside the last panel in the list).

[Martin_fr]

OK, on Linux, even if I use ctrl: something goes wrong.

Some rows are not painted correctly

[Martin_fr]

I retested on Windows. If I multiselect (in any way), then the "name" property is no longer shown => IMHO expected.

[Martin_fr]

@Tony, maybe check if it is a paint issue? After the selection, when you don't see the properties, resize the OI (change height and width). See if that make a diff.

[Tony Stone]

@Tony, maybe check if it is a paint issue? After the selection, when you don't see the properties, resize the OI (change height and width). See if that make a diff.

I'm surprised you are not seeing what I'm seeing because I am seeing the issue also on my windows laptop with it bit of an older version of Lazarus. When I get home I will mess around a little bit and try what you suggested.

[Tony Stone]

Of course if a memo has one of the panels as parent, and is listed inside that panel, and I use shift in the OI-tree, then that memo gets selected. (Except if the memo is inside the last panel in the list).

Ok I see what you are saying, with shift+click range it is also selecting child items!  I didn't realize it was selecting the chold items which are collapsed in the view!  I see... SOOOO... this is NOT really a bug exactly.  But I think it is unexpected behavior.  It should not be selecting items that are collapsed when using the shift key to select a range.  The fact it took me 2 days to realize the "issue" says it is unexpected and likely undesired behavior!  lol  But I can see it both ways.... hmmm

[Tony Stone]

OK, on Linux, even if I use ctrl: something goes wrong.

Some rows are not painted correctly

Ok I am not seeing the paint issue. I will try to make that happen on my end here.

Tried to get a paint issue like you are seeing and no matter how i sized things it never happened.  Paints perfect everytime...

And always shows the proper properties now that I understand it was selecting child controls too.  This probably explains odd changes to properties I have experienced in the past where I later find something changed and I am like "whoops, must have changed that one by mistake" 

[Tony Stone]

Just occurred to me too that maybe when doing range select it should automatically expand the collapsed items so the user clearly sees there is many other items selected?

No I changed my feelings on this again!

When it comes to selecting items in a tree view, my stance is pretty straightforward: if child items are collapsed, they shouldn't be selected when I'm doing a range selection (Shift + Click). It just makes sense that if I can't see those child items, they shouldn't get selected automatically—it's like selecting something behind my back. But if the children are visible, then yes, they should be part of the range selection, because that’s what I can see and what I expect to interact with.
Control + Click works fine for me, regardless of whether the children are visible or collapsed—since it's meant for precise, individual selection, it should keep working the way it does. But for Shift + Click, I think it’s all about sticking to what’s visible to avoid surprises and make sure the interface feels intuitive.