This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Writing a Windows system tray application with .NET
I want to develop a tray application. What this should do is it must keep looking for recently modified files.. once a file is get caught it a copy of that file to the web server. Therefore, user will be able to login to the website and later on user will be able to download those backing up files. what i want to know is how do i develop the tray application? Do i have to write a windows service for that? If so, i need a tray application to control the service (tray application must have sfunctionalities to start and stop service [Backup service], An option to choose the file extensions)
I'm using c#.
Thanks a lot in advance.
Sounds pretty straightforward.
Create a basic WinForms app. The app's main window should start "minimized" and should not show in the taskbar. But, it should have a "NotifyIcon" component, which allows the app to show in the system tray. Double-clicking the NotifyIcon would restore the window, show the window in the taskbar and hide the NotifyIcon until the window is minimized or closed again.
This application can do the file watching on its own, or it can edit the configuration used by a Windows service; either way would work. Either way, you need to set up a FileSystemWatcher (or several of them) that monitors files in the directories the user wants you to check. When a FileSystemWatcher sees a file change, it'll fire an event that you can handle by performing the upload to the web server.
Just as an aside to the whole design; if you're implementing an online backup system (which it appears that you are), I would make sure that the user has access to several past iterations of the file, in case they want to restore a previous version. You should also have virus-checking; the last thing a user would need is for a virus to wreck their files AND for your backup system to have backed up the wrecked files.
I personally wouldn't make it like a Windows Service, but would choose a simple application that "lives" on behind of system. It's easier to maintain and update, uninstall from the client (on his request). In short, for something simple I wouldn't go for Windows Service.
I would add a sys-tray component, with some menus.
You can have a look at WPF NotifyIcon from Philipp Sumi.
One of menu items can have an item that registers executable to run on startup of the OS.
You can achieve that with kind of code:
Microsoft.Win32.RegistryKey key = Microsoft.Win32.Registry.CurrentUser.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true);
Assembly curAssembly = Assembly.GetExecutingAssembly();
key.SetValue(curAssembly.GetName().Name, curAssembly.Location);
If for some reason, cause it's not very clear from your post, your application, indeed, goes to manage some serious amount of data on considerable production environment, go for WindowsService and manage all related to it stuff.
Hope this helps.
Related
I need to develop a project using Visual Studio. The project will run constantly in the background, checking a file path. When the image is uploaded to the file path, the application will display the uploaded image as a pop-up on the computer screen. The application will not be triggered by a user. It will constantly run in the Background, checking the file path. Which project template should I use for this? I hope I was able to explain.
I thought of writing windows service. Because it can run in the background. But I couldn't open a picture with it
I see you're a new contributor, so it would be better if you posted a bit more context of what you have already tried. For instance, providing a minimal reproducible example. I ask you this because the way to write Windows Services or Console Applications in .Net Framework and .Net Core (and subsequent) are different. How to ask a question?
That being said, a windows service, by concept, does not have UI and is not allowed to have one. They're designed precisely to only run on the background, without user interaction (at least since Windows Vista).
These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface.
From Microsoft Docs
So it seems that you need to either write your application as a different kind (for example), or create a secondary application that somehow communicates with your windows service. The decision would be up to you based on your requirements and/or possible limitations.
There are some possible alternatives in this possibly related question as well.
I have a Win UI 3 app that checks it here is a new update available, it dowloads the installer, but is it possible to execute such installer without closing the app?
How execute the installer from the code?
How to handle tha installation from within the app without closing?
Is it to complex? or should I just have the user do it manually?
NO. The executable is in memory (and may have locked files or resources). In order to get an update it will have to be relaunched. If your code is modular, think plugins, these could be updated in place.
Most applications launch a helper app then close themselves, because Windows usually blocks changes to executable files that are in use.
The app might pass its own process ID to the helper app so that it can wait for the process ID to disappear before attempting to update the file.
If not, the helper app might scan the process list for the EXE name, and pop up a message asking you to close the main app. It repeats this until there are no instances of the EXE in the process list.
I'd like to know with a .net language(C# or VB) if I can detect when a new app is launched.
e.g: an user opens Firefox.exe from desktop (not from my app!), is it possible to detect this event from my app? Also is it possible to "pause" it before running it?
So for example when an user double-clicks an application, my app comes first and then it displays a message if he is sure to open that file with Yes and No buttons.
I don't need all code, I just need to know how to catch that event that can happen anywhere in system.
There are some Windows API functions in user32.dll that you can use in your .NET application through System.Runtime.InteropServices.DllImport to get the information you're looking for. Take a look at GetWindowThreadProcessId. For sample code, see http://www.c-sharpcorner.com/UploadFile/satisharveti/ActiveApplicationWatcher01252007024921AM/ActiveApplicationWatcher.aspx. Because applications tend to become active when they are launched, you'll find that the techniques used in that example will cause it to detect new app launches.
That doesn't answer the question about letting the user confirm whether they want to run an app, but it will get you part of the way towards what you are trying to do.
I am currently writing a windows store app, where I want to offer the possibility to open a specific file directly, if there is a known app to open it. Otherwise I want to hide this option.
The common way to open a file is using the Launcher.LaunchFileAsync(IStorageFile)-Method. It opens the file directly or offers a list of possible apps to open the file. So it sometimes knows about the apps to open the file and sometimes not. But is there a way to find out whether there is such an app installed or not programmatically, so that i can decide whether to hide the open button?
This isn't supported for Windows Store apps.
The general model is to "keep the user in control" which means if there isn't an app already available for file or URI association, they have the option to find one in the Store to complete the workflow. This is also there, I believe, to encourage acquisition of new apps as well.
Put another way, association launching is demand-driven, wherein the user is invited to find apps exactly at the moment they need them, rather than separately looking for apps that somehow configure the device and then enable functionality in other apps (like enabling certain file types).
In the model you suggest, wherein an app working with files hides unassociated file types, ask yourself this: how would users ever enable a file type? That is, they could see a file on their system using the file explorer (or another apps). But in your app they don't see it listed. This in itself a point of possible confusion--I can see comments in your reviews that would say "How can I get these files to appear?" Your only answer would be "Well, you have to first install some other app that can handle that file type." Customer: "How do I find those apps?" You: "Um..." because the Store app doesn't give you a way to search by association support...maybe you can get lucky with keywords.
Or, let's say the user happens to acquire some other app from the Store, or a desktop app, which means that magically those files start to appear in your app for not clear reason. Customers are bound to ask why this happened.
In short, the model you suggest could potentially create a disconnect between what's on the file system and what shows in your app, which would be hard to reconcile. I imagine that in the course of dealing with that disconnect, you'd eventually be led to create a UI in which you show unassociated file types and then invite the user to go get an app that would support them (if you could even launch the Store with that criteria). I don't know for certain, but I would guess that a number of desktop apps did this very thing, which is why Windows chose, for Store apps, to build the UI directly into the launching API.
I don't know about native RT methods to get such a data, but windows-runtime is nonetheless still Windows. So you can access the registry. And all the needed information to determine whether the file type has the associated application is contained inside the registry.
Taking into account those two considerations you can try to use this SO thread as the basis for your enabling code.
P.S.: Native RT methods would have been much better solution but, sadly, I have very fleeting experience with Win-RT. May be someone more knowledgeable can propose better native solution.
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.