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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
