Since Microsoft doesn't allow to replace the system's virtual keyboard, I've developed a custom virtual keyboard as a UserControl to be used inside my Windows Store App. My current problem is that the default virtual keyboard always pops up whenever a user taps a TextBox.
I've been searching for a solution to this problem since yesterday, but I couldn't solve it. My almost successful attempt was developing a TextBox with a transparent Canvas over it. When the user taps the Canvas, the focus is programatically transferred to the TextBox and my custom virtual keyboard is instantiated. However, if no physical keyboard is connected to the tablet, the system keyboard also pops up with this approach (over my custom keyboard).
The main reason why I want to use a TextBox is because that way I can preserve and use the already implemented caret function, but it is not mandatory.
Any input will be helpful, thanks.
There are a couple of things you could do:
There are events for when the keyboard shows up, check those and see if you can prevent it.
You could implement a custom TextBox that suppresses OnPointerPressed event so that the TextBox is never focused. There are a couple of other things you'll need to do (such as prevent tabbing into it giving focus by setting IsTabStop=false.
You could implement a custom TextBox from the ground up (that looks and acts like a TextBox).
I think the second option is the easiest and most interesting option to try.
Edit: You could also give your TextBox a DependencyProperty that you set the current Page to via bindings. In the TextBox's OnGotFocus event, set the visual state to "CustomFocus" (or whatever you call it), then call Page.Focus();
Related
I am currently working on a Windows Presentation Foundation app and I need to make use of Message boxes. I want to get few information from user inside Message Box popup.
But they appear always like this:
But I think the actual look of it should be like that:
Does anybody know, why this is, and how to solve it? I tried all everything listed
here
, but nothing worked.
I agree with Keithernet, build your own. Its more of an Input Dialog box. You may want to plan it to create a window, create it with ex: 4 parameters which you could override so you can apply them in the form including
The title,
The prompt you want the user to fill in
optional default button 1 text
optional default button 2 text.
have the input value stored into a public property in the window for the text to be bound to during entry.
If the user clicks the cancel button (or similar), clear the text entry and close the window. If ok button, just close the window.
Then, when you call it with a YourWindow.ShowDialog(), upon return, you can look at the public property for that input text value.
You could even do with a property / flag if the user cancelled directly or not. I have done similar in a couple of my WPF apps.
MessageBox is very limited. Based on your screenshot, you should just create your own child Window with your own XAML so you can get the user input.
You can find sample service implementations/NuGets for this on GitHub. Here is one I've created sometime ago: https://github.com/Dirkster99/MsgBox
Just create your own is an oversimplifying statement in my opinion because this is usually a dialog that you want to show in different parts of the application. Therefore, you have to settle for a software design pattern (I chose a service implementation as suggested here).
Likewise, there are other design decisions that should be taken. I have for instance made sure that the API has a compatible subset of Show API calls with the standard .Net MessageBox to make its application as flexible as possible. I also settled for light and dark themes hoping this will make its application easy in any other theme...
Every windows hook is set to a particular window, or is global. And if I'm not wrong, even the textbox is a window. So, is it possible to set a low level keyboard hook to a specific textbox?
My goal is to capture keydown event on my textbox, but I figured out that using basic method I'm not able to capture the PrintScreen key, so I'm trying to do it another way.
Thanks
PrintScreen is a key that triggers a system function, e.g. Copy screen to clipboard. The key needs to work no matter what UI control has the keyboard focus and is getting the rest of the keystrokes, e.g. your text box. The way to capture this key is with a keyboard hook. See this answer. I believe the code works in both Winforms and WPF.
Shame I have to install another toolkit, but this seems to be pretty useful: Coding4Fun InputPrompt.
I am having an issue with it though:
There only seems to be functionality for triggering an event when the input is 'completed' without being able to differentiate between whether the tick is tapped or if the cross is tapped.
Rushed into asking for help unnecessarily there. Found a solution, will post below.
Original question:
Users of my application can currently submit messages which they do by tapping on a textbox and typing in the message and then tapping send.
I want to make this cleaner by not having a permanent textbox for this and instead have users tap on a button on the application bar along the button which brings up the keyboard along with a textbox to type into, and when users tap submit the textbox and keyboard disappear again.
I can't see any way of creating a popup with a textbox in it, so how would I do this?
I'm using the WP Toolkit already for a messagebox with a ListPicker inside, by even this toolkit seemingly has no way of adding a textbox.
I'm not sure what your trying to do is even possible. However, what you could do is have a Parent Form which contains your ideal Interface. Within this Parent you could create an Event Handler that is listening for a response.
Then when it comes to that Textbox it actually creates a Child Form or Page. Which they can input their value into. Then the page automatically closes, which then the Event Handler will already know the change for you to manipulate with the rest of your Logic.
As mentioned above, normally you would go to another page. I don't know if my solution is viable, but it does accomplish your goal. I'd recommend possibly refactoring your interface so that it makes it slightly more elegant. That way your logic handles it more elegant as well.
Hope that helps.
Shame I have to install another toolkit., but this seems to do the trick just fine: Coding4Fun InputPrompt.
They've added input.IsCancelVisible = true to add a cancel button and then use e.PopUpResult.ToString() == "Ok" within the input_completed method to only submit when the tick button is tapped.
I'm trying to determine whether or not a user left the WPF TextBox using the keyboard or the mouse.
If I decide to monitor the TextBox for certain keys being pressed, what are the keys for which I should watch? Put another way (hence the question title):
Question: With what keys can a user possibly leave a WPF TextBox?
Is it only Tab , or are there other keys to consider?
Don't forget about
Shift-tab
Arrow keys (depending on focus)
Alt menu option key combinations
Alt-tab
Windows key
tab by default. However, In windows forms (including WPF) you have full control over everything so the keystrokes/keystroke combinations that could cause a control to lose focus is virtually limitless. It would probably be fairly easy to see if anything specific could cause a specific control to lose focus, but covering all possibilities is impractical in the general case.
Also, have you considered how to handle voice recognition software that lets a user navigate a screen?
Is it possible to take focus from another program to respond to an event, but then once the response has been handled, switch back to the previous program and restore the cursor where it was?
This sounds like a weird question, but think of it along the lines of
User is typing in a text box in Program A.
A window for Program B pops up and user presses a few buttons to confirm something.
Program B returns control to Program A and restores the selection of the textbox.
If there is a complete C# solution, then great, but this sounds like it might require a little more effort than usual.
Any thoughts?
Personally, doing this could very likely result in the user selecting undesired values in the popup window. For example, someone is typing away in Word. Your application pops up a window, where hitting "Enter" selects a value ... such as the default button. Without wanting to, the user "selected" an incorrect value on your form.
Windows itself tends to do this, and it's very annoying. Quickly double-clicking a desktop shortcut to open an application and then switching back to (for example) an e-mail before the app launches, will tend to remove focus from the focused e-mail window and put focus in the just-opened application, causing your e-mail text or keyboard strokes to go to the just-opened window.
In my experience windows programs work just this way. It often appears that they don't because the user is returning focus with a mouse-click, which itself resets the focus. If it's a winforms app you can probably do something with the lost focus/got focus events at the form level.