screenheight() still has to be calculated to find the control positions so they are visible with on screen keyboard.
with windows 10 the screenheight does not account for keyboard. so the window does not resize automatically. That has been one of the reasons for this whole exercise.Some of my controls will be hidden behind keyboard when screen is rotated. I have to figure out what the visible screen dimensions are!!
I might have misunderstood your comment. Once the dialog size and position has been determined then we can use coordinates of window.
I also have to rethink using any of the msg*() functions or any dialog that is centered. Without modification they will not always work right on Windows 10 when on screen keyboard visible.
Gale,
My core strategy in tablet programming with fwh:
To use dialog controls on ScrollPanel class.
When control get obtain focus, automatically open osk. Close osk on lost focus.
When open osk then scrolling Panel until osk top- 1
Regards.
That sounds good and I am glad you have it working for you.
Scrolling dialog is good and I had tried to implement that. There were several issues using that alone. #1 was the placement of navigation buttons like next, previous, print, cancel, etc. With Windows 8 and 10 if you put them on the bottom of the dialog then they could get covered up with on screen keyboard. It is inconvenient to always scroll to find important buttons or controls. Also the manipulation of the on screen keyboard is different from Windows 7 and Windows 8 or 10. I could not get on screen keyboard to start and stop correctly with focus placed back on original control. After working on screen rotation problems I have learned a lot more about on screen keyboards.
#1 was the placement of navigation buttons like next, previous, print, cancel, etc. With Windows 8 and 10 if you put them on the bottom of the dialog then they could get covered up with on screen keyboard.
