Is it possible to run applications on the Windows Desktop? I mean... that it can only be seen in the system tray, and it should be able to run alongside the desktop.
I have no idea how to code it, please help me. I'm kind of new to these things, I am supposed to create something like a "Stardock Fence".
I have seen some examples, but they seem buggy, any strong alternative I could use?
Process.Start() can be used to start a windows application/console app from another win application. There are parameters that allow you to optionally hide the UI as well.
You want your application's windows to be always-on-bottom. In other words, your UI will always appear to be beneath any other open window and just above the Desktop's icons.
To accomplish that, see these related questions.
Once you have a window always on the bottom of the z-order, you'll probably want to remove the non-client window chrome (titlebar/min/max/close buttons) so that your UI can look like a more integrated part of the Desktop. There's plenty of examples around; Googling is left as an exercise for the reader.
Not entirely sure what you mean by background. I expect you mean a Windows Service which is a project type in visual studio, or you might (less likely) mean running a background thread.
Actually, if you want it in the system-tray, you don't want it entirely in the background.
If it was to be fully "in the background", then your best bet is to have it as a service.
System tray icons need a window, but you can just make it non-visible and non-taskbar and that's fine.
A common combo is a service that does the actual heavy-lifting, and a hidden-window application with a systray icon that reports on the service's status (possibly making that same window visible when further interaction is needed).
You want to run your application in the background? Is it on a windows machine? If so then you want to look into running your application as a windows service. Here's an msdn link:
Introduction to Windows Services
There's examples in the article I think - if not it's a good starting point. You can configure services to start automatically on startup of the machine etc. Your application will then run in the background.
Basically you craete your application as normal and then host it in a windows service rather than say a console app or a winforms app.
Related
Is there anyway to find what kind of window is opened on the desktop in real time?
It may need C# or C++. What I have found right now is to use C# Process.GetProcesses() method to find the opened windows on desktop.
But the output cannot be changed when the users have opened any new windows. So, is there any method I can use to track the opening windows in real time?
Also, is there any way to track the mouse movement on a specific window by using our web service?
Many many thanks!
I do agree with tnw that this sounds sketchy (possibly an example would be useful to help here). However, you want to look at the windows api calls:
GetForeGroundWindow
GetCursorPos
The first will only give you the current window, and not all open windows, but it sounds like this is what you really want anyway?
Source code to Windows keystroke logger that does this (in C++): http://16s.us/16k/
Edit: It shows the open window the user is typing in (in real time), but not all open Windows, only the active window in use.
I'm working on a .NET 4 WPF application, and just the other day, came across a very peculiar bug. I have three Windows 7 Pro machines involved: laptop (1366x768), desktop (1680x1050, multi-monitor), and the remote machine (resolution unknown). Our application is installed on the remote machine.
Consider the following events: I remote desktop into the remote machine from my laptop, start our application, and launch a particular feature (an mdi child) within the application. If I connect to the same remote session from my desktop (thus closing the session on my laptop), this feature within my application becomes completely unusable. By unusable, I mean combo box drop downs are showing in the top/left corner (much like what's described here), other controls aren't laid out correctly, and some controls don't even show at all. Mouse coordinates appear to be off in that clicking certain controls no longer invokes the appropriate actions. It's the strangest thing I've ever seen.
If I close the application and launch a new instance on my desktop, things work great. Also, it only seems to happen when I launch the feature on my laptop, then move to the desktop. Never the other way around.
I wish I could show some code, but I don't really even know where to start or what to show. I can say that it only happens on certain features. Some features handle the resolution change perfectly.
Has anyone else seen these types of symptoms? Or know what could cause them or how they could be fixed?
This is a little embarrassing. After a few hours of "process of elimination", I found that another developer had added some unmanaged code to automatically maximize the window. The approach they followed is documented here. This approach does not work through remote desktop sessions. Lol.
I've a small c# application which does some sync between two libraries.
This has to run regularly, and the use of scheduled has been choosed.
So for now everything is working fine, except one thing, when the task is scheduled, I got a console windows which opens.
Is there any way(in the scheduler or in the application) to don't have any windows visible when the program is running?
My sync library can put in what I want.
(what if instead of using a console application, I create a windows application, without any windows, and the code started in the app.xaml.cs ? Is this a good idea? I've the impression this isn't the right way to do it).
Thank you!
In the Project Properties window, Change the output type from Console Application to Windows Application. Your application will still run, but it will have no window at all. You might also consider making a Windows Service instead.
Set up the task to run as a different user, then it won't popup to the currently logged in user. You could run it as SYSTEM i.e.
Yes, using a Windows App without any windows is the way to go. You can even show a tray icon in an app without windows if that might be useful.
I am trying to do my winform application dock and follow another application, like IE or word. My full plan is run the program underground and then this specific application is running, my winform will maximize and dock, will follow if moved, minimize if this application is minimized.
Can you guys show me some ideas about how to do it?
thanks
You will have to get the messages send to the other application and analyze them. Here are some resources on window system hooks on MSDN and in the MSDN Magazin. So you will have to use good old P/Invoke because there is no managed API.
Hooks can work; however, both the programs you mention (IE & Word) provide APIs that allow you to customize the user interface. I would first look there. BTW, Due to IE's restricted environment your going to have a lot of trouble getting the standard hook APIs to work.
I have a GUI C# Windows form program that I would like to start as a service when the computer starts and perhaps have an icon in the system tray that when clicked maximizes the program. Is this possible without major rework?
Thanks
Windows Services cannot have a GUI, at least not directly. You will have to separate your application to a presentation layer/process and a service layer/process:
The presentation layer will remain a WinForms application
The service layer will run as a Windows Service
The two of them will have to communcate with each other with some means of inter-process communcation, like named pipes or sockets.
You can use a third party app, such as FireDaemon (http://www.firedaemon.com/), to start any program as a service. There are many options available in FireDaemon, such as form visibility, restart on failure, etc. However, it will not automatically create a tray icon for your app. So your app will have to be changed to have its own tray icon functionality and FireDaemon will just start the program and manage the process.
FireDaemon costs about $40 (USD). I imagine there are many other similar applications available.
I would first look into creating an actual service project as mentioned by other answerers, but keep this approach in mind. It has worded well for me in a handful of situations.
It depends on how the code is currently written. I have several WinForm apps that double as services, but the bulk of the work I have separated into another assembly. My solutions for those apps generally have 3 projects: WinApp, Service, and Library (I'm oversimplifying here).
If you feel that your WinForm app could make a good service then you probably have your code in such a state that you could probably separate it out easily enough. Adding a service project is pretty simple, adding the installer for it is a little more challenging but still well documented. The trickiest part is making a deployment package for it that installs the service properly, but again... its well documented as long as you know you need to look for it.
Edit: Just to clarify, in general I wouldn't consider this a major project.
You can write the code to have it run as a service, but I think the more important question is, what does it provide? There are ways of minimizing an application to the tray, and you can start said applications at launch to the system tray.
This is the link that I always refer back to about doing windows services. It is WCF based, but I think with a little modification you could make it work for you:
http://support.microsoft.com/kb/317421
As to minimizing to a tray, there's an excellent answer in this question:
What's the proper way to minimize to tray a C# WinForms app?
You could use Task Manager within windows and setup a task that would execute your application's .exe per windows boot.