On 11 Jul 2014, at 5:44 pm, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote:
> In such a case, it’s also worth re-considering your UI at a higher level. > > I wonder, for example, whether there’s an alternative that uses *two* text > fields. Put the file name in the ‘textField’ outlet field, and put the > extension in a separate but adjacent field. Use auto-layout to keep both > fields sized to their contents, and to keep the second field immediately > adjacent to the first. If that’s actually possibly, it’ll look like a single > string when not being edited, but will change the UI so that editing of the > pieces is separate. (Or make the extension field uneditable, if you don’t > actually allow it to be changed.) It might even be *better* than the old way. > :) I'm open to all ideas. But I'm essentially trying to mimic what happens in the Finder, where name+extension can be edited as a unit, but not accidentally. I also want to keep some names unable to be edited at all. Your idea also raises the question of what will be selected when the user presses return and there are two text fields. If I understood how that process happened, I might find a better solution. (And auto-layout is down the track for this .xib -- each time I start playing with that conversion, I seem to end up either crashing Xcode or producing an unreadable .xib. So it's one step into the future at a time.) -- Shane Stanley <sstan...@myriad-com.com.au> <www.macosxautomation.com/applescript/apps/> _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
