Comments by Jimmanuel (Top 16 by date)

OK, you made it sound like you already knew how to write a service. If not, see here: http://msdn.microsoft.com/en-us/library/aa984464%28v=VS.71%29.aspx

With that, you have the help to write a service, you have guidance on how to make it periodically do something, on how to check for Outlook, on how to know when it exits, on how to know it's run time and on how to write data to file. I'll leave it up to you to put all of the pieces together in the correct order.

And also, at the bottom of each answer is an "Add a Comment" button where you can leave a reply to a answer. The comment you post should be emailed to the author of the answer (I think). Unfortunately there doesn't seem to be a way to reply to a comment yet. :)

The two methods aren't inherently better or worse than one another, they're two different things to do two different jobs.

By default all of my classes start internal and sealed. I make them public only when I need to use them from another assembly and I remove the sealed only when I have another class the needs to inherit from it. It's just a policy of mine that I start with the most restrictive permissions and ease them only when necessary.

As for why my example was an instatiatable class instead of singleton, that wasn't the main focus of it. That was just the quickest way to put something demonstratable together.

Agree - this would be better in the forums but since it's already here . . .

"Try to solve his problem or merely tell him that what he has done is wrong and that he should redesign his whole application?"

There's no way to know if this involve redesigning the entire application or just one small part. What I do know is that when you have a problem it's ALWAYS better to treat the cause instead of it treating the symptoms. Fixing the cause is a one time thing. If you don't then symptoms will keep popping up later on down the road. And it's not just THIS problem we're talking about. You've acknowledged that creating forms in background threads is bad, but now the OP has a solution that works whether or not it's a good one. The next time the OP comes upon this situation what do you think he's going to do? The properly desinged way or the quick and dirty way? What do you think he'll promote to his colleagues?

"When Dave says "this is no solution to the problem", he's definitely wrong"

While you're technically correct, I agree with Dave's statement. Application.DoEvents will solve the problem for now, but it's not promoting good design. I did look at the other link where you suggested this and in that case you DID mention to avoid while(true) loops but not here. Just because an answer is technically correct doesn't make it a good answer IMO and that's why I downvoted it.

"having a loop in it will freeze all other threads for the execution time of the loop if you don't call either DoEvents or Sleep"

I was going to let the conversation end but then you made this statement. Take this simple example:

public partial class Form1 : Form
{
private volatile bool runThreads;

public Form1()
{
InitializeComponent();

new Form2().Show();

runThreads = true;

new Thread(() =>
{
while (runThreads)
{
;
}
}).Start();
}

private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
runThreads = false;
}
}

There's a while(true) loop in a background thread and the two forms works just fine. The Windows scheduler will ensure that each thread gets a fair time slice so that the 2 forms will remain responsive. The only way that the previous example can bog down the two forms is when there are so many background threads spinning that it causes the entire system to become unresponsive; sleeping may be appropriate here depending on what the threads are doing but it's moot since this isn't what the OP wants to do. Problems only arise with just one thread when Form2 is created and shown from the background:

public partial class Form1 : Form
{
private volatile bool runThreads;

public Form1()
{
InitializeComponent();

runThreads = true;

new Thread(() =>
{
new Form2().Show();

while (runThreads)
{
;
}
}).Start();
}

private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
runThreads = false;
}
}

Now Form1 works fine but Form2 is hosed because the background thread is busy spinning instead of pocessing window messages. The ONLY solution to make this work is to put an Application.DoEvents inside the body of the loop; sleeping won't accomplish anything because the window can't update if the thread is asleep. Try it and see. Yes. Technically speaking calling Application.DoEvents will work but it's a personal belief that any call to Application.Doevents ia a bad code smell that's an indicator of a lazy design. The MSDN page on Application.DoEvents gives a perfect example of what I mean

Link: http://msdn.microsoft.com/en-us/library/system.windows.forms.application.doevents.aspx

A much better method IMO would have been to load each image, set the picture box and then set a timer to wake up and load the next image. The way it's designed in their sample the app won't respond to ANY user input while the slide show is playing.

Well then, how about telling us how you really feel :)

Dave's answer is IMO the correct one. Modeless forms should not be shown from background threads. Period. Whenever you attempt it you're forced to call Application.DoEvents because otherwise the form would never get a chance to process window messages and it'll appear frozen, as the OP has found out. Why I consider this a misuse is because background threads are for doing background work, not running windows message pumps. To show a form the form should have it's own thread exclusively for processing messages but since in this case the primary purpose of the thread is to do some background work, calling Application.DoEvents is improper.

Showing a modeless form from a background thread and then sleeping does nothing because if the thread is asleep then it obviously can't process the window messages and the form will stay as frozen as it was before (and i just tested this to confirm).

Reason for my vote of 5
Good answer.

Reason for my vote of 1
Calling Application.DoEvents in this case is a misuse of that method.

I think you need to clarify what you mean by "all coordinates of the curve". On any given line there are an infinite number of points so it would be futile to try to create a list of all of them. If you have a specific subset that you want then you could use some trigonometry to generate them but I wouldn't expect .Net to know what specific subset you're looking for.

Are you supposed to be able to copy data off of it? Usually when I've seen a computer locked down in such a way it was done to prevent specifically that. I recommend you direct your question to the person who gave you access to the computer.

Edditting your post to include what kind of exception is being thrown might help get an answer to your question.