An edit_field with a value begins entirely selected. Possible to avoid?

[DFBurns]

In my dialog box, I have an edit_field that is bound to value and when the dialog box is displayed, all of the text is selected (this is true for both Win and Mac).  Is it possible to avoid this? I'd rather have the cursor sitting at either the beginning or end of the text.

If it helps, here is my current definition:

f:edit_field {

    fill_horizontal = 1,

    height_in_lines = 10,

    width_in_chars = 40,

    allow_newlines = true,

    value = LrView.bind( 'text' ),

}

Thanks,

db

[johnrellis]

I think this is caused by the SDK assigning focus to that control when the dialog first opens. In general, LR seems to assign focus to the first or second control in the dialog, and I've sometimes rearranged the design of plugins to take advantage of that, making it easier for the user to start typing immediately.

I haven't seen any way of controlling this, other than by using keystroke stuffing via a utility, which of course is fragile and far from robust.

[johnrellis]

I remember something I had observed before -- disabling and re-enabling a control takes away the focus. Here's a sample script demonstrating that:

local Require = require "Require".path ("../common").reload()
local Debug = require "Debug"
require "strict"
local LrBinding = import "LrBinding"
local LrDialogs = import "LrDialogs"
local LrFunctionContext = import "LrFunctionContext"
local LrTasks = import "LrTasks"
local LrView = import "LrView"
local bind = LrView.bind
local f = LrView.osFactory()
local showErrors = Debug.showErrors
LrFunctionContext.callWithContext ("", showErrors (function (context)
    local prop = LrBinding.makePropertyTable (context)
    local controls = f:column {bind_to_object = prop,
        f:edit_field {value = "text 1", enabled = bind ("e1")},
        f:edit_field {value = "text 2", enabled = bind ("e2")},
        f:edit_field {value = "text 3", enabled = bind ("e3")}}
    LrTasks.startAsyncTask (showErrors (function ()
        LrTasks.sleep (0.05)
        prop.e1, prop.e2, prop.e3 = false, false, false
        prop.e1, prop.e2, prop.e3 = true, true, true
        end))
    local result = LrDialogs.presentModalDialog {
        title = "Test", contents = controls}
   end))

This takes the focus away entirely, requiring the user to click in the box to edit it.  The re-enabling is done in an asynchronous task to ensure that it occurs after the dialog is already materialized and open.  The sleep (0.05) isn't necessary in my testing, since I've long observed that when you create another task, execution continues in the current task until it does an explicit or implicit yield. But the sleep() here is just a little extra safety in case the task scheduler ever changes.

[DFBurns]

Thanks, John.

It's an interesting technique but ultimately it doesn't solve my goal of not having any text selected when the edit_field does regain focus. In this one scenario, the user is editing existing contents and I don't like it when one inadvertent keystroke can delete the entire contents of the field. I wonder if there's an undocumented setting somewhere...

Cheers,

db

[johnrellis]

I wonder if there's an undocumented setting somewhere...

I don't think there is such a setting via viewFactory.   One technique for finding such things is to invoke Debug.lognpp (controls) on the controls passed to LrDialogs.presentModalDialog.  That dumps out the entire internal Lua structure of the controls.  When I do that, I can't see anything relevant for the edit_fields.