Question

I’m creating a reporting application, and our customers are going to need to generate some pretty big reports which require quite a bit of memory. Ive been in a re-factoring mood lately, so I was wondering what the best way to access the properties of another open form would be(The reporting viewer opens in a new form.) So far I have:

Dim form As MainSelections

form = My.Application.OpenForms(2)

yay or nay.

Thanks

*Edit – I should probably mention that what I need is a label, two date time pickers, 5 datagridviews and a few datasets. Those cotrols have the info I use for my parameters

Answer 1

First, don’t access a form’s controls directly, its considered a bad practice, access dependent data through an interface instead:

(Warning: untested code and my VB-fu is rusty, but you should get the general idea)

public interface ILoginScreen
    Property Username as String with Get
    Property Password as String with Get
end interface

Implement the interface on your Form. (And make sure your interface does not return datatypes like TextBox, ComboBox, etc, that would defeat the purpose of the interface abstraction.)

Second, don’t access dependencies through global state like the OpenForms collection, pass your dependencies to your objects through a constructor instead.

So if your Reports form depends on your login screen (or any other screen), you should have a constructor which accepts an ILoginScreen implementation:

public sub New(loginScreen as ILoginScreen)
    me.LoginScreen = loginScreen
end sub

And instantiate your reports form as such:

dim reportScreen as new ReportScreen(Me)
'passes self as ILoginScreen implementation

---

According to the OP in the comments:

Actually what I need is a label, two
date time pickers, 5 datagridviews and
a few datasets. Those cotrols have the
info I use for my parameters.

Evidently the OP is passing these controls as report parameters. Probably creating and implementing an interface is excessive for his needs, but the general principle of dependency injection is correct.

Pass your data into your Report form’s constructor:

class Report
    public sub New(start as DateTime, end as DateTime, label as String, _
        etc as Whatever)
end class

Please ensure you pass things like DateTimes, Strings, Integers, DataSets, etc — or a typed object representing your parameters.

Don’t pass DateTimePickers, TextBoxes, Comboboxes, DataGridViews, etc. Your report form shouldn’t know or care that its start and end dates come from a DateTimePicker or not, it should only care that it actually has dates of some kind. Lazily passing form controls is a surefire way to enrage the next person who works on your code.