LC8DP15 feedback-IDE Issues

[Mark Waddingham]

On 2016-03-03 16:35, Mark Wieder wrote:
> I'm also curious now about the use case for cantSelect. I realize it's
> not going away since it's always been there, but I'm having trouble
> coming up with a scenario in which this is useful. My worry is that
> we're putting a pretty obscure setting front and center in a primary
> tool for stack design when screen real estate is already at a premium
> (e.g. we're already overloading functions into the PB.

The use-case for 'cantSelect' is to allow you have objects on a stack 
which act as if they are in browse/run tool mode when the global tool is 
not the browse/run tool. For example you can create a single stack which 
has buttons allowing to (say) choose different types of graphic object, 
but still allow you to create the graphic objects on that stack with the 
standard graphic object tools. (i.e. You get a simple vector graphic 
object editor).

In the IDE the 'cantSelect' property can seem strange because the IDE 
shares the same notion of current tool that user stacks do. Ideally the 
IDE 'tool' would be distinct from the user stack 'tools'; in much the 
same was as ideally it wouldn't have to rely on the same set of object 
manipulation messages as user stacks do (hence the current problem with 
palettes not updating when lock messages is in effect).

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps