For practical purposes but also as a learning exercise, I am wanting to create notification application to remind me of friend's Birthdays. I would like the application to be running in the background so that it can check the current date against user configured reminders. If a reminder is due then the user is displayed a simple Window that will allow them to snooze or dismiss the notification. I want the application to have user specific notifications (i.e. User A's notifications are not seen when User B is logged in).
Option 1 - Application launched upon Windows startup:
I thought about keeping it simple by checking when to display notifications only when the application starts up. I would then put a shortcut in the Windows Startup folder. However, this probably wouldn't work if the PC is put to sleep and resumed each day.
Option 2 - Application constantly running in background:
I then thought about making the application so it minimises to an icon in the System Tray and thus would constantly be running in the background. It would then periodically check when to display notifications.
Option 3 - Using Windows Service with application:
I then thought about using a Windows Service to do the periodic checks as to when to display notifications. Obviously, a Windows Service cannot display UI notifications so it would need to use some other mechanism for notification (e.g. sending an email). An application could then be used to configure settings that the service uses.
Are there any other options that I have not considered which would work better. I'm currently inclined to go with option 2 for my first implementation but could look to move to a better solution afterwards.
TIA
Your option 2 is the optimal one since you are aimed to distinct users and their reminders - your application runs in the context of a particular user, you already know which remainders need to be shown. Of course, you could go for the third option but this way is really need more time to code and the code itself would be more complex. I would go for the second option. As your applications is WinForms, for the periodical checks I would recommend you to use System.Windows.Forms.Timer class.
By the way, showing an icon in the tray notification area does not make your application "run in the background", it is just a convenient way to show your application is up and running.
Related
We are creating an application(must be UWP for Microsoft app store). The application will remain running and we want to “hide” the UI from the desktop after they log in (not in taskbar). We want to put it somewhere where they can see the status of the application and/or logout (like a VPN or Anti-virus app shows status).
We have investigated using systray (non existent in uwp), quick actions tray (seems to be for system applications), notifications (show status there, but user can remove it—looking for something like the Action Center buttons for Wifi). Our goal is to have an application running, but out of the way, with access to the status and logout functionality. What is the Microsoft approved way? If there is no such approved way, how have you solved this?
At this point, that's not supported in UWP.
You can however publish WPF applications to the Microsoft Store using Desktop Bridge. I haven't touch it, but I've seen a few apps in the store running more elevated access than UWP and you may have the ability to control the visibility of the application's icon (ie taskbar/systemtray).
Give it a try and let us know if it works.
You're right, but there are some workarounds that can be used:
1. USING THE DISMISSED EVENT to show the notification again if user dismissed it.
2. UWP APP WITH SYSTRAY EXTENSION
As explained in this blogpost, you can add a component that will create the tray icon.
I am trying to build a window service which will run in background for card reader, I will take card's data on a textbox . My question is :
When someone swipes a card on a card reader that window service WINFORM should take card;s data on a textbox. How can I achieve this.
or,
IF any one can tell me just that how to execute a WINFORM when card swipes, that would work also
Thanks
Windows services aren't supposed to show any kind of UI to the user, they run as completely background task that take no input from the user and show no output or status to them. If you require a service to "talk" with the user, the normal practice is to split the project in 2 different programs, one being the service itself, which is a UI-less thing that does the background processing, and a normal user app, maybe ran at login, that shows notifications and communicates with the service. Consider also that services survive logoff and logon, and there may be many users logged at a given time, so it doesn't make sense to show a dialog to anyone.
My suggestion would be to turn the service into a normal program, that the installer configures to run at startup, and it does the monitoring of the card reader and displaying of the popups asking details for the user. Since there will be no background work, other than monitoring, and if the form is absolute required, it doesn't makes sense to monitor without a user logged in, I don't think a service is the best choice.
I have seen two type of card readers:
1 - plugs into your keyboard port and acts as a keyboard (can also plug into a USB port, but still simulates a keyboard). When a card is swiped the info is written to whatever application and text field currently has focus.
2 - Has some kind of hardware driver (most likely a USB driver, possibly Serial or other).
If you aren't sure which you have then open notepad, make sure it has focus, and swipe the card. If the details show in notepad then you have #1. If they don't, then you probably have #2
If your reader is #1 then you can put some code into the Textbox's TextChanged event to do what you need (I presume you can add code to the application as you said you are building it).
If your reader is #2 then it really depends on the driver it uses. Some will likely provide an API you can integrate with, but you will need to find documentation.
Do you have a model number and manufacturer for your card reader?
I have a console application that shows latest activities & status on its console. The application is heavily threaded & performance is the major concern. No user interactivity is required. Due to a recent case, ive been asked to migrate it to a win form application.
Initial post ->
How to programmatic disable C# Console Application's Quick Edit mode?
So to encounter the problem, I have used Application.Run(ApplicationContext context) so to start a message loop in my console application so that i can hook and trap mouse events and can reset quick edit mode at runtime. I have also deleted a Console's default menu item "Edit" that emerges on right click so not to allow the user to Mark/Copy/Paste.
I want to know what should be the optimal solution, migrating to win form or console app (considering changes i made). Also i need to call Invoke every time in order to put the task in UI's queue so to print the message if migrated to winform.
WinForms would definitely give you more flexibility in what you can do with the UI.
In terms of performance, you really need to be doing a lot of UI updates in order for performance to be a concern. It sounds like that will not be the case since you're currently getting it done with a console application. Most of the time, the UI performance is affected not because the UI thread can't keep up with the updates, but because non-UI stuff (e.g. file IO, database queries, etc.) is done within the UI thread.
I would consider to change your application so that it streams it's output into a logfile, a lightweight database or a Windows event log instead to the console. Thus your application won't need a console or UI at all and can be alternatively run as a service. If someone wants to see that messages, give him a separate (probably Winforms) program to view the latest output, or if you use the Windows event log, he can just use the Windows Event viewer to check the output of your program.
So you neither have to migrate you application to Winforms, nor do some ugly console hacks.
To process log files, the Microsoft log parser may be of interest for you.
Basically, I have an application that runs every 15 minutes. I would like this Console application to remain hidden and not for example minimise/disturb full screen applications.
What would be the best way to accomplish this, it can't be a service though. I'm writing the console application in C#.
Thanks.
To run an application every 15 minutes use a scheduled task. The very simple way to avoid any window being shown is to make this a normal GUI app rather than a console app, but arrange that you do not show any windows in your GUI app.
like david said if you make it a gui program but never load any windows it will run in the background with nothing ever popping up or showing or anything.. another option would be to have your application run continuously and have it do something every 15 minutes...
One option would be to have the scheduled task run as a different user, Network Service maybe, depends on your needs. This will force it to run under the specificed users context and will not show up on other logged in users screens.
You don't need to do anything. A console application is invisible and doesn't interact with other windows. The only way to even know it's there is through Task Manager or something similar.
I have integrated a small to-do list in my WinForms application, where-in user can add tasks and set alarm for it. Is it possible to run timer (or alarm clock counter) in background, even if application is closed. I am using the AlarmClass written as answer here. The aim is only to show a MessageBox when the alarm time is reached and nothing else to do with the application. Also multiple alarm setting should be possible.
I am sorry if my question is not elaborated, coz I dont know wat other details I must include. But ready to reply your questions.
Thanks in advance.
Edit: Any comments on this link?
Short answer
No. If your application is shut down, there's no good way.
Long answer
Yes if you resort to clever hackery. You could:
Run your app in the system tray / background when the 'X' button is clicked
Run a scheduled task which launches your app in "alarm-checking" mode every N minutes
Write a windows service which launches your app for alarm events
I'm not sure, but can't you create a Windows application which only shows up in the Systemtray. Add the required keys to the registry to make sure it will automatically start when windows starts.
Otherwise you can split it up into two separate applications;
- Windows Application to manage the alert
- Windows Service to do the check in the background