I have a Page in WPF which has a text box. This text box is set to be focused on load.
There is an application running in the background which takes a string value of a biometrics scan result and places it in that text box. This is a 3rd party application, and we have been told that it looks for a text box with a certain name, in an application with a certain name and if that text box is focused on, it will write that string in.
This works perfectly fine, but below is the problem I am having.
We have another piece of software which is a custom on screen keyboard. The text box can also be written into so the user can click a button to bring up this keyboard then start typing. However when this keyboard comes up, it seems to lose focus to my application and it doesnt come back again. For the lifecycle of our application running, the biometrics doesn't work because it doesn't see my application as the one currently in focus.
How do I force my application to come back in focus, but only when I want it to. I don't want it ALWAYS to be in focus and on the top, else the custom keyboard would never show.
I looked into Application.Activated Event with no joy, and even tried the following
public static extern bool SetForegroundWindow(IntPtr hWnd);
Getting a but stuck, does anyone have any advice?
Have you tried Activate() and Focus() methods?
This thread has a bunch of answers on topic Bring a window to the front in WPF
This particular one worked for me https://stackoverflow.com/a/7559766/305020
Related
I'm developing a GUI in Linux (Ubuntu 16.04 - WM: Gnome) using GTK+3 and the graphic library cairo.
After clicked on a push button (Plot), using the instruction of cairo I draw a red square on a new top window where I put a GtkDrawingArea.
In this window I also put a push button (Cancel) that clicked, hide the window. In this way, if I re-push "Plot", the red square reappear.
The issue is the "x" icon present in the top bar of the window.
If (no me) a user push this x, the window disapper and if he re-push the "Plot" an error is reported.
The question is: it is possible avoid this possible cause of error?
(remove this "x" from the top bar of the window or in some way disable its functionality).
I tryed to find alone a solution and the possibility found are:
1 - Remove from the window the property of "decorated".
The top bar disapper (so also the x) but is not possible move the window on the screen
2 - Using the function gtk_window_set_deletable(window, FALSE) (used before to show the window), but the x is always there and pushing it the window is destroyed.
If you think that can be useful, I can report the code.
I'm waiting your suggestion.
Edit:
Now we know what you want to achieve: display a separate window but avoid destroying it so you can display it again. You already have in the "Cancel" button of your secondary window the logic to hide it.
The cleanest solution is to just do the same: when the user tries to close the secondary window, hide it instead. This way the user is not frustrated of seeing something that apparently doesn't work as expected. Hidden or closed, it's different for you but it's the same for the user.
So you just need to connect to the delete-event of that secondary window, and hide it. There's even no need to create a specific callback for that, GTK+ provides it for you: you just need to connect the delete-event to gtk_widget_hide_on_delete. To display the window again, just call gtk_widget_show_all on it.
Original answer:
I realize the plot
"realize" is a term that has a defined meaning in GTK+. Don't use it out of context, and try to use an alternate term if you're not talking about widget realization.
What I would like is to remove this "x" from the top bar of the window
or in some way disable its functionality.
Do you understand this is ultra annoying for a user and defeats a unified user experience? Would you like to use applications that do random different things?
Anyway, one way of disabling the closing button is to connect to the delete-event and return TRUE there to stop the propagation of the event. The button will still be there but do nothing, so you will have to kill the app to exit it.
To make the button disappear, gtk_window_set_deletable will ask the Window Manager to do that, but we'd need some code to know what's wrong with your attempt.
I have a simple user control (just an example): it is 40x100, but resizable. It has two buttons, one anchored at the top, one anchored at the bottom.
It put this control on a form and stretch it to 40x400. This works fine.
But as soon as I switch the form to Localizable = True and change the language to translate any strings, the Designer shows the user control
as if it was 40x100 for both the default an the translated language, i.e. the bottom button is not anchored.
Or better: the bottom button is displayed as if it was not anchored. The control occupies the correct amount of space (40x400), though (see selection highlight). And it displays fine during runtime, this is just a Designer issue.
A picture showing the issue.
Did I miss something here? Is this how it is supposed to work?
Im on VS2010 at the moment, tried the old VS2005 but it's the same there.
Thanks...
I could easily repro this problem by anchoring the second button to the bottom. The Anchor property has a few oddish failure modes, layout isn't always recalculated when it should be. You found one such case. I think the underlying issue is that the Size property is a localizable property as well and the designer fails to fire the required events when it starts a new localization set. Something like that, nothing very trivial.
You'll need to punt this problem and not rely on the Anchor property to get the button positioned correctly. That just takes a one-liner in your UserControl code, like:
protected override void OnResize(EventArgs e) {
button2.Top = this.ClientSize.Height - button2.Height;
base.OnResize(e);
}
I´ve been working for some time on a good OSK solution for my WPF apps, that are running on a tablet. But it´s hard working with the OSK.exe and tabtip.exe, because of several bugs, strange behaviour and no standardized solution to this ordinary problem.
What I (probably) need is a custom textbox control, which inherits from System.Windows.Controls.TextBox, and overrides some methods.
The simple requirements for this textbox should be:
1. When a user clicks in a textfield, the tabtip.exe (or alike) keyboard should pop up at the bottom of the screen (default).
2. If the keyboard pops up on top of the textbox, the contentframe should scroll so that the textbox is visible.
3. When the textbox loses focus, the keyboard should close automatically, except if the user clicks on another textbox.
This seems like pretty standard behaviour right? Well I´ve looked a long time for solutions (there is no standard microsoft way which is kind of weird), and as said I´ve tried making my own but with no luck. For example, sometimes when I try to kill the process, it fails. When I click the close button in the upperright corner on the keyboard, like 5-6-7 times, it closes. The behaviour from PC to tablet is not consistent. The ScrollViewer.ScrollToVerticalOffset(x); sometimes doesent work on a tablet, and so on.
So does any of you know a good solution to this common problem?
I am developing a website, which is going to be accessed by an embedded system with a touchscreen interface. In order to provide the data to an ExtJS combobox, the user uses an on-screen keyboard (such as the add-ons provided by chrome and firefox, which are developed in javascript). When I select the combobox, I can type the first character (the combobox looses the focus when the keyboard button is pressed and then focuses once again when the key in the keyboard is released). When I try to insert the second character, the first one is erased instead of being concatenated to the end.
Is there any way to make sure that the new characters are appended to ones that are already in the combobox?(instead of erasing them).
Any help on this matter would be nice.
Would need to see code like the previous answerer, but make sure selectOnFocus is false on the combobox, or else you would be typing over everything for each letter the way you described it.
I like how MsgBox stops all further processing until it's clicked but I don't like how it pops that little msgbox in the middle of the screen. Is there a way to do something like a msgbox but keep it on my Form (which is always in view) so I can go ahead and click a button on the form instead of having to bring the little msgbox window on top of windows that may be covering it.
I use the msgbox to inform me that a certain situation has happened, which I manually fix and when I'm done I click the MsgBox to continue processing. It'd be nice to have this button right on the form.
which I then have bring to the front if there is a window covering it
That shouldn't happen, but can happen if you display the message box from a thread in your program. The window has the desktop as the parent and has no Z-order relationship with the windows in your user interface. And yes, can easily disappear behind the window of another app, including your own.
There's a MessageBoxOptions option that isn't exposed in Winforms, MB_TOPMOST, which ensures the window is top-most. You'd use it like this:
MessageBox.Show("text", "caption", MessageBoxButtons.OK,
MessageBoxIcon.Information, MessageBoxDefaultButton.Button1,
(MessageBoxOptions)0x40000); // use MB_TOPMOST
But by far the best thing to do is to display the message box on your UI thread. Use Control.Invoke() to do so. That way the other windows of your app are disabled, no way for the user to not notice the box.
Still one problem with this, the user won't expect the box to show up since it is shown asynchronously from anything she does. Which means the box can easily get dismissed by accident when the user just happened to press the Enter or Space key. Or clicked at just the wrong spot. Nothing much you can do about that.
Centering the box in your main window is technically possible, but fugly to do. Check this answer.
Do you mean that the form shall exchange its contents with a message plus an OK button?
This would be similar to the way a text mode interface typically works.
You can make it happen by adding a disabled panel or UserControl with message and button topmost on the form and enable it when you wish to alert the user. However, I am puzzled how to implement the blocking behavior similar to MessageBox.Show() and Dialog.Show().