decouple UI

  • Thread starter Thread starter mp
  • Start date Start date
M

mp

I'm playing with a little app to show some values from a spreadsheet(excel)

First i had some code in the form to open and read the excel files

Then I was thinking about the idea of the form being coupled as little as
possible to the rest of the code

So I took the excel stuff out of the form and created an excelReader class
to do all that stuff...

now if i want to show some results in the form, is the following an "ok" way
to do it or is there a better pattern i should be using?

it's clunky but at some point the form has to know what control it want to
display what info in...so there's some inevitable coupling at some point,
no???

thanks
mark

ps i tried to get rid of the switch statement below by using foreach but
found a lable control isn't a control apparently
foreach (Control ctl in this.Controls)
{
//label is not a control!!!
Debug.Print("Control " + ctl.Name);
if (ctl.Name == "lbl" + rangeName)
{
ctl.Text = rangeName + ": " + String.Format("{0:
###,###.00}", rng1.Value2);
}
}
(no label names are output)

code snip follows:

...in the form (show value of certain ranges in a lable in the form)
private void btnReadExcel_Click(object sender, EventArgs e)
{
string filename = @"Path to file.xls";

//open excel file and get reference to specific worksheet
ExcelReader xlReader=new ExcelReader(filename, sheetname);

//range names i want to view
string [] rangeNames = new string[] {"Cash","Stocks", "Bonds" ,
"RealEstate", "Total"};

//show values in lables(or other control later )
for (int i = 0; i < rangeNames.Length; i++)
{
this.ShowRangeLabel(xlReader, rangeNames);
}
xlReader.Close();
}

private void ShowRangeLabel( ExcelReader xlReader,string rangeName)
{
Excel.Range rng1;

try
{
rng1 = xlReader.GetRange(rangeName);
}
catch
{
MessageBox.Show("Range not found " + rangeName);
return;
}
switch (rangeName)
{
case "Cash":
this.lblCash.Text = "Cash: " + String.Format("{0:
###,###.00}", rng1.Value2);
break;
case "Stocks":
this.lblStocks.Text = "Stocks: " + String.Format("{0:
###,###.00}", rng1.Value2);
break;
case "Bonds":
this.lblBonds.Text = "Bonds: " + String.Format("{0:
###,###.00}", rng1.Value2);
break;
case "RealEstate":
this.lblRealEstate.Text = "Real Estate: " +
String.Format("{0: ###,###.00}", rng1.Value2);
break;
case "Total":
this.lblTotal.Text = "Total: " + String.Format("{0:
###,###.00}", rng1.Value2);
break;
default:
MessageBox.Show("Unrecognized range name <" + rangeName
+ ">");
break;
}
}
 
Peter Duniho said:
I'm playing with a little app to show some values from a
spreadsheet(excel)
Click to expand...
[]
Without a concise-but-complete code example, it's not possible to say for
sure what's wrong. But the most likely cause is that your Label instances
are not direct children of the Form instance. Instead, they are children
of some other container child within the Form.
Click to expand...

ahh! they're on a frame(groupbox), I didn't realize the foreach would not
get all the controls, thanks'

[]

It would make more sense to declare your "rangeNames" variable as a static
class member:

private static string[] rangeNames = .;
Click to expand...

of course, i always forget about static :-|
That way, it's instantiated only once.
[...]
}
}
Click to expand...

Another alternative would be to not have the array of names at all.
Instead, associate each Label instance with a name in some easy to use
way. I would not recommend using the name of the control itself, but if
you do then at the very least you should just extract the particular
substring from the control's name, rather than keeping a separate list of
names and searching a list of controls for each name.

In the Designer, you can set the Tag property of a control, which can be
used to store a string such as the name for your reader. IMHO, that's a
somewhat better approach than using the control's name.

If you really do want a collection of range names, then IMHO it makes more
sense to make that a dictionary, with the key being the range name, and
the value being a delegate instance, or perhaps a custom type containing
more than one delegate instance if you have more than one operation to
associate with the name (e.g. setting a value and retrieving a value).
Then you simply look up the delegate and invoke it based on the name. You
can enumerate the dictionary members for situations where you want to
handle all members, and use the individual keys to get specific data (for
example, if you have an indexer on the Form class to extract values for
specific range names).

Pete
Click to expand...

thanks for all the ideas, i'll chew on them for awhile
mark
 
Steel said:
[...] but at some point the form has to know what control it want to
display what info in...so there's some inevitable coupling at some point,
no???
Click to expand...

No, not really if you use MVP and IView with the interface get/set of the
control on the form in the Interface.
[...]
Click to expand...
The controls are objects that you can control on the interface, which
makes things loosely coupled, keeping the UI a dumb UI controlled by the
presenter.
Click to expand...

Steel,
thank you very much for that presentation. i've read about mv patterns but
obviously not adequately digested.
I will spend some time reviewing those sites and your explanations...thank
you very much
mark
 
Steel said:
Steel said:
On 12/23/2010 8:12 PM, mp wrote:
I'm playing with a little app to show some values from a
spreadsheet(excel) []


http://www.polymorphicpodcast.com/
Click to expand...

Steel,
Wow thanks again for that link
That's the most understandable presentation i've seen yet...the video is
great compared to all the text i've read in the past
really helps it sink in
Thanks
Mark
Click to expand...

Well, I start a new contract on 1/3/2011 where I have to come in running
converting over old asp.net solutions over to MVP and n-tier, teaching the
junior developers (10 of them) how to do things right, along with other
things I am hired to do to drag this section of the programming department
to n-tier, OOP, TDD, DDD, ORM, and WCF. It will be a lot of fun.
Click to expand...

congratulations! Great way to start the New Year!!
was that your podcast?
 
Back
Top