I'm writing a HUD style application (just text, zero user interaction) and I want my text / water marks to always be visible regardless of other apps on the system.
I made myself a WPF popup and topmost but if other applications come along that want to be topmost as well they seem to supersede mine.
Is there win32 support to override this and effectively watermark system / appplication wide?
Nope. From Raymond Chen's blog: What if two programs tried to do this?
"How do I create a window that is never covered by any other windows,
not even other topmost windows?"
Imagine if this were possible and imagine if two programs did this.
Program A creates a window that is "super-topmost" and so does Program B.
Now the user drags the two windows so that they overlap. What happens?
You've created yourself a logical impossibility. One of those two windows
must be above the other, contradicting the imaginary "super-topmost" feature.
Related
I develop with VS2010 in C# and I would like to create a WPF Window which have a taskbar text different from the Window title.
The property Title set both the window title and the taskbar text. Is there a way to set them separatly?
First, let me reinforce what Cody Gray said in both his answer and comment - this is non-standard behavior, and you should have a darn good reason for doing this.
That being said, I would take a nearly opposite approach to Cody's point #1. I would create a window WindowStyle set to None, and recreate the title bar (which could include the icon, your "pseudo-title," minimize, maximize, and close buttons, and perhaps even the standard Windows menu. You will also need to handle resizing (which can be done by setting ResizeMode to CanResizeWithGrip, but it adds a Grip control to the bottom of your window, which makes it look slightly different than a "normal" window).
The Title property of this window would then be the Title you want to show in the Taskbar, and the "pseudo-title" in the title bar you create would just be a Label or TextBlock bound to whatever you want your window to show.
It is a little complex, but really not too difficult to do. You will probably run into some Gotchas along the way (for instance, how the Window looks on different OS's or with different Windows themes applied). The nice thing is that it requires no Interop, and a majority of it can be attained using XAML only.
There are lots of examples online (here is one I picked at random).
Again, you'll have to decide if it is worth the effort to create a non-standard behavior. YMMV.
Basically, you have two options:
Draw the taskbar button yourself, rather than letting Windows handle it. This is actually reasonably simple, as far as owner drawing things goes.
Manage two different forms/windows simultaneously. You'll need to create a hidden main window that will appear on the taskbar and own your second window. Your second window will be visible, display its own caption on its title bar, and contain your actual user interface, but won't show up on the taskbar (set its ShowInTaskbar property to "False"). You'll have to write code to show the second window whenever the first one is activated using the taskbar.
I recommend that before starting down either one of these paths, you carefully consider whether you really need this "functionality". It's difficult to tell what goes with what if you have what is effectively one window with different names in different places.
try to use this:
http://www.codeguru.com/forum/showthread.php?t=3833
in conjunction with
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/6b97a6de-0480-4339-8ed0-cb7cdb27bd83
The first one works fine for me in classical .NET form application when I have made window without title bar and want some text in task bar icon.
The second one you need to handle low level WIN32 messages in WPF window (but this works only for top level one).
This function is like the "always on top", it is something like always occupy the right most area.
I wrote a software that the software will pull some messages from server periodically, so I want to put it into the right-most area of the screen, and never be overwriten by other windows unless the user press the minimize button.
So it means the other windows, even the maximize button is pressed, will only occupy the left side of the screen(the space that not be occupied by my software).
Is it achievable in MS Windows?
Sounds like the support for Application Desktop Toolbar is what you want:
An application desktop toolbar (also called an appbar) is a window that is similar to the Windows taskbar. It is anchored to an edge of the screen, and it typically contains buttons that give the user quick access to other applications and windows. The system prevents other applications from using the desktop area used by an appbar. Any number of appbars can exist on the desktop at any given time.
The best you can do is to make your window "always on top". You can't reserve part of the desktop exclusively for your application.
When I set focus on a text box, on a forms load event in Windows Mobile 5.0, the Windows tool bar appears even though my form is maximized.
When I do not set the focus on the text box the form opens maximized. I do not want the windows tool bar appearing.
How do I prevent this from happening?
TThe start bar in WinMo is actually not part of your app - it is a separate process managed by the Shell and it really wants to always be on top. Trying to get your app above it goes against the design goals of WinMo (though it's a common thing to want to do).
I'd recommend doing some searching and reading on "kiosk mode" to garner what knowledge you can from others who have been down this road, but what you're seeing is that the StartBar is getting set topmost.
Raffaelle Limosani has a pretty decent blog entry that covers kiosk mode, so it's a good place to start (take a look at the other blogs he links to as well).
The toolbar at the top is actually a separate window, and it has a habit of appearing when not wanted over top of a full-screen ("kiosk" mode) app. For example, if you ShowDialog a second full-screen window from the first, the Start window flickers up for a split second before going away.
The only way I ever found of dealing with it was to hack into the API and actually make the Start window hidden while my application was open. This is a big potential problem, because if your app crashes without making the Start window visible again, it will stay invisible until you reset the device (or run you app again successfully).
I'd advice against doing this unless you absolutely have to. As ctacke points out, this would be an example of an app not playing nicely with Windows Mobile.
Assume i have an empty form 100px by 100px at 0,0 coordinates on the screen. It has no border style. Is there any way to have this positioned BEHIND the desktop icons?
I would assume this would involve the process Progman because thats what contains the desktop icons. But no matter what i try... getting window handles and changing parents etc, i cant seem to get the window to appear behind the icons.
Any ideas?
Essentially you want to draw on the desktop wallpaper. The desktop hierarchy looks like this:
"Program Manager" Progman
"" SHELLDLL_DefView
"FolderView" SysListView32
It's the SysListView32 that actually draws the desktop icons, so that's what you have to hook. And you can't just stick your form on top of it; you have to grab a WindowDC to that handle and draw on the DC.
It can be done - it has been done, but you're going to be using a lot of interop. Forget about doing this with a traditional Winforms Form. I don't think I've even seen it done in C#, although somebody did it in python, if that helps. I'm not a python coder myself, but the code is pretty short and easy to understand.
There is a solution to this problem, at least for Windows 8. I postet it in form of an article on CodeProject, so you can read about it here:
http://www.codeproject.com/Articles/856020/Draw-behind-Desktop-Icons-in-Windows
This works for simple drawing, windows forms, wpf, directx, etc. The solution presented in that article is only for Windows 8.
Google-fu led me to this MSDN forum question:
http://social.msdn.microsoft.com/Forums/en/winformsdesigner/thread/c61d0705-d9ec-436a-b0a6-6ffa0ecec0cc
And this is a blog post regard the major pitfalls with using GetDesktopWindow() or dealing with the desktop handle (as per your other question: C# Position Window On Desktop)
http://blogs.msdn.com/oldnewthing/archive/2004/02/24/79212.aspx
You also don't want to pass GetDesktopWindow() as your hwndParent. If you create a child window whose parent is GetDesktopWindow(), your window is now glued to the desktop window. If your window then calls something like MessageBox(), well that's a modal dialog, and then the rules above kick in and the desktop gets disabled and the machine is toast.
Anyway, I suspect that it probably CAN be done, but whether you should is another question.
If I have a Winforms control, is it possible to tell if there are windows (from any application) above it? Basically, I need to know what parts of my control are actually visible on screen.
If you're happy to P/Invoke, the EnumWindows function enumerates all top-level windows on the screen giving a HWND; from that you can get the non-client rectangle (GetWindowRect) to compare against your form bounds.
This won't account for windows with non-rectangular opaque areas (fancy skins for media players and the like), so you may get false positives for such a window occluding your control.
In the Win32 API, you can use WindowFromPoint to determine the topmost window at any given point. This won't tell you if your whole control is visible, but if you test all 4 corners it gives you pretty good odds.
Why do you want this information? Typically when people ask this question it's because they want to ensure that their UI is in the foreground if it's not. And that usually is what happens just before they try to steal the focus away from the application which does have the foreground.
And foreground stealing is very, very, very bad. People get REALLY upset when applications steal focus.
Having said that, either of the two techniques above would work - I think I'd prefer the EnumWindows/GetWindowRect/IntersectRect technique in Steve Gilham's answer.