Deleting a Control in LC8 DP16 in the IDE

[J. Landman Gay]

On 3/29/2016 8:43 PM, Mark Wieder wrote:
> On 03/29/2016 06:31 PM, Paul Hibbert wrote:
>> Bill,
>>
>> There is a ‘Trash’ icon in the bottom row of tools in the PB, the only
>> downside is it asks for confirmation before deleting, or you can
>> double click the control in the PB, it should be selected if the card
>> is visible, then you can hit delete.
>
> Yeah, be *very* careful with that, though... I have several times now
> deleted the wrong control thinking that it was selected just because it
> was highlighted. Er... hilited. Anyway, there's no "undo" option, so
> save your work before attempting this.
>

The hiliting in the PB is confusing and it's hard to tell what you will 
be operating on. I would like to see all selected objects hilited the 
same way and the dotted outlines eliminated entirely. It's far too easy 
to ruin a stack because of the current confusion.

To distingush between objects on the current card of the topstack and 
objects elsewhere, I have two ideas:

Method 1: Have the non-current objects hilited in light gray and have 
the current ones in the topstack hilited in the normal hilite color. The 
color difference provides a visual indication that you will be operating 
on objects in disparate locations. But regardless of the hilite color or 
object location, all the hilited objects should respond to the user's 
edits or deletions whenever possible.

Method 2: Hilite all objects, regardless of location, with the same 
hilite color. If an action is specified that isn't appropriate for 
disparate objects, either operate only on the current card, or put up a 
dialog explaining why the operation can't be completed. Or both -- put 
up a dialog asking if the user wants to operate on only the current card.

I think this is important. I have never seen two types of selections 
anywhere else and the meaning is not intuitive. Users will expect all 
selected objects to respond to any action whenever possible and they 
won't know how to distinguish between the types. Even with documentation 
(which few really read) the meaning of the outlined selections is 
confusing and hard to remember.

For alignments, the icons at the bottom should probably be disabled if 
all the selected objects aren't on the same card. Alternately, put up a 
dialog that explains why the action can't be completed and ask if it 
should be applied only to the current card. The same for the group icon, 
which should be disabled (or dialoged) if all selections aren't on the 
same card. There may be others that need special treatment. For example, 
the Delete icon should probably include a warning about deleting 
non-current objects if any are selected, and provide a way to cancel out.

The main idea here is to treat all types of object selections similarly 
and not force the user to remember and distinguish between types. Even 
after you know how it is supposed to work, the non-standard behavior 
still induces errors. We are creatures of habit.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com