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 ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps _______________________________________________ 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
