WPF Application with OnScreenKeyboard on Windows Tablet - c#

I am building a WPF Application that is going to be used on Desktop as well as on a Surface Pro Tablet running the Win10 Creators Update.
If a Textbox gets Focus the onscreenkeyboard of Win10 should open on the bottom of the screen and move the application up the screen to push the focused element back into view.
I have implemented WpfTabTib which worked pretty well until we updated the tablet to the creators version. Technically it is still working but with an ugly animation moving the window up, down and up again to open the keyboard.
Having read that microsoft adjusted the behaviour of the keyboard to match the uwp behaviour I have updated my .Net framework to 4.6.2 without the hoped result. It seems Microsoft doesn't care for this behaviour.
Does anyone have the same problem or an different approach for me ?
Thanks a lot!
Edit: Updating the Tablet to an Insider Preview of the coming Windows Fall Update changed the behaviour again: The opening animation is now a little better, but still far from nice. And as new problem closing the osk doesn't move the application back down.

Related

How do I invoke or dismiss the touch keyboard in WPF using .NET 4.6.2?

Microsoft's release notes for .NET Framework 4.6.2 includes the following:
"Soft Keyboard support enables automatic invocation and dismissal of the touch keyboard in WPF applications without disabling WPF stylus/touch support on Windows 10. Prior to 4.6.2, WPF applications do not implicitly support the invocation or dismissal of the touch keyboard without disabling WPF stylus/touch support. This is due to a change in the way the touch keyboard tracks focus in applications starting in Windows 8."
The List of Changes likewise states:
"Enable automatic invocation and dismissal of the touch keyboard in WPF applications without disabling WPF stylus/touch support on Windows 10 [178044]"
But I cannot find any indication of HOW to do this, and I cannot find anything in the official API diff that seems to be this.
Can anyone help me find documentation of how to do this thing that I can now allegedly do?
My context is that I have an application that explicitly launches "OSK.exe" when needed. On touch devices with a built-in Windows on-screen keyboard, this results in TWO on-screen keyboards being shown. I want to disable the standard one and only launch "OSK.exe" explicitly.
Thanks!
I think this (especially the comments) should answer your question. The short story is: there is nothing specific to do, but it works only on Win10 anniversary edition.
To disable the soft keyboard, you can do what's indicate in the comments:
WPF on Windows 7 with touch: hide soft keyboard (and the popup icon that enables it)
or
https://blogs.msdn.microsoft.com/winuiautomation/2015/04/26/how-and-why-i-added-an-on-screen-keyboard-to-my-windows-store-app/
If in WPF on Windows 10 anniversary edition, you can override automation peer in TextBox:
protected override AutomationPeer OnCreateAutomationPeer()
{
return new FrameworkElementAutomationPeer(this);
}
On Windows 7 it is enough to put
InputMethod.IsInputMethodEnabled=”False”
Hope it helps.

Windows CE 6.0 (OEM 5.37) not displayed hourglass cursor

I have a problem with displaying the hourglass and custom cursors in Windows CE applications on OEM 5 platform. Question is that the cursor does not display by default, and is displayed only when I click on the screen.
Interestingly, the hourglass cursor spins correctly on OEM 4 platform.
I think, that in OEM 5, UI would updated only by actions outside.
What can be done so that the cursor will update correctly at the screen?
I had a similar issue. Here so far what I know and what solutions you have:
In some mobile operating systems the wait-cursor is very sensitive. When you activate him twice (without deactivating him) he will not appear again.
Also there are CE-Devices where a wait-cursor won't show up.
You could disable all controls when you are processing something
You can also put a wait-image or a wait-label in the middle of the screen instead of using the wait-cursor.
My colleagues and I spent lots of hours on these buggy wait-cursors under windows ce. Finally we gave up and used this solutions I mentioned.

WPF visual problems on Windows XP

We have a huge project in WPF .NET 4.0 which should support Windows XP SP3 and above. (hence the use of .NET 4.0) It has no problems whatsoever on Windows 7 and 8/8.1. However we're experiencing major visual issues when running on Windows XP to the point that the application is unusable.
I searched a lot and came across some similar questions such as this one but none of the suggested solutions worked for us.
Here's an screen shot taken on Windows XP SP3:
The odd thing here is that there is clone of "28" TextBlock you see in the screen shot, to the left of it. They have everything in common except their name but the left one is not rendered properly!
And here is how it really looks like (taken on a Windows 8.1 test machine):
Some pages are even worse:
When I remove AllowsTransparency from the main window, it looks like this on XP: (Note that the title bar has no problems any more)
We're really stuck and have no clues about its cause. Any help would be appreciated.
It seems this problem is related to the graphic card. In another VM with a different graphics accelerator we didn't face any major problems. In the problematic test machine, we lowered hardware acceleration to the third level and the problem is gone.
Display Properties -> Settings -> Advanced -> Troubleshoot
Although there are still some small issues with some mouse over animations and we lost the benefits cursor accelerations bring to the table, it's acceptable for us since not much is expected from Windows XP.

Windows Form Application Touch Gesture

We are developing a C#, .NET 4.5 application. On Windows 8.1, whenever a user does touch scrolling on one of the panels in the form, the entire screen application moves just a bit, even if maximized.
Found questions asked where people having similar issues fixed it in WPF by turning off the boundary feedback event, and people who fixed it in Windows 7 by just turning off boundary feedback for all of Windows. However, I can't find anything for disabling this in a standard C# windows form application, and the boundary feedback setting option doesn't seem to exist in the Windows 8 settings.
Any suggestions?
Thanks
I haven't tried this, but I believe you can override the WM_GESTURE message (specifically GID_PAN) and not send it on.
The default code is likely very similar to the example code in UpdatePanningFeedback .

3D Screensaver interfering with WPF application (Windows XP)

I have a fairly large application that uses WPF for its user interface. I recently found an unusual defect regarding 3D screensavers. The 3D screensavers 3D FlowerBox,3D Flying Objects,3D Pipes,3D Text causes 1 of my WPF windows to disappear when the screensaver activates. Other screensavers are fine.
My application only encounters this problem on Windows XP.
I have some experience with DirectX. When a 3D screensavers activates, the d3d device context will be switched to exclusive mode. I reckon that WPF has trouble restoring the device context when the device switches back to cooperative mode (hence why its only affecting windows XP)
Has anyone seen such a scenario occur before ? Is there a remedy for the problem ?
Windows XP SP3, DirectX 9.0c, .NET 3.5
Not that exact one, but I have definitely seen strange problems with WPF and Windows XP, especially. The easy thing to say would be that you should try to move to Windows 7 ASAP, but then I would just be a jerk.
First off, check your video device driver. We've had a lot of problems with WPF on XP when an old graphics cards' device drivers are used. Update it to the latest version. That could take care of it.
If that doesn't work, and if you can, try swapping the video card for a different brand. That, too may work (though highly undesirable).
Third -- is your window semi-transparent or non-rectangular? If you switch your WPF app to be a regular, rectangular, boring, ugly Windows XP window, we've found that a lot of these quirks went away when we stopped getting fancy with our main windows. My guess is that it has something to do with the fact that XP has no desktop window manager. But then again I don't really know.
I know this is all very unsatisfying. We've had stuff like this happen to us on XP. I'm praying for our IT department to be able to move us to 7 this year...

Categories