I would like to remove the ability for a user to close a window in my application from the taskbar in windows 7:
The close button in the image should not be available.
Any suggestions?
You shouldn't do this. Window managing/decorating is left to the window manager, you should rather handle the "close" event in some way, and avoid the applicaiton exiting.
Also, middle clicking (mouse2) on any part of that preview will also close the window, so it's not a matter of just hiding that button.
Related
I have a program that runs over the top of the screen, I couldn't figure out how to allow clicks to the window behind it, so I have decided it's easier to just reactivate the previous window if its accidentally activated. It is not possible to tab into, the only way to activate it is to click the text on it.
So, I'm asking, is it possible to find the window activated just before my program is activated? I would prefer not to do a check every couple seconds or so for the currently active window.
You can add this.BringToFront(); after InitializeComponent(); in the form constructor.
This will bring the form's window to the front.
When I open any dialog in my Winforms application then Windows 10 behaves oddly in these ways:
ALT-TAB no longer displays the list of windows
I cannot switch to hidden applications using taskbar icons - if I select a taskbar icon of a window that is not currently visible (even if it is not hidden by the winforms app) the icon just flashes and then stays highlighted, but is not brought to the foreground. I can use other applications that are visible. As soon as I close the dialog form the other I can use the windows of other applications correctly
If I switch to the application window that is behind the winforms application by clicking on it, I cannot go back to the winforms app either by ALT-TAB or by clicking on the taskbar icon. I can get back to it by minimizing the other application
I'm opening the dialogs with
dialogFormName.ShowDialog(this);
TopMost is set false on all forms and is not set in the code.
I've read about 50 related articles and the only problems seem to be either TopMost is set or ShowDialog is not called with the parent form. I'm not a regular Winforms developer so I'm probably doing something stupid. This is driving me crazy, so I'd really appreciate any help!
Edit: The same issues occur with MessageBox.Show(this, "test"). The issue does not occur with a newly created app just with a single button calling MessageBox.Show(this, "test"). The problem application uses EntityFramework but no other packages and the problem existed before I added EF.
After trying different scenarios I eventually found the issue. In my case I was calling ShowDialog() after a user clicks an item on a ContextMenu. The blocking of ALT-TAB was caused by the following code that attached the ContextMenu to the ListView that the menu was contextually for:
lstList.ContextMenu = myContextMenu;
As soon as I removed that association, the ShowDialog no longer blocked ALT-TAB.
Form.ShowDialog() blocks the parent form until it's closed.
Use Show() to display the form separately without blocking its parent.
I would like to reproduce the behavior of the Google Drive Tray App:
Open a window on click on the tray icon (easy)
Close the window on click outside of the tray icon and current window (?)
Most of the solutions I saw on internet rely on an equivalent of developing key-loggers, is it any other solution to perform this quite usual behavior?
You want to detect the focus of the window/app.
Refer to WPF: Detect when Window loses focus for possible help.
Quote:
Use the Window.Deactivated event. You may be looking for the Application.Deactivated event, which fires only if the user switched to a different application.
I'm implementing a Windows 7/Vista-style notification area ('system tray') pop-up application in WPF. I've written about my work so far here (determining the notify icon's position, disabling resize, etc.).
There is one problem that I haven't solved quite to my satisfaction, however: hiding the window when the notify icon is clicked a second time. If you click (for example) the volume icon in Vista/7 to show the volume control, notice that it is hidden again when the icon is clicked a second time.
I handle the window's Deactivated event to hide the window, and the window is indeed deactivated when the notify icon is clicked. However, clicking the notify icon of course shows and activates the window, so what ends up happening is that the window disappears while the mouse is down and re-appears when the mouse is released (completing the mouse click event).
My first thought was that I might use the notify icon's MouseDown event (I'm using a System.Windows.Forms.NotifyIcon) and check whether the window is visible at that time - if it were, I could interpret it as the user clicking the notify icon a second time to hide the window. Unfortunately, the MouseDown event seems not to fire until the mouse has actually been clicked (in other words it works identically to the MouseClick event), by which time the window has already been deactivated and thus hidden. This seems to rule out this solution.
My next idea (and the approach I've ended up using) was to get the cursor position when the window is deactivated (GetCursorPos) and checking whether that point is within the notify icon's bounds. At the same time, I also use GetForegroundWindow to find the currently active window - if the notify icon is indeed to be clicked, it should either be the taskbar (the top-level window with class name Shell_TrayWnd) or the notification area fly-out (top-level window with class name NotifyIconOverflowWindow; Windows 7+ only). In short, if the cursor is over the notify icon and the notification area is active, I assume that the user mouse-downed the notify icon to hide the window. If these conditions are true, then the following MouseClick event will not result in the window being shown/activated.
This solution has at least one problem, though: if the cursor is hovering over the notify icon and the user presses the Windows key to open the start menu (or uses a Windows key + number shortcut to open an application), my program will wrongly interpret that as a mouse-down to the notify icon (because the taskbar is made active by those keyboard shortcuts). This means that the next time the user actually does click the notify icon, the window will not be shown. (Clicking the notify icon once more will show it.)
I hope what I've written makes some sense; if not, I'm happy to try and clarify the situation further.
I'm interested to hear if anyone has any other ideas about how to solve this.
I suspect that it might not be possible: it seems to me that the native Windows 7 notification area pop-up applications themselves use a simple timer implementation. Clicking on (for example) the volume icon when the volume control is open will only close the volume control if the time between the window deactivation and mouse click is less than about 2 seconds. Holding the mouse down on the icon for a longer period of time and then releasing will show the volume control again, even if it was open before the mouse-down.
That's not how the volume control window works. It disappears when you click anywhere, including the notification icon. The icon isn't relevant. This is a standard Win32 trick, it captures the mouse so it can see clicks outside of its window.
Mouse.Capture in WPF. Not nearly as easy to do because it requires an IInputElement instead of a window handle.
I have an application written in C# targeting .NET Compact Framework 3.5, running on Windows CE. I would like to provide a custom visual cue in a modal dialog if the user tries to interact with its owner window without closing the dialog first.
Is it possible for a modal dialog to receive notifications of mouse clicks on its owner window? The owner window is running in full screen, so it would be sufficient to trap clicks outside of the modal dialog in general.
This is how modality works. When a dialog is shown modally (CE or desktop Windows) that window gets it's own internal message pump. What that means is that wehn you get a message (like a mouse down) outside of your Window, the pump discards it. There's no way for the pump to dispatch that message "up" the chain to another pump (well not without you mucking with both pumps yourself - it's possible yes, but complex, convoluted, and not at all scalable or maintainable).
You could probably use the Control.Capture property.