|
You can make use of System.Timers.Timer . Enable it in the OnStart method of your service and set its interval as 1 hour. Then, handle its Elapsed event and perform email sending there.
50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!
|
|
|
|
|
I voted this as a good answer even though you recommended the use of a timer object instead of using a thread of some kind.
Timer events are the lowest priority message in Windows, and on a busy system, the message is not guaranteed to be sent, much less retrieved.
.45 ACP - because shooting twice is just silly ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
That can be a good thing.
|
|
|
|
|
Thanks.
I am not sure how I would employ threads for this. (Is it suspend/start kind of thing that you are referring).
John Simmons / outlaw programmer wrote: Timer events are the lowest priority message in Windows, and on a busy system, the message is not guaranteed to be sent, much less retrieved.
IMHO when you are sending mails, you should not be expected to make it happen instantly. Reason being even though your code works perfect, there is always a chance of email server not being upright (unless you have your own and you guarantee it will always work). So a couple of seconds or even a minute or so should not trouble. I also believe that threads can actually mess up the whole application if not used sensibly and accurately. And IMHO when application goes live, only then one can check how well he has handled threads (just an opinion).
50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!
|
|
|
|
|
d@nish wrote: I am not sure how I would employ threads for this. (Is it suspend/start kind of thing that you are referring).
Just use a BackgroundWorker that sits and spins. It can't wait more than 4 seconds before cycling (in a loop) because task manager will shut a windows service down that looks like its not active. It can be canceled, so there's no problem with running it in a service. I abhor the use of timers, and I view them with the same disdain I reserve for goto statements.
d@nish wrote: IMHO when you are sending mails, you should not be expected to make it happen instantly. Reason being even though your code works perfect, there is always a chance of email server not being upright (unless you have your own and you guarantee it will always work). So a couple of seconds or even a minute or so should not trouble. I also believe that threads can actually mess up the whole application if not used sensibly and accurately. And IMHO when application goes live, only then one can check how well he has handled threads (just an opinion).
I don't understand your concern. Once an hour you send an email. Period. Whether or not the SMTP server is available and whether or not you even need to care depends on the environment. If the server isn't on your local domain, there's nothing you can do except send the email and hope for the best. It has nothing to do with the threading model you chose to implement the cycle.
.45 ACP - because shooting twice is just silly ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: Just use a BackgroundWorker that sits and spins.
I don't believe a BackgroundWorker can be used in a Windows service. It's designed to be used in combination with a UI thread.
/ravi
|
|
|
|
|
Yes, it most certainly can be used in a Windows Service.
Technically, it's designed to send notifications concerning its status, regardless of its environment.
.45 ACP - because shooting twice is just silly ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
Once an hour is rather infrequent; a Windows Scheduled Task might suffice.
|
|
|
|
|
You don't need to be a programmer to do this though - it's a matter of job security.
.45 ACP - because shooting twice is just silly ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
After performing operations on mutiple images at the same time(batch image processing) I want to save the images in the same format as the original one.How can I achieve this Can someone pls help.
|
|
|
|
|
Have you considered Image.Save[^]?
All those who believe in psycho kinesis, raise my hand.
|
|
|
|
|
Hi,
Has anyone experienced issues using functions such as SetWindowPos() when moving maximized remote desktop windows over extended desktops.
When I maximize the remote desktop to one of my screens and move the remote desktop to another screen using the c# MoveWindow() function the Remote Desktop yellow title tool bar gets left behind.
What I want to do is take the remote desktop out of full screen mode and run it in a restored state on another screen.
Is there an alternative as SetWindowPos only seems to handle regular windows.
It also seems to not handle multiple screens very well as when I use the functionality to maximize a screen the edges take up 4 pixel columns from point -4 to 0 and from point 1024 - 1028, where I have to manually adjust.
Hopefully I’m just using the wrong functions to position windows.
Functions uses: GetWindowRect, SetWindowPos, MoveWindow, GetWindowPlacement.
As per the following using parameters:
SW_HIDE = 0;
SW_SHOWNORMAL = 1;
SW_SHOWMINIMIZED = 2;
SW_SHOWMAXIMIZED = 3;
SW_SHOWNOACTIVATE = 4;
SW_RESTORE = 9;
SW_SHOWDEFAULT = 10;
For Min, Max and Normal:
WINDOWPLACEMENT param = new DisplayManager.WINDOWPLACEMENT();
GetWindowPlacement(referenceHandle, ref param);
param.showCmd = SW_SHOWMINIMIZED;
SetWindowPlacement(referenceHandle, ref param);
To bring a window to top:
SetWindowPos(Handle, HWND_TOPMOST, xPos, yPos, width, height, TOPMOST_FLAGS);
To move a window to a specific location:
MoveWindow((IntPtr)positionHandle, (offset + xPos), yPos, width, height, true);
Getting the position of a window:
GetWindowRect((IntPtr)positionHandle, ref activeAreaApp);
Patrick.
|
|
|
|
|
It appears as if the remote desktop title bar only displays on the primary monitor.
.45 ACP - because shooting twice is just silly ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
In my situation the remote desktop title bar is sticking to the screen which it was maximised on. I'm driving four screens including the primary where I have remote desktops on each screen. When I minimise each remote desktop each screen keeps the associated toolbar at the top of the screen.
It looks like a maximised remote desktop is a different type of window mode when compared with an application like word. Maybe it's running a type of console / kiosk mode window which behaves differently.
|
|
|
|
|
namespace example
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
}
private void addEmployeeNumberToolStripMenuItem_Click(object sender, EventArgs e)
{
//this.comboBox1.Items.Add(textBox1.Text);
}
private void comboBox1_SelectedIndexChanged(object sender, EventArgs e)
{
}
}
Hello, I have a form with one combobox on it- and menu item: addEmployeeNumber.
is there a way to click employeeNumber toolstrip menu and have a text box display and then once filled with data -it can be added to combobox- or another way- my code this.comboBox1. items. add ( textbox1.text); is not working the right way.
|
|
|
|
|
Why don't you show a new form to capture the data you require and raise an event with custom args to send the data back to the host form where you can update the combo?
I gave an example here[^] the other day.
Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
|
I have written a program that uses the ID field in an access database. If the user removes an item the autonumber still increments by one. That is fine but my question is this.
How does one retrieve the value of the next autonumber when the add new item button is pressed on the bindingnavigation bar?
I originally was doing
int rowcount = this.bookdbDataSet.Tables[0].Rows.Count +1;
this works but it shows me the true value of records in the table. I don't want that I want to know what the next autonumber ID would be.
Example: I have filtered using a search for say cat
I get 2 records back the navigation bar says 1 of 2. And that listings Item ID: 1. I then discover that I wish to add another record so I hit the add button. I would to autofile the Item ID box with the next autonumber in the IDcolumn of the database.
I hope I'm not confusing anyone. Your help is greatly appreciated.
|
|
|
|
|
Hi,
this is a database question, not a C# question.
you should tell your database to generate unique numbers automatically, and then not worry about them yourself. With your code in charge things would go wrong when multiple requests come in around the same time.
BTW: Most databases offer a way to get the primary key of the row that was affected by the insert or update operation once it has been executed.
|
|
|
|
|
the database does generate numbers automatically. but my question is simply how to get the next value in which it wishes to assign. if the value was 4 or 900 i don't care just wanna know how to get that value
|
|
|
|
|
There's no reliable way to tell. If the last record you created gets deleted, how are you going to know that??
Normally, you either create a blank, or partially filled, or even completely filled, record in the database, except for the autogenerated number, get the ID after the data is inserted and use that for the remaining operations, if any.
|
|
|
|
|
well whats the correct syntax in c# to do something like this ?
int itemvalue = this.bookdbDataSet.Tables[0].Rows(bookdbDataSet.Tables[0].Rows.Count - 1)("ID");
that should bet the id value of the last item in the dataset which is what i'm seeking.
thanks for your help by the way...
|
|
|
|
|
there seems to be no safe way in MS Access, Google around and you will find things like this one[^].
|
|
|
|
|
I figured it out thanks for the help guys.
Here for anyone curious about how to do something like this...
this.locationTextBox.Text = this.bookdbDataSet.Tables[0].Rows[bookdbDataSet.Tables[0].Rows.Count - 1]["ID"].ToString();
|
|
|
|
|
Yeah, that gets you the last "currently used" row. It will NOT give you the ID of the next record that's going to get created. Because Access doesn't support true stored procedures, there's no way to reliably get the ID of the records that was just created.
|
|
|
|