How to stop LoveCode running in Edit mode

[Keith Clarke]

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