Add a way to disable flyout's response to soft keyboard appearance

[wasker]

Hello,

I'm using Flyout to host editor for an item. Editor has a bunch of fields and is quite high. I found that it's easier for me to add some panning facilities to allow users to get to the controls obstructed by the keyboard, however this conflicts with Flyout's own attempts to manage soft keyboard appearance.

Please see the screenshots: http://imgur.com/a/1F468

First off, let's see the behavior if the hosted control doesn't react on soft keyboard.

By default the focus is on the second line, which is not obstructed by the keyboard, so Flyout doesn't move the control (OK). Since nothing lets user to get to the controls at the bottom, user will hide the keyboard (Hide keyboard.jpg).

Now, imagine that user wants to enter text to the last input line. Whenever they tap that control, keyboard appears, obstructs input and Flyout moves the whole thing up (Tap the last input.jpg). It actually overcompensates and, since there's no way to pan, there's no way to go to the controls on the top of the last field and the only way to go for user is to hide the keyboard.

I decided to make it less clunky to use and added panning myself to the hosted control. However, since Flyout still handles the keyboard, in situation when user hides the keyboard and then taps the last control, the whole flyout disappears from the screen (Tap the last input but when hosted control manipulates its size to enable panning.jpg).

I looked through your reactions to Flyout issues and my feeling is that there's not really much of what you can do about soft keyboard behavior. So my suggestion is to add some way to disable or extend Flyout's logic for those who want to manage this state on their own.

[timheuer]

What version are you using? If the flyout is a part of the visual tree then you should get the keyboard logic automatically without the flyouts provisions. I won't change it to manage the state as that isn't in line with the behavior of the keyboard expectations, but I had thought that I had fixed this issue of occlusion already. Please update to the latest version and/or try to put the flyout in the visual tree.

---

http://timheuer.com/blog/ twitter: @timheuer

On Sat, Jun 22, 2013 at 3:47 PM, wasker notifications@github.com wrote:

Hello,

I'm using Flyout to host editor for an item. Editor has a bunch of fields and is quite high. I found that it's easier for me to add some panning facilities to allow users to get to the controls obstructed by the keyboard, however this conflicts with Flyout's own attempts to manage soft keyboard appearance.

Please see the screenshots: http://imgur.com/a/1F468

First off, let's see the behavior if the hosted control doesn't react on soft keyboard.

By default the focus is on the second line, which is not obstructed by the keyboard, so Flyout doesn't move the control (OK). Since nothing lets user to get to the controls at the bottom, user will hide the keyboard (Hide keyboard.jpg).

Now, imagine that user wants to enter text to the last input line. Whenever they tap that control, keyboard appears, obstructs input and Flyout moves the whole thing up (Tap the last input.jpg). It actually overcompensates and, since there's no way to pan, there's no way to go to the controls on the top of the last field and the only way to go for user is to hide the keyboard.

I decided to make it less clunky to use and added panning myself to the hosted control. However, since Flyout still handles the keyboard, in situation when user hides the keyboard and then taps the last control, the whole flyout disappears from the screen (Tap the last input but when hosted control manipulates its size to enable panning.jpg).

I looked through your reactions to Flyout issues and my feeling is that there's not really much of what you can do about soft keyboard behavior. So my suggestion is to add some way to disable or extend Flyout's logic for those who want to manage this state on their own.

— Reply to this email directly or view it on GitHubhttps://github.com/timheuer/callisto/issues/213 .

[wasker]

That is the latest version actually.

About the visual tree - I initially added the logic that adds host popup to the visual root (the snippet from the home page), however it resulted in another strange behavior: from time to time, after I tap within the Flyout, the Flyout would disappear. I didn't find the reason for that and currently this logic was removed.

edit: clarified what I was adding to the visual root.

[wasker]

And just to make it clear - I'm not requesting Flyout to manage any states, but only a flag that would skip this part of code and let me manage soft keyboard myself:

        if (_hostPopup.Parent == null)
        {
            Windows.UI.ViewManagement.InputPane.GetForCurrentView().Showing += OnInputPaneShowing;
            Windows.UI.ViewManagement.InputPane.GetForCurrentView().Hiding += OnInputPaneHiding;
        }

[timheuer]

yeah if you parent it, you’ll get the “correct” behavior of the keyboard scrolling things into view for you.

without parenting it, then you have to measure yourself and hence the code you note. However we could probably try to be smarter about measurements.

-th

From: wasker Sent: ‎Saturday‎, ‎June‎ ‎22‎, ‎2013 ‎5‎:‎36‎ ‎PM To: timheuer/callisto Cc: Tim Heuer

And just to make it clear - I'm not requesting Flyout to manage any states, but only a flag that would skip this part of code and let me manage soft keyboard myself: if (_hostPopup.Parent == null) { Windows.UI.ViewManagement.InputPane.GetForCurrentView().Showing += OnInputPaneShowing; Windows.UI.ViewManagement.InputPane.GetForCurrentView().Hiding += OnInputPaneHiding; }

— Reply to this email directly or view it on GitHub.

[wasker]

Tim, I get what you're saying about parenting, but currently I'm stuck between the rock and a hard place: if I parent my dialog, I have full control over input pane handling, yet getting random flyout disappearance when user tries to interact with it (usually 2nd or 3rd appearance of the flyout); if I don't parent it, I completely give up the control over input pane handing and rely on Flyout's implementation, which may be not what I want in the end. Moar flexibility, please!

[timheuer]

If you can help me understand the repro of disappearing that is better. My goal is not to I introduce flexibility that may not be there (or needed) in the future ;-)

-th

Sent from mobile - please excuse tone and brevity

On Jun 23, 2013, at 11:07 AM, wasker notifications@github.com wrote:

Tim, I get what you're saying about parenting, but currently I'm stuck between the rock and a hard place: if I parent my dialog, I have full control over input pane handling, yet getting random flyout disappearance when user tries to interact with it (usually 2nd or 3rd appearance of the flyout); if I don't parent it, I completely give up the control over input pane handing and rely on Flyout's implementation, which may be not what I want in the end. Moar flexibility, please!

— Reply to this email directly or view it on GitHub.

[wasker]

http://screencast.com/t/cdOCglU8

Sorry it's kind of too fast. Pay attention to the tap point on the line where Tags label is. You'll see that in several cases tapping somewhere in the flyout (doesn't really matter where) the flyout simply disappears. In other cases you'll see me successfully tapping on all the controls.

Please let me know where can I send my markup and code for the repro.

[wasker]

Tim?