In my application (C#, Windows Forms) I have got a telephone information screen: if there is an incoming phone call a window with additional information to the caller is shown.
This window should open in foreground and should stay there even if the user is writing in another window (so the user still sees the information regarding the incoming phone call).
First I've used BringToFront - but this didn't really work in all circumstances (e.g. when the main application was not in the foreground).
Right now I am using BringToFront and the user32.dll function BringWindowToTop -> which works, but if the window loses focus it is in the background.
How do I implement this behaviour ?
I think you want to set your form as TopMost:
yourForm.TopMost = true;
Related
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'm creating a Windows Forms application in C# that utilizes the SlimDX(a managed wrapper of the Direct3D API) libraries. Problems arise when I try to take the application fullscreen(a state in which the main window covers the entire desktop area including the taskbar).
The Direct3D device window(main window) displays correctly. The taskbar and other overlapping windows are hidden entirely by the device window. The cursor, however, seems to belong to the window directly beneath the device window. This is evident in the appearance and behavior of the cursor. When I click on the device window focus is changed to the window beneath. This is unexpected behavior for any window.
Also, I am able to click items on the taskbar which will cause a change in focus.
I am changing the window style of the device window to 'TopMost and 'Popup'. Also, I am following the utility class found in the DirectX SDK. When I run a sample from the DX SDK, which uses Win32, this problem doesn't occur. Is it possible that the problem is related to my use of Windows Forms?
There is a lot of code involved in my application so I was hoping for theoretical responses as to why this problem might occur. I found a thread here that describes a problem when taking device fullscreen, however, the solution is unacceptable. It was suggested to use a 'windowed fullscreen mode'. Instead of modifying the adapter display mode for fullscreen, the device window would simply be resized to cover the entire screen. This solution would prevent the use of adapter formats, resolutions, and refresh rates that are available in fullscreen mode.
Any suggestions would be much appreciated!
The problem was due to the nature of controls found in Windows Forms. From MSDN:
A control can be selected and receive input focus if all the following are true: the Selectable value of ControlStyles is set to true, it is contained in another control, and all its parent controls are both visible and enabled.
The device window in my application belongs to a parent window and the parent window becomes nonvisible once fullscreen is enabled. Its possible that a conflict arose due to the 'focus rules' above. To test the theory I examined the return value from DeviceWindow.Focus()(derives from Control.Focus())...which returned false.
My solution was to create a form used for the sole purpose of fullscreen mode changes. Now, when I want to go fullscreen I reset the device with the handle to the new device window. All problems solved...
I seem to be running into a dead end here. I have a project that does the following:
just runs and stays in notification area
when user presses middle mouse button, it shows a form
user can then chose whatever from the form, and be happy.
This is working just fine, however what is NOT working is that when the form is shown, it does NOT activate.
Now, prior to me modifying the app.manifest to requireAdmin, it was working fine. Any time the form was shown, boom it was active.
But now that i'm running the form as Administrator, given that I need to be able to control one of our other applications with it (that is ran as admin as well), the form comes up just fine, but doesn't activate.
I have tried:
- TopMost = true inside of the Form_Load method
- Calling SetForegroundWindow with the forms handle on Form_Load
- Calling ShowDialog both on Form_Load and also tried it when the form was built.
- Calling Activate on Form_Load as well as when the form was built
Here's my layout:
Program runs, requires UAC permissions due to the manifest, user agrees, and it kicks off
Only a notification icon appears, shows a nice little bubble saying it's running
Program.cs monitors the keyboard/mouse hooks
When middle mouse button, or any of the keyboard hooks are triggered, it creates a new form object
sets the location of where the form should appear
and then finally shows the form.
Again, without UAC and requireAdmin inside of the app.manifest, this works fine. But once it is running as admin, nope, wont stay in front.
I know that MS has made the SetForegroundWindow requirements much stricter with later versions of windows (Vista, 7, 8), but i really need to be able to make this form show as the top most, active window (like a context menu).
How can i do that properly?
You could split your program into two, a non-admin requiring half that sits in the tray and watches for the middle button, and the half that requires admin permission that you launch when the mouse button is pressed. The non-elevated half could then call SetForegroundWindow or AllowSetForegroundWindow as needed.
If you want to avoid a UAC prompt every time you can cache a COM elevation object via the CoCreateInstanceAsAdmin method and use it repeatedly.
I'll let my application be automated from another application by exposing a net pipe. Basically, application B will emulate being a user using application A, which is a WinForms application.
My only problem so far is that I don't want application B to be able to access functionality you wouldn't be able to access if you'd be an actual user, like clicking buttons in a form while there is a message box or a modal dialog on top of it. This should keep me on the safe side while still giving application B full control over application A.
What I would do is override MessageBox.Show with custom code, as well as every call to any ShowDialog in application A to set some global boolean to false while the modal dialog is being shown that will tell whether the main form is accessible at the moment or not. Then I could either make application B wait or return an error.
But instead of my solution, is there some built in way to tell whether a form has a dialog on top or not? I tried 'Active', 'Focused', even the native GetForegroundWindow but none of them work as I need. To start with, all of them will be false if my application is minimized, which I don't want.
Modal dialogs disable their owners so one simple test would be to check if the window was enabled. Use IsWindowEnabled to determine this. You also need to check that the window is visible with IsWindowVisible.
we would like to build a screensaver that shows the desktop and the running applications but prevents user input by showing the login screen. The idea was to build a windows app with no window or a transparent window. However, as soon as the screensaver gets activated the desktop and all applications are hidden from the screen.
Is it possible to start the screensaver without hiding the desktop?
Thx,
bja
Is it possible for you to implement this as something other than a screensaver? I'm assuming that the Windows API does have a method that allows you to tell how long the computer has been idle (otherwise, how does the stuff that manages screensavers do it?), so if you use that you could just set up your application such that it's continuously running as a background process, and will pop up a modal dialog box (or your idea of a transparent window) or something that prompts for the user's login info when the computer has been idle for a certain amount of time.
Why can't you just grab an image of the screen when the SS kicks off. Then use that as the backdrop of your SS.
Vista has a bubbles screen saver that just starts putting bubbles on the screen. Not sure how they do it.
You are better off just creating a full-screen application with a transparent window that starts up on a timer like a screensaver. The screensaver functionality while similar to what you are doing, functions much differently.
As an alternative suggestion, you could always use a service (or background app) to gather the information you want these monitoring tools to display, or even just to grab periodic screenshots of the (hidden) desktop, and then have your screensaver query that app to get the data it needs to display.
That way, you get the benefit (the secure desktop, the usual Windows login sequence, etc.) of a screensaver, but still get to display what you need to.