How do I prevent the main window (where I write something in the textbox) from losing focus?
The application has a couple of pop-up windows that sometimes show up and it prevents me from continuing to write text in the main window (and I have to click back to it).
Thanks for any advice.
You have to create those popup windows as modeless window.
Refer microsoft sample here
Related
I am in a need of hiding the console window, which I quickly resolved by P/Invoking ShowWindow. However, the call hides the console window as well as the taskbar button of the console window. I need the taskbar button to remain visible. I am not, however, looking for a way to minimize the console window. Clicking the taskbar button show not do anything. I tried to use SetWinEventHook and hide the window every time it was activated, but to no avail, as the window calling this function must run message loop in order to receive the events (and my console window didn't, no matter if I set OutOfContext or InContext flag).
Is there a way I can make my console application run, show itself in taskbar, then hide itself (or never show itself in a first place) and just keep running with no window but taskbar button visible?
The normal way to get a button on the taskbar is to create a visible unowned top-level window. So that's no use to you. One possible alternative is to use ITaskbarList::AddTab to add a button. I don't know whether or not this will do anything for an invisible window. Either way you'd need to run a message loop for your window. Even if you could do this the net result would not feel very nice for the user.
I have a .Net 4 application with two windows in WPF 4:
One uses the WS_EX_NOACTIVATE style to prevent gaining focus.
The other is a basic Window.
The "no-activate" window behavior is appropriate as soon as I do not select the basic window (it doesn't gains the focus). But when the basic window is selected, the "no-activate" window can be focused... and gains it when the user clicked on it.
It is as if WPF considered two windows of the same application had the right to give focus even if they are not supposed to.
This behavior does not happen if both windows are WS_EX_NOACTIVATE.
Have you ever been faced with this problem?
I have read this: WPF in Visual Studio 2010 – Part 3 : Focus and Activation, but does not solve it.
Edit: I have been able to get around by using a Popup as a base class for my no-active Window. However, I don't want to have a Popup. Why !? The popup never receives the focus: does someone know why / how ? How can I reproduce this behavior to a Window ?
I try to step into Popup / Window code, but it is not very clear !
Thanks !
Try also giving it the WS_EX_TOOLWINDOW.
http://www.daniweb.com/software-development/csharp/threads/273724/a-form-that-doesnt-steal-focus#
OK. I partially solved the problem.
The Window already got the focus if it is directly selected, but it is not focused when a component of the window is selected.
Just add :
Focusable = false;
to any WPF controls contained in the Window and they will never been focused even if the previous focus is a Window of the same Application.
Suppose, I have the following task.
There is a main application form with numerous buttons; when you click on each of these buttons, you get one more form. The second click on the button should close the opened form.
These forms should not be shown in taskbar, because they are auxiliary. They should not be dialog, because that will block the main application form and prevent user from performing some other operations with the main window or with other forms like the one that is opened. They should be shown above the main form, but not above other windows (so TopMost doesn't suite). When such forms are closed, the main form should be notified, and when the main form is minimized, they should be minimized as well.
How would you solve this problem?
The current solution is based on using hooks. It's not very easy to understand and very difficult to maintain (mainly because I am not experienced in win32). It works fine for about 90% of situations, but in 10% it doesn't.
Maybe, the requirements to forms behavior are to strict?
I would recomment using some window-manager, so each button will tell the window-manager to toggle visibility of form X, if X is not there it will be shown, if it is, it will be closed.
You should be able to configure the windows such that they will not show up in the taskbar.
For the visibility, I am not sure what you mean. When you open a form via a button, it will usually go to front, which should be ok. If you switch the window then, what do you expect? Should the main window always stay in the background or is it allowed to come to the front when focused?
Whenever I have seen applications change such standard behaviors, they failed in some way. Either wrong windows showed up or some were not accessible anymore or the user was just confused because these windows didn't act like all other windows.
It's not a problem. Use the Show(owner) overload to display the form.
An owned form is always on top of its owner. It minimizes automatically when you minimize the main window. No need for ShowInTaskbar. Another window model supported by winforms is MDI, check out the MdiParent property. The child windows are confined inside the bounds of the main window. Also consider using UserControls instead of a form, you can swap them in and out as needed. Or a tabbed interface, using TabControl. Weifenluo's DockPanel suite is a very popular implementation of the Visual Studio style windowing model, supporting windows that can be docked and floating within the main window. Plenty of choices here :)
Here's how most of your requirements can be accomplished:
Set the Owner of each child Form to be the Main Form.
MSDN Quote:
When a form is owned by another form,
it is closed or hidden with the owner
form. For example, consider a form
named Form2 that is owned by a form
named Form1. If Form1 is closed or
minimized, Form2 is also closed or
hidden. Owned forms are also never
displayed behind their owner form. You
can use owned forms for windows such
as find and replace windows, which
should not disappear when the owner
form is selected. To determine the
forms that are owned by a parent form,
use the OwnedForms property.
For stoping a form from appearing in task bar you need to set the ShowInTaskBar property
I am using C# and WinForms to create UI of my application.
I have main window and dialog, which is shown modal to the main window. Dialog window is not shown in task bar. I go to another application and return back by clicking at the main window task bat icon. I can see locked main window but cannot see dialog unless I select it in Alt-Tab. This is confusing for an application user.
How can I ensure showing modal window in this situation? I can see similar but unfortunately unsolved question ALT+TAB in Vista activates main window instead of previously active child window which regards to Vista (and I have Windows 7).
This is probably because you don't use the ShowDialog(owner) overload. You should fret a little bit about the exact reason that ShowDialog() cannot find an owner by itself and picked the desktop window instead. It isn't healthy. I cannot guess why from your post. See what explicitly setting the owner buys you.
Oh, this will happen when the dialog runs on its own thread. In which case ShowDialog(owner) is going to bomb.
It sounds like your dialog is not properly owned by the main window. Make sure you have assigned the main window to the dialog object's Owner property before showing the modal dialog.
I am trying to do something with the Modal dialog in Win7. To do that I need to know which control window has got focus right now by using Win32 API. If I could know which control is now got focus then I can send message to this window to do some specific task.
Could any one suggest me how should I know which control has got focus right now using win 32?
If you want to know which window has keyboard focus and you're only interested in windows belonging to your own thread use GetFocus.
Finding out which window in the entire system has focus requires a few steps:
GetForegroundWindow
GetWindowThreadProcessId
GetGUIThreadInfo