search

AvaloniaUI / Avalonia

Develop Desktop, Embedded, Mobile and WebAssembly apps with C# and XAML. The most popular .NET UI client technology
https://avaloniaui.net
MIT License
25.73k stars 2.22k forks source link

On screen keyboard #13319

Open mattwilson345 opened 1 year ago

mattwilson345 commented 1 year ago

Describe the bug

On phones the on-screen keyboard can cover up textboxes and you cannot see what you are typing. It is easy to add bottom margin to the scroll-viewer, BringIntoView; in GotFocus. If there was a way of knowing how tall the On-screen-keyboard was it would be perfect, but I cannot find a solution for this problem.

To Reproduce

have a textbox in the bottom 20% of the screen.

Expected behavior

The textbox on top of on-screen keyboard. Or if you knew the height of the on-screen keyboard you could do this yourself.

Screenshots

Environment

IOS and Android. Avalonia-Version: [11.0.4]

Additional context

maxkatz6 commented 1 year ago

@emmauss didn't we have a solution for this with resizing the root view? I am pretty sure it worked at some point.

emmauss commented 1 year ago

The root view isn't resized by default, but one can adjust the padding of the main view to account for safe area, which currently includes keyboard insets on android, using the InsetsManager. But the internal views, i.e. the textbox needs to be hosted by a ScrollViewer, and always kept in view. This isn't implemented yet.

maxkatz6 commented 11 months ago

This issue is still valid and reproducible. But at least now there is a way to handle keyboard appearance and adjust the app accordingly. From the Avalonia side, we need to add automatic adjustments and bring a focused element to view, when the keyboard appears. But this is likely to happen mid-11.1.x.

LyleRolleman-plst commented 8 months ago

The above InputPane implementation doesn't appear to actually have been released?

It's been on master for awhile but looking at 11.0.9, nothing.

Considering how important this is on mobile, this is rather surprising...

timunie commented 8 months ago

@LyleRolleman-plst features go into major release, e.g. 11.1. If you need it now, use nightly builds until 11.1 drops.

LyleRolleman-plst commented 8 months ago

Tried the nightly build but InputPane was always null on TopLevel :(

Will just roll my own I guess until this is sorted out

maxkatz6 commented 8 months ago

Tried the nightly build but InputPane was always null on TopLevel :(

It means that your target OS either doesn't support input pane API (like, older Windows), or Avalonia didn't yet implemented support for it (like, some Linux distros, I believe)

LyleRolleman-plst commented 8 months ago

Tried the nightly build but InputPane was always null on TopLevel :(

It means that your target OS either doesn't support input pane API (like, older Windows), or Avalonia didn't yet implemented support for it (like, some Linux distros, I believe)

It was Android actually (emulator to be precise)

Same thing also appeared to be the case on iOS (physical), though I'm having some debugger woes there atm so not 100% sure (it hits breakpoints but doesn't show anything, treats it as external code)

One possibility I can think of is it's just not initialized yet, as I was trying to do it in my MainView constructor. Will have to see.

timunie commented 8 months ago

One possibility I can think of is it's just not initialized yet, as I was trying to do it in my MainView constructor. Will have to see.

Try to use Dispather.UiThread.Post with priority Loaded when you want to access view elements from constructor.

LyleRolleman-plst commented 8 months ago

One possibility I can think of is it's just not initialized yet, as I was trying to do it in my MainView constructor. Will have to see.

Try to use Dispather.UiThread.Post with priority Loaded when you want to access view elements from constructor.

That's good to know.

I was able to resolve the issue by moving the access into the Loaded event as well