[callahan09]

Hello, I am trying to teach myself how to add a progress bar to my Windows Forms Application, and discovered that the bar will not repaint itself to actually show the progress of the work unless I put the work in a separate thread. So that set me off on a job to teach myself multithreading.

This program is purely experimental to try to understand these concepts. The full code from Form1.cs follows:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Threading;

namespace Multithreading__Test_2_
{
    public partial class Form1 : Form
    {
        private int x = 0;
        private int y = 12500;

        public Form1()
        {
            InitializeComponent();
        }

        private void Form1_Load(object sender, EventArgs e)
        {
            // Prevent the framework from checking what thread the GUI is updated from.
            Form1.CheckForIllegalCrossThreadCalls = false;
        }

        private void button1_Click(object sender, EventArgs e)
        {
            button1.Visible = false;
            progressBar1.Visible = true;
            progressBar1.Maximum = y;

            Thread workThread = new Thread(new ThreadStart(WorkThread));
            workThread.Start();
        }

        void WorkThread()
        {
            if (x != y)
            {
                x++;
                progressBar1.Value++;
                WorkThread();
            }
            else
                MessageBox.Show("Done");
        }
    }
}

This code, as-is, works perfectly fine. But for some reason, if I make y any bigger, say 13000 or larger, then I get a System.StackOverflowException suggesting that I've got an infinite recursion. Obviously, it would not be infinite recursion, it would end after just a few more iterations, but for some reason C# does not like it.

Why does this create a System.StackOverflowException situation and how can I prevent it? When I do this for my actual program, the work being done is a recursive operation that has the potential to recur more than 13,000 times so I am worried that I will get the same error there, and would like to try to correct it in this experimental situation before modifying the code of my other program.

Thanks in advance!

[JackOfAllTrades]

void WorkThread()
        {
            if (x != y)
            {
                x++;
                progressBar1.Value++;
                WorkThread();
            }
            else
                MessageBox.Show("Done");
        }

No recursion???

[eclipsed4utoo]

Try changing your WorkThread to this..

void WorkThread()
{
     do 
     {
          x++;
          progressBar1.Value++;
     }
     while (x != y);

     MessageBox.Show("Done");
}

and really, you don't even need x.

[callahan09]

JackOfAllTrades, on 16 August 2010 - 09:19 AM, said:

void WorkThread()
        {
            if (x != y)
            {
                x++;
                progressBar1.Value++;
                WorkThread();
            }
            else
                MessageBox.Show("Done");
        }

No recursion???

Sorry if the title was misleading, my intention was for the "infinite" to apply to both loop and recursion, meaning that I know I don't have an infinite loop or infinite recursion.

[Curtis Rutland]

Stack Overflow doesn't just happen on infinite recursion. It happens when you run out of stack space. So finite recursion with a huge number of recursive calls can still cause a StackOverflowException.

[callahan09]

OK, thanks for the replies. I do not know how I can get my test program to run without a stack overflow and still do it using recursion. I just implemented the multithreading into my actual program, which does (and must) utilize recursion, and so far I have not encountered any situations where it must recurse 12,000+ times, so it has been working well, but I fear that if I do encounter an odd large case then the program will fail. But that will be a question for another time, I guess.

[JackOfAllTrades]

Why do you NEED to do this with recursion?

[Curtis Rutland]

Well, it is technically possible to increase your stack size, but that's like putting a bandaid on a bullet wound. It's better if you can figure out a way not to recurse 12 thousand times.

[eclipsed4utoo]

callahan09, on 16 August 2010 - 11:50 AM, said:

OK, thanks for the replies. I do not know how I can get my test program to run without a stack overflow and still do it using recursion. I just implemented the multithreading into my actual program, which does (and must) utilize recursion, and so far I have not encountered any situations where it must recurse 12,000+ times, so it has been working well, but I fear that if I do encounter an odd large case then the program will fail. But that will be a question for another time, I guess.

did you try my code? It accomplishes the same task without the recursion.

EDITED: just noticed you said it MUST utilize recursion. Why is that?

[Curtis Rutland]

eclipsed4utoo, on 16 August 2010 - 02:56 PM, said:

did you try my code? It accomplishes the same task without the recursion.

I'd have to guess that he's simplifying something for us, something that might need to use recursion more than a simple counter.

But as far as I'm aware, there's usually an iterative solution to recursive problems. They aren't always the most elegant, but recursing twelve thousand times to blow the stack isn't exactly elegant either.

[callahan09]

I'm making a file copier, so it uses recursion to go through each file in the parent directory and all subdirectories and make the moves. It's pretty simple using recursion. I couldn't think of any other way to do it, though perhaps there is some way? In some cases there are thousands of subdirectories.

This post has been edited by callahan09: 16 August 2010 - 09:07 AM

[Curtis Rutland]

I wonder if something like this would help:
http://blog.function...-your-tail.html

[AdamSpeight2008]

callahan09, on 16 August 2010 - 03:08 PM, said:

        private void Form1_Load(object sender, EventArgs e)
        {
            // Prevent the framework from checking what thread the GUI is updated from.
            Form1.CheckForIllegalCrossThreadCalls = false;
        }

Just asking for trouble. You may not even be aware the trouble.

[callahan09]

AdamSpeight2008, on 16 August 2010 - 11:06 AM, said:

callahan09, on 16 August 2010 - 03:08 PM, said:

        private void Form1_Load(object sender, EventArgs e)
        {
            // Prevent the framework from checking what thread the GUI is updated from.
            Form1.CheckForIllegalCrossThreadCalls = false;
        }

Just asking for trouble. You may not even be aware the trouble.

This program is my very first attempt at writing a program that utilizes a GUI. I've been a console guy forever but this program just simply has to have a GUI for it to be user-friendly enough for some of the people who will be using it. So I'm learning as I go with the GUI stuff. Could you please enlighten me as to what trouble that could cause? And what would be a non-trouble-causing way to allow my secondary thread to manipulate the GUI?

[AdamSpeight2008]

The answer is to use delegates. For an example look the background worker tutorials.