Thanks Richard & Alan for the response. It looks like a plugin is responsible
for this strange behaviour...
Richard - great and comprehensive background information on some of the things
going on in LiveCode 'under the hood'. My primary use of the IDE is to create
utilities and prototypes - so I consider myself very much an IDE ‘driver’
rather than any kind of ‘engineer’. Thanks for the first-level checks. I
created a new stack on 8.1.1 with just a button and a right-click didn’t reveal
a menu, despite put the mode of this stack = 1 and put the cantmodify of this
stack = false.
Alan - thanks for the tip regarding plugins & BvG Docu. To continue the above
car analogy, I don’t venture under the hood but I have a whole raft of plugins
that I’ve collected over the years (with little thought to housekeeping),
including BvG Docu 2. I’m sure many of these delve into LiveCode’s inner
workings. I moved BvG Docu 2 out of my Plugins folder but the behaviour
persisted. So, I emptied the Plugins folder and LiveCode 8.1.1 seems to be
behaving as I expect to see. :-)
Am I correct to assume that a clean LiveCode installation would have the
Plugins folder empty? I ask as despite clearing this out, I still see a couple
of third-party plugins listed despite the Plugin folder being empty - e.g. Data
Grid Helper. Have I further housekeeping to undertake to clear the decks of any
obsolete code?
Best,
Keith..
> On 24 Sep 2016, at 19:27, Richard Gaskin <ambassa...@fourthworld.com> wrote:
>
> 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
_______________________________________________
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
