Question: I am working on a multi-threaded app. I'm processing reports and keeping track of the number of reports in the current batch as well as the total number of reports processed. Whenever I update the counters, I also need to update a label on the GUI which, since the process is on a separate thread, requires a call to a delegate. Which one of these is the better way to go?

```

private void UpdateTotalCount(int newValue)
{
    totalCount = newValue;
    if (labelTotalCount.InvokeRequired)
        BeginInvoke((MethodInvoker) delegate() { 
            labelTotalCount.Text = "Total reports:" + totalcount; });
    else
        labelTotalCount.Text = "Total reports:" + totalcount;
}

```

or 

```

private int totalCount;
public int TotalCount
{
    get { return totalCount; }
    set {
        totalCount = value;
        if (labelTotalCount.InvokeRequired)
            BeginInvoke((MethodInvoker) delegate() { 
                labelTotalCount.Text = "Total reports:" + totalcount; });
        else
            labelTotalCount.Text = "Total reports:" + totalcount;
    }
}
```

**Edit:** Ok, third option.

```

private void UpdateTotalCountLabel()
{
    if (labelTotalCount.InvokeRequired)
        BeginInvoke((MethodInvoker) delegate() { 
            labelTotalCount.Text = "Total reports:" + totalcount; });
    else
        labelTotalCount.Text = "Total reports:" + totalcount;
}
// code elsewhere would look like this
totalCount++;
UpdateTotalCountLabel();
//or
totalCount+= curBatch.Length;
UpdateTotalCountLabel();

```

Answer: 
I prefer the first or

```
private void UpdateTotalCount(int newValue)
{
    totalCount = newValue;
    if (labelTotalCount.InvokeRequired)
        BeginInvoke((MethodInvoker) delegate() { 
            labelTotalCount.Text = "Total reports:" + totalcount; });
    else
        labelTotalCount.Text = "Total reports:" + totalcount;
}

```

The second one I dislike because it breaks Encapsulation. I would also modify the method name to be more descriptive such as 'UpdateTotalLabelCountAsync' since that is what the method is doing. 

Since you are right now are working on the code you could get away with putting it in the property setter. However, when somebody else or even you later go to do maintenance work, you might not see how the label is set. With the method at least you know exactly how the label is set. Also a property is used to store data not updated a UI. It is also possible you might move the property out of the UI layer and store another location.
I actually favor #1, since it clearly conveys that you are *doing* something, other than setting a field.

However, I agree with Mykola that your UI interaction **should not belong** to the same class that your backing logic does.