Some wrong things here, let's see.
First of all, why would you ever pervert the flow of data here and try to get any data from the label?! A label can be a sink of data, not a source of it, so why trying to make its text a source? Where all the data comes? From the application, which is, in your case, the used space calculation. Where it comes? To some control which displays the data. Isn't it obvious and simple?
Then, you need such control which can be notified on some value and display this value on screen. The application part, the code using this control should be totally agnostic about how this value is shown, it should just notify it.
So, the control should totally encapsulate the presentation issue and surface only the numeric properties used to notify the control on some value to be shown. It means that the exposed properties should be pretty much the same as the one of a progress bar, such as minimum, maximum and current value, only numeric ones. This way, you can create either a custom control or a user control with the progress bar and a label in it as a child controls. Those children should not be exposed to the application code. The setter of the value property should take the value, pass it to the progress bar and format it into string to be presented in the label. Always do it, even if the application is very simple and the control is used only in one application. That's it.
Now, you should not use repeated string concatenation as you do in the calculation of the label texts. The strings are
immutable, so this is a performance leak. Do I even need to explain why? Use
string.Format
instead:
http://msdn.microsoft.com/en-us/library/system.string.format.aspx[
^].
In many other cases using format is impossible (such as in loops appending strings), then you can use mutable
System.Text.StringBuilder
:
http://msdn.microsoft.com/en-us/library/system.text.stringbuilder.aspx[
^].
Good luck,
—SA