Buttons and groups do not have their own text displays, so their labels can inherent the text properties of the object. Adding a label to a field will require a whole set of new properties to distinguish its formatting from that of the field text. We'd also want relative placement properties (top, side), alignment, etc and by the time it's all there we'll basically have the same thing as our current field, only attached permanently to the parent field. So it seems to me that the only thing a label will save is the attachment bit.
Also we'd need to introduce a new property that controls the offset of the label in pixels from the field itself, since the distance between the two will always vary depending on layout, font size, etc. This isn't an issue with buttons and groups, where each OS has existing rules about label placement. On January 12, 2015 10:39:54 PM CST, Jim Lambert <j...@netrin.com> wrote: >Following the logic that it’s more better to have separate fields for >labels would dictate that the existing built-in labels for buttons and >groups should be deprecated! > >What’s good for the goose is good for the gander. ;) > >JimL > > > > >_______________________________________________ >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 -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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
