Deleting a Control in LC8 DP16 in the IDE
J. Landman Gay
jacque at hyperactivesw.com
Wed Mar 30 06:41:23 CEST 2016
On 3/29/2016 8:43 PM, Mark Wieder wrote:
> On 03/29/2016 06:31 PM, Paul Hibbert wrote:
>> 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
More information about the use-livecode