DatePicker is not considered focused immediately after calling Focused(true). Focused() returns False if called immediately afterwards.
Code to reproduce bug. Notice output in browser console:
var view = new Fit.Template(true);
view.AllowUnsafeContent(false);
view.LoadUrl("debug.html", function(sender)
{
var item = null;
var datepicker = new Fit.Controls.DatePicker(Fit.Data.CreateGuid());
datepicker.Date(new Date());
item = view.Content.Controls.AddItem();
item.Control = datepicker.GetDomElement();
var button = new Fit.Controls.Button();
button.Icon("cog");
button.Title("Focus DatePicker (see log output)");
button.OnClick(function()
{
datepicker.Focused(true);
console.log("DatePicker immediately focused (true expected): ", datepicker.Focused()); // BUG: Focused() does not return True
});
item = view.Content.Controls.AddItem();
item.Control = button.GetDomElement();
view.Update();
});
view.Render(document.body);
Internally, DatePicker uses function overrides for FireOnFocus and FireOnBlur to update the internal focused state, but that is invoked async. The focused state must be updated immediately when calling Focused(true).
The solution above is probably something we can now realize using the ability to set a focus state lock:
Notice how the comment describes how the control must function when the focus state is locked (marked in the screenshot above). This means we can fix our problem in DatePicker like this:
And naturally it would be wise to change the implementation in DatePicker so it uses the new FocusStateLocked(..) function rather than overriding the implementation of FireOnFocus and FireOnBlur (first screenshot).
DatePicker is not considered focused immediately after calling Focused(true). Focused() returns False if called immediately afterwards.
Code to reproduce bug. Notice output in browser console:
Internally, DatePicker uses function overrides for FireOnFocus and FireOnBlur to update the internal
focused
state, but that is invoked async. Thefocused
state must be updated immediately when calling Focused(true).The solution above is probably something we can now realize using the ability to set a focus state lock:
Notice how the comment describes how the control must function when the focus state is locked (marked in the screenshot above). This means we can fix our problem in DatePicker like this:
And naturally it would be wise to change the implementation in DatePicker so it uses the new FocusStateLocked(..) function rather than overriding the implementation of FireOnFocus and FireOnBlur (first screenshot).