Matthew,

<< 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. >>

The issue is the soft keyboard.  I would *not* have designed touch
interfaces with a soft keyboard like they did with iOS, Android.  It's a
*nightmare* for a lot of applications, from completely taking up most of the
screen to issues like this.  A slide-out keyboard/hardware solution would
have sufficed.

Anyways, back to EWB: any time you focus a control, up comes the soft
keyboard.  This can be a *really* annoying when you're simply navigating
from form to form.  So, on mobile/tablets with a soft keyboard you want the
*user* to touch the control in order to focus it, not have automatic
focusing.

Tim Young
Elevate Software
www.elevatesoft.com

Rick,

<< 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.
>>

This was required due to IE8.   IE8 has/had major activation/focus problems
that cost me weeks of work, and none of that applies anymore since EWB 2
targets IE9 and higher.  In IE8, any time you clicked outside of a control
on a non-focusable element like the form surface, it would cause the current
control to lose focus.  So, EWB1 had to jump through hoops to detect this
and re-direct focus back on to the proper control.  In IE9 and higher, it
works correctly.  If you click on a non-focusable area, then the current
control with focus *does not* lose focus, hence it never gets re-focused.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> any time you focus a control, up comes the soft keyboard

Any control, or just edits? A quick whizz around Google shows that you
can use "Blur()" to hide the keyboard immediately (so it doesn't really
appear), but that would probably stop it appearing manually.

To be honest, I'd have the keyboard appear if it is in an edit. But if
any control, then it's a problem of course. And then you'd be right to
not "restore focus" automatically.

I would sort of assume that if I had FormA with an edit and button,
that clicking the button would take the focus to the button, show
FormB, and on return would go back to focus on the button, not the edit
box. If the edit was focussed when FormB was shown, the keyboard would
be visible, and on return I'd expect it to return again.

Perhaps it might help to have a sample - do you have one we can go to?

Matthew,

<< Any control, or just edits? >>

Yes, sorry edits are what I'm discussing.  The assumption here is that the
first control on a form is an edit, and that's what triggers the soft
keyboard when the first control is automatically focused on a form show,
etc.  Which I'm now just realizing was a 4) on that list.  Right now EWB
automatically focuses the first control on a form when the form is shown.

<< A quick whizz around Google shows that you can use "Blur()" to hide the
keyboard immediately (so it doesn't really appear), but that would probably
stop it appearing manually. >>

Yes, that would kill it permanently.

<< To be honest, I'd have the keyboard appear if it is in an edit. But if
any control, then it's a problem of course. And then you'd be right to not
"restore focus" automatically. >>

You'll have to use an edit-heavy form to see what I'm talking about, but
trust me when I say that the soft keyboard pops up constantly in ways that
aren't very user-friendly, and are downright frustrating after a while.

<< I would sort of assume that if I had FormA with an edit and button, that
clicking the button would take the focus to the button, show FormB, and on
return would go back to focus on the button, not the edit box. If the edit
was focussed when FormB was shown, the keyboard would be visible, and on
return I'd expect it to return again. >>

Correct.  But, things like showing error message dialogs, etc. don't
necessary follow this same pattern.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>
> You'll have to use an edit-heavy form to see what I'm talking about,
> but trust me when I say that the soft keyboard pops up constantly in
> ways that aren't very user-friendly, and are downright frustrating
> after a while.
>

Well so far every time I think it would be nice if "whatever" I've
found that you have already thought it through and solved it, so I'll
trust that you will do the same here.

Very much looking forward to touch support. 8-)

On 12/02/15 23:08, Tim Young [Elevate Software] wrote:
> This was required due to IE8.   IE8 has/had major activation/focus
> problems that cost me weeks of work, and none of that applies anymore
> since EWB 2 targets IE9 and higher.
>

Thanks Tim. I'm glad to see that situation go!

That's interesting... EWB2 targets IE9 as a minimum. Does this mean that
the browser must support HTML5? Are there any other minimum requirements
for EWB2?

--
Rick

Rick,

<< That's interesting... EWB2 targets IE9 as a minimum. Does this mean that
the browser must support HTML5? >>

Yes.

<< Are there any other minimum requirements for EWB2? >>

Nope, that's it.

Tim Young
Elevate Software
www.elevatesoft.com