This probably reflects my complete ignorance, but...

J. Landman Gay jacque at
Fri Oct 29 12:51:19 EDT 2010

On 10/29/10 1:54 AM, Vokey, John wrote:

> in the Metacard IDE, as soon as I script-select the line to allow the
> user to draw the line so my code can get the rect, it switches the
> IDE to edit mode, which means any subsequent clicks on buttons (to
> indicate that the line has been drawn, etc.) put that button (or
> whatever object) into edit mode, so the intent of the object is lost.
> Suggestions?  Remember, they have to work within the Metacard IDE,
> and I can't know ahead of time when the user has finished drawing or
> adjusting the line.  Obviously, the Metacard IDE itself has solved
> the problem (e.g., all of the IDE stacks remain in use not edit
> modes), but I remain baffled.

The IDE doesn't matter, it works the same way in any IDE and is normal 
engine behavior. Both LiveCode and MetaCard manage this by making their 
IDE stacks into palettes or modeless windows. Those window styles always 
operate in browse mode.

It's been years since I played with this, but if nothing has changed, 
the engine still sends all mouse messages normally even in edit mode. 
However, both IDEs trap those messages in a frontscript in order to 
manage editing actions. You can get around that by temporarily removing 
the frontscript, waiting for a mouseEnter into a button, and then 
restoring the frontscript and going back into browse mode. But that can 
be tricky and prone to error, which is why it is much easier to just 
provide palettes for user interactions during editing operations. I 
haven't tried it lately so it may not work anyway.

Jacqueline Landman Gay         |     jacque at
HyperActive Software           |

More information about the Use-livecode mailing list