Hi everyone, another question for you:

The focus control in EWB 2 is currently a little less stringent than EWB 1,
but it still gets a little overly aggressive in ways that make mobile usage
weird.  The situation is this:

1) When you click on a focusable control, EWB 2 "remembers" this control as
the last active control for the container control.

2)  If you click on a non-focusable control or an area of the container
control, EWB 2 will automatically re-direct focus back to this last active
active control.

3) When you close a form, and the prior form had a last active control, then
EWB 2 will automatically re-direct focus back to the last active active
control for the prior form when it is brought forward.

I'm probably going to do away with 2) completely because it's not necessary
at all anymore (a pre-HTML5 behavior in IE 8 or earlier required it).

As for 3), I'm up in the air.

For 2) and 3), both trigger a superfluous soft keyboard show on mobile that
is no-no, so I'm thinking that 2) will go away and 3) will become a property
switch.  However, I'm also open to just ditching the whole "last active
control" and letting the user/developer choose when/how to focus a
particular control, especially since I don't want the default behavior on
mobile to be wonky.

What do you think ?

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> 3) When you close a form, and the prior form had a last active
> control, then EWB 2 will automatically re-direct focus back to the
> last active active control for the prior form when it is brought
> forward.

This sounds like a handy behaviour. I'm not sure what the alternative
is really - go to the first or something? But if I am typing something
and a pop-up happens to say "too much text" or something, then I'd want
it back where I came from. Presumably a button to say "Add ten" which
shows a window and then closes would be handy to have easy to repeat.

If it is possible to override, then fine, but it sounds good the way it
is.

2, I'd be happy to lose.

Matthew,

<< This sounds like a handy behaviour. I'm not sure what the alternative is
really - go to the first or something? >>

The alternative would be to let the developer choose which control to focus
after a form closes.

<< But if I am typing something and a pop-up happens to say "too much text"
or something, then I'd want it back where I came from. Presumably a button
to say "Add ten" which shows a window and then closes would be handy to have
easy to repeat.

If it is possible to override, then fine, but it sounds good the way it is.
>>

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

I think that "ditching" is the way to go here Tim.

Mark Brooks wrote:

> I think that "ditching" is the way to go here Tim.

Ditching all behaviour? The main thing for me is you need to know what
is happening, and how you can control it. If I do a ShowModal on a
form, I want to know where the focus will end up when the form is gone
again. To me, back where it was before makes sense. "Nothing changed".

If it is ditched, then where will the focus be, and how do I set it to
where I want it again? I'd rather not have to set the OnClose for any
form that I want to show. An event to indicate "child form closed"
would be fine, though then I have to store state if I care about which
had the last control. I'd rather the framework do that for me.

Tim,

> However, I'm also open to just ditching the whole
> "last active control" and letting the user/developer choose when/how to
> focus a particular control, especially since I don't want the default
> behavior on mobile to be wonky.

That's the best option, I think.

Uli

On 2/11/2015 9:09 AM, Tim Young [Elevate Software] wrote:
> For 2) and 3), both trigger a superfluous soft keyboard show on mobile
> that is no-no, so I'm thinking that 2) will go away and 3) will become a
> property switch.  However, I'm also open to just ditching the whole
> "last active control" and letting the user/developer choose when/how to
> focus a particular control, especially since I don't want the default
> behavior on mobile to be wonky.
>
> What do you think ?

It would be nice to have "mobile" vs "non-mobile" based default
behaviors but i do realize that just adds to the "todo feature pile".

From mobile side ditching makes sense.

For non-mobile ditching #3 looks like pain - unless i'm misunderstanding
this one would need to write bunch of (almost standard) focus code into
every form if you wish to have any keyboard usability within EWB app.
Scrolling issues come to mind as well if focus set would cause the form
to scroll.

Raul

Raul, Matthew,

<< For non-mobile ditching #3 looks like pain - unless i'm misunderstanding
this one would need to write bunch of (almost standard) focus code into
every form if you wish to have any keyboard usability within EWB app.
Scrolling issues come to mind as well if focus set would cause the form to
scroll. >>

I'm leaning towards a conditional #3, depending upon mobile detection.
Offering a property switch would simply just be offloading the same decision
to the developer who will use the same properties to determine mobile usage.
Likewise for the focus functionality itself, which would involve the
developer essentially doing what EWB is already doing.

So, no automatic focus on container mouse downs, but automatic focus on form
switches (from active form to previously-active form or when showing a new
form), depending upon mobile detection.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> depending upon mobile detection

I read this last night on my phone (can't reply from it for some
reason), and it made me wonder what is so special about "mobile"? What
does it even mean any more? My applications are designed to be used on
any device. The lastest version of my Connect product works on any
screen from massive monitor on a desktop PC, through Chromebook, iPad,
iPhone 6, to the 3.5" iPhone and Androids. Works nicely, apart from not
supporting touch.

I'd expect my web shop to work the same on any device, though I've not
gone with support for small screens on that.

I realise there may be technical differences, but I still think that
what is needed is a simple and consistent behaviour from the framework.
Restoring to the last focused control seems a sensible option to me. I
realise I know nothing of the technicalities, but if I have to do
special stuff for mobile, then it almost shouldn't do it for desktop
otherwise I'll not see the behaviours in desktop testing and thus fix
it for all.

IMO of course...

On 12/02/15 01:09, Tim Young [Elevate Software] wrote:
> 1) When you click on a focusable control, EWB 2 "remembers" this control
> as the last active control for the container control.
>
> 2)  If you click on a non-focusable control or an area of the container
> control, EWB 2 will automatically re-direct focus back to this last
> active active control.
>
> 3) When you close a form, and the prior form had a last active control,
> then EWB 2 will automatically re-direct focus back to the last active
> active control for the prior form when it is brought forward.
>

Tim, I'm happy for EWB2 to handle focusing automatically in both 2 and 3
above just like Delphi does. The last active control always
receives/retains focus as described. Probably best controlled by a
switch (form/application property?) so that the developer can choose to
handle focus manually or let EWB do it. Of course, you don't want the
keyboard appearing on mobile so that has to be prevented somehow.

Whatever you choose to do, my one request is please don't let the
memo/edit control automatically select all of its text when the user
clicks outside of it (as in 2 above). That behaviour in EWB1 is a little
annoying. If the focus does automatically go back to a control then text
selection needs to be in the same state as when focus left and the caret
should be in the same location (just like Delphi).

--
Rick