How to stop LoveCode running in Edit mode

[Richard Gaskin]

Keith Clarke wrote:

 > There’s nothing special about the stacks that misbehave for me on
 > LiveCode 8.1.0 - right-clicking buttons in Browser/Edit mode that
 > just have simple mouseUp handlers exhibit regular Pointer/Run mode
 > behaviour instead of (not even in addition to) expected edit
 > behaviour. It’s as if the mode switch is ignored by the IDE - even
 > saved stacks opened in edit mode behave as if the IDE is switched to
 > Run.

LiveCode has no edit mode per se.  The only xTalk I've seen with a true 
edit mode is SuperCard, in its companion application SuperEdit.  All the 
rest have the script interpreter running, allowing many different object 
properties and global properties to define and refine the experience.

Like HyperCard, LiveCode has a "button tool" and a "field tool", as well 
as a "browse tool", and like SuperCard LiveCode has a "pointer tool" so 
interactively working with objects.

This is a subtle distinction but not merely semantic.  If we consider 
the actual scope of the various properties in play, things that may seem 
mystifying can become clear.


In addition to the "tool" global property, two object properties may 
contribute to an experience such as you describe:

The "cantSelect" control property will prevent a control from being 
interacted with when the global "tool" property is set to "pointer 
tool".  Instead, regardless of what the global "tool" property is set 
to, when the "cantSelect" of a control is true the object will always 
behave as though the "tool" global property is set to "browse tool".

Confounding matters, the Project Browser provides a lock icon next to 
the eye icon, but while the eye icon governs visibility as we commonly 
see in other apps, the lock icon is used in many other apps to govern 
whether an object can be moved (what we would consider the "lockLoc" 
property), but in the IDE it's used for "cantSelect".

In brief, you may want to double-check the state of the "cantSelect" 
property on any control that behaves as though the "tool" global 
property is set to "browse" when in fact that global property is set to 
"pointer".

If the behavior you're seeing is affecting all objects within a stack, 
you may want to check the stack's "style" property.  The "pointer tool" 
will only affect stacks open as toplevel, which allows us to have 
palettes, dialogs, and even other modeless auxiliary windows which are 
unaffected by the current tool mode.

If you were to set a stack's style to "modeless", for example, its 
layering and other behaviors would be the same as toplevel, but it would 
be immune to changes in the "tool" global propety.

The "style" property is persistent, allowing you to set it once and then 
anytime you open the stack with "open" or "go" it retains the specified 
mode.

You can also open a stack temporarily in any style by using that style 
name as a command, e.g.:

    modeless "MyStack"

When using the command form of a stack style the "style" property of the 
stack remains unchanged; to determine the mode of a stack regardless of 
how that mode was arrived at check the "mode" property, e.g.:

   put the mode of stack "MyStack"

Modes are integers rather than style names, which may seem off-putting 
at first but makes sense as you learn more about them since they allow 
us to learn of modes that aren't settable as the stack"s "style" 
property, such as "cantModify".

Rarely used in a language that has "modeless" as a style, "cantModify" 
is similar in behavior, causing the stack to treat all mouse 
interactions as though the current tool is "browse tool" even when it 
may globally be something else.

Originally adopted from other xTalk dialects, "cantModfiy" also has an 
additional distinction in that it prevents savable changes to the stack.


All that's just background, hopefully demystifying concepts around 
interaction modes in LC.

To apply this to the problem at hand:

1. Check the stack's mode

2. If it isn't 1, you found the source of the issue.
    The next step would be to find how it became anything
    other than 1:

    2a1. Check the stack's "cantModify"
    If false then we can rule that out, so then:

    2a2. Check your code to see if you're opening the stack
    with a style as a command ("modeless", "palette", etc.).

If the mode is 1 then:

    2b1: Check the "cantSelect" of non-selectable controls.


Please keep us posted with what you find.  In nearly 30 years with this 
family of languages I've not yet found a problem that couldn't be 
diagnosed.  With a little patience we'll pin this one down for you too.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com