I'm working on a small internal use utility ATM, and I'd like it to appear in the system tray rather than the task bar. I'd also like it to be minimised there from startup rather than loading the main form. Also I'd like to know how to customise the left click action and right click menu on the system tray icon.
I'm failing to find a detailed walk through on this, I'm pretty new to C# (and in fact Windows in general!) so not 100% sure what to search for!
Read this article, it's a good tutorial:
https://www.simple-talk.com/dotnet/.net-framework/creating-tray-applications-in-.net-a-practical-guide/
The basic answer of using a NotifyIcon is correct but, like many things .NET, there are a host of subtleties involved in doing it right. The tutorial mentioned by Brad gives a good walk-through of the very basics, but does not address any of these:
Does closing the application from the system tray properly close any open child forms?
Does the application enforce that only one instance of itself may run (applicable to most, though not all, tray apps) ?
How to open WPF child windows as well as WinForms child windows, if desired.
How to support dynamic context menus.
The standard NotifyIcon exists in WinForms space; can I do a pure WPF solution? (Yes you can!)
I just had an article published on Simple-Talk.com that addresses these points and more in great detail, providing a tray application framework that you can put to use immediately, plus a complete, real-world example application to show everything in practice. See Creating Tray Applications in .NET: A Practical Guide, published November, 2010.
Related
I noticed for a few updates of Skype now that if you start 2 or 3 instances of Skype, in the windows taskbar they appear as separate windows and you can drag them individually as opposed to other applications when they are "glued" together and you can drag them all at once.
My question is how can I implement the individual appearance in my application and is it possible from C# or through winapi?
The shell groups windows in the taskbar using each window's Application User Model ID (AppUserModelID).
By default, every window generated by a given EXE (even in different processes) shares a system-generated AppUserModelID.
You can give each process its own AppUserModelID by calling SetCurrentProcessExplicitAppUserModelID. From your description this is probably what Skype is doing, though I haven't checked.
You can give each window its own AppUserModelID by setting a different PKEY_AppUserModel_ID property on the windows.
Note that these IDs are required to have a particular format:
CompanyName.ProductName.SubProduct.VersionInformation
Raymond Chen wrote an article about this, and it's also worth reading the documentation I linked to.
I'm not aware of WinForms having explicit support for this, but you could certainly use interop to call the Win32 API directly.
I've created WinCE 6.0 image without taskbar. So all app's maximized to full screen.
I want create my own app like taskbar. I want add only few buttons to this taskbar. But I want That other app in their maximized mode don't hide this task bar. And I don't want make my all top most, because they hide some part of other app.
How can I make my app like task bar?
You could modify the existing taskbar in the current Explore shell (source at %WINCEROOT%\PUBLIC\SHELL\OAK\HPC\EXPLORER\TASKBAR\taskbar.cpp or is that's not flexible enough, you could create your own Shell and create your own "taskbar-like" behavior however you'd like.
In either case, remember to clone the code to your own BSP tree! Don't modify the public tree.
The approach I've taken and works is to write a custom kiosk shell based on the explorer.exe code built in visual studio. You could use platform builder as well, kind of the same tool now a days. Looking back I'd say it was a bit heavy handed and it took a little bit of refactoring to CTaskBar and explorer to subclass CTaskBar to our needs, but it produced a shell that we could lock and unlock with complete explorer capabilities. Perhaps a lighterweight approach would be to register your app's window as the taskbar (sorry the system call escapes me) and handle the taskbar specific messages in your winproc?
I have an idea to write a multimotor taskbar application in c# for windows xp. So, does anyone have any information how
to put a taskbar on the second
monitor,
to make it use windows styles,
to prevent aplications running on the
second monitor to appear in default
taskbar,
so on...
Any help would be ...helpful )))
You can P/Invoke SHAppBarMessage() to create a task bar. The APPBARDATA.hWnd you'll need could simply be the Handle of a Form class. Anything goes as far as what you display.
Getting the notifications you'll need to make the task bar display active windows is going to be a whole lot more difficult. You'll need to use the global WH_SHELL hook, set by SetWindowsHookEx() to receive the notifications you'll need. You cannot set this hook in C#, it requires an unmanaged DLL that you can inject into a process. You'll find crucial help in this project.
Getting the Windows taskbar to not do its normal job is going to be impossible unless you somehow find the undocumented information you'll need. Microsoft doesn't document this for a good reason, the taskbar is an important part of the way they innovate on the Windows look-and-feel. Quite visible in Win7. They don't want any code to take a dependency on this, they'd have a near-impossible job of keeping the next version of Windows compatible. I'd have to recommend you completely disable the Windows taskbar and replace it by your own.
Anyone know of an efficient way of detecting movement of any windows currently open on a windows system? I need to detect a window's movement, determine if it collides with my applications Form, and bump it out from underneath if necessary.
I know I can scan through an enumerated list and check each window -- but that is way to intensive to perform constantly.
Background:
I have a taskbar-esque application that docks on the side of a user's screen. When the "Always on Top" feature is on, maximized windows will take up the remaining available space without covering the toolbar, as expected.
However, if you drag a non-maximized window over the toolbar, the application goes behind the toolbar (also expected), but you can no longer grab onto the title bar to move it back -- the window is stuck unless you disable "Always on Top" and then move it. So, I want to bump the window out from underneath.
Although not a direct answer, one possible solution to this is to create your application as an application desktop toolbar rather than a regular window. From the docs:
An application desktop toolbar(also called an appbar) is a window that is similar to the Microsoft Windows taskbar. It is anchored to an edge of the screen... The system prevents other applications from using the desktop area occupied by an appbar. (emphasis added)
This may not be a great fit for your scenario because it is oriented towards COM and unmanaged code rather than managed apps: however see this CodeProject article for info about using this feature from C#.
Failing that, you could try installing a hook (see SetWindowsHookEx) and listening for move messages but this is pretty low-level...
Try checking your PaintEventArgs ClipRectangle ..
(edit: and/or WindowFromPoint shooting match)
You can get notification of window movements using a CBT Hook: http://msdn.microsoft.com/en-us/library/ms644977(VS.85).aspx
http://www.codeproject.com/KB/dialog/FindWindow.aspx?msg=3262771
"FindWindow By Jörg Bausch"
Will get you the external (not your app's) window ID (IntPtr) the mouse went up over from within your C# application. For the desktop, and everything else on the desktop, it will return the same pointer (you can't distinguish, using this code, between as mouse-up on a folder, the desktop, the Recycle Bin).
http://www.codeproject.com/KB/cs/globalhook.aspx
"Processing Global Mouse and Keyboard Hooks in C# By George Mamaladze"
Will allow you to create GlobalHook for keyboard and mouse-events in C#. I've used it recently in VS 2010 beta 2 : it is NOT USABLE compiled against FrameWork 4.0, but does compile and work okay against FrameWork 3.5 and lower. If you download only George's demo app, be aware the download doesn't include the required dll, and will fail when you launch the .exe file (which I have brought to George's attention).
I've never worked with a "desktop application toolbar;" I hope this is relevant.
best,
I wrote a console program in c# that takes up to three files as input, and does some data calculations on them.
I'd like to make a simple frontend that allows the user to easily
import files - basically choose up to three files to be routed to the backend code
change settings - I have about 10 settings that I'm currently storing in an app.config file. maybe a simple settings box would be nice
see what's going on - the console program shows some status messages that might be useful to display on a GUI
I have practically no experience with windows forms or GUI design, so I really don't know where to begin. I compiled the backend stuff into a *.dll and am currently playing around in design mode of sharpdevelop...but i really have no idea how to get the two to work together.
any pointers would be greatly appreciated!
The usual pattern, in cases like these, is to make the main features of the application into a class library and call that from a wrapping executable, such as a console app, winforms app or webforms app (if possible). That way you can easily adapt the interface as needed and simply route input and output to and from the class library.
Edit: I realize this isn't a very indepth answer, but I hope it helps to get started at least, together with any other answer that may arrive.
If you want to get started with GUI design in .NET, I recommend you choose WPF (Windows Presentation Foundation). This is the latest technology released in the UI/graphics area by Microsoft and is where everything is heading now. (Windows Forms won't be obsolete for a long time, though it is surely but slowly becoming deprecated.) I noticed however that you are using SharpDevelop, which doesn't yet have real support for WPF (as far as I know), whereas it certainly does for WinForms. If there's any chance you can use Visual Studio, I recommend you begin by learning WPF. You have the advantage of not being confused by previous experience with the styles and methodologies of WinForms, so it would very much be the right way to go.
Whichever you wish to learn, the Getting Started page of WindowsClient.NET (the official MS site for both WinForms and WPF) would be a great resource. There's also a few MSDN articles on getting started with WPF.
Hope that helps.
Have you tried Visual Studio Express editions? They're free and come with a designer for either WinForms or WPF applications.
As a first pass you'll need 3 text areas for the filenames, with associated buttons to bring up the file open dialog (it doesn't actually open the file just returns the filename).
A label to display the status - updated from your worker code.
Then either the various radio buttons, check boxes etc for your configuration settings.
Oh and don't forget the "Start" button to set off your process.
If your process takes a while you ought to use a background worker thread. You can then implement a "Cancel" button to safely abort the process and tidy up if it goes wrong.
There will be optimisations and reorganisations that you can do once you've got it working.
Your question is quite indistinct. If you're asking about working with GUI, you should read some book on Windows Forms.
And if you're asking about how to put your dll in your new windows forms application, then you should just add a reference to it in winforms project's properties and then use classes from dll's namespace.