I've been googling a lot for this one and I can't seem to find anything. Maybe it's the way that I'm wording it. So basically what I'm looking to do in C# using Windows Forms, is create a form and have it essentially take the shape of the taskbar and do the same functions as the taskbar, but it will sit above the task bar or at the top of the screen.
It can't be "ON TOP" (I'm not trying to block user buttons like the close button of a program they are using).
Autohide would be a plus.
This is the main thing I'm after:
It needs to act just like the task bar. When you maximize any other window, the taskbar does not go over the top of the window, even though it is set to "on top".
You'll want to use an Appbar to do this:
http://msdn.microsoft.com/en-us/library/cc144177.aspx
For more information, check out here and here and here.
If you don't want to deal with C++ and Native Code (as #FKunecke correctly proposed) then you'll not find anything predefined for this. What you can do is create a form for your bar and make the visualization calculations by hand, then you can set the screen location of it. That's all. Not forcing the bar form to stay on top will not hide the other app forms so you'll get that for free.
Now, to fully implement what you want there are some problems you need to deal with, such as Taskbar location and height. Then you'll need to use some native code tricks.
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).
For a while now I have attempted to get into UI design with WPF. My main goal is to create a good-looking application in a borderless window, like for example:
I made this example using the MetroUI framework. While this framework does the trick on borderless window functionality, it also does way too much for my tastes, custom controls, skins, animations, etc. I just want a borderless window and decide everything else myself.
I've searched stackoverflow a lot, and tried a fair amount of frameworks, but nothing seems to suit my needs.
Basically, I would like to have a borderless window with FULL windows functionality (drag to sides to pin, only show shadow if operating system settings has it on, etc etc).
Putting WindowStyle to None but keeping AllowsTransparency at False in order to preserve the original window chrome makes most if not all of the functionality I am seeking for work. However, the obvious problem here is: the window chrome is still there.
This looks like this:
To finally ask my question:
Can we keep all the current functionality that this window chrome provides, but somehow make it invisible (yet keep the dropshadow it provides) ? I can live without the dropshadow but it would be a nice bonus.
Or to ask a more broad question: is there any framework / pre-made project, that simply ONLY handles making a borderless window work properly and no other additional controls, skinning, ... ?
The more time I put into this the more it seems making borderless windows with WPF is simply incredibly clunky and I am getting rather unmotivated on my entire project because of this.
Thank you
See my answer on the following thread, it pretty much sums up all the window issues at once. Hope it helps!
WPF Borderless Window issues: Aero Snap & Maximizing
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.
Simple question. How can I change the icons of the close, minimize, maximize buttons. Can I do this in Winforms and WPF?
These Icons, the caption, and the border on your window are all drawn while processing the WM_NCPAINT message. So, the way you take over drawing this is by handling this message.
But you don't have access to the state information about the icons (i.e. which button you should draw in it's pressed state because the user is currently clicking on it.). You dont even know where exactly the mouse handling code thinks these icons are.
So to take over non-client paint, you also need to take over non-client mouse handling, and the whole problem just snowballs until you've written thousands of lines of code and your window still doesn't behave quite right when the user tries to drag it, etc.
And that's in unmanaged code, in managed code (C#/.Net) this is even harder because you also have to do interop to get to some of the APIs you need to use.
So the answer is: Yes its possible, but its harder in WinForms and WPF than it is in C++, and those that have attempted it are all bald now.
The real answer is that you shouldn't do this. Users expect all applications to work and look the same. Making them try an figure out what spiffy new icon you use means minimize is likely to make them unhappy.
Doing this isn't difficult but it is a lot of work - you have to basically replace the window frame and handle everything yourself, there is a lot of functionality in the default window frame you have to rewrite - you also have to write different code for Vista/7 with Aero enabled.
In WPF you use the various techniques in http://blogs.msdn.com/wpfsdk/archive/2008/09/08/custom-window-chrome-in-wpf.aspx
In WinForms you use the same basic techniques but I don't know of a page that summarizes all the details like the link above.
In wpf, you can set WindowStyle="None" for your Window and then set a custom TitleBar for that, with minimize, maximize and close button. I have done this earlier. You need to do some event handling to perform minimize, maximize, close, drag etc.
Yes, you have to create your own window style. Refer to FluidKit, GlassWindows for example.
If you want to control the look of those buttons, you'll have to create your own. This is one value of using Windows features to write windows applications (they come with a standard look and feel).
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.