First, a UserControl
is for reusing GUI logic, so I hope that is what you meant. If you are trying to reuse non-GUI logic you might want to create some stand-alone classes for that.
Second, it is generally bad design to call back up to the parent form in the way you describe because it makes the UserControl
less reusable and it creates an overly tight binding between the two. You should, if at all possible, push the data down into the UserControl
instead.
If you can find no way for the Form to push the data down (perhaps because it is based upon a UI interaction within the UserControl
), you have a couple of other options. The first is to wrap up the data-loading behavior into an object that can be passed to the UserControl
during initialization, and the the UserControl
can access the LoadData
method on it as needed. Another approach is to have the UserControl define a set of Events that can be used to request external data from the form. I like to use the "Query" prefix on these kinds of events. So when a fetch button is tapped on your UserControl
, it raises the "QueryData" event, and the form that is handling that event responds by populating a data container of some sort that is part of the custom EventArgs
.
Either of these can be expanded upon if you need more assistance.
Upon re-reading the question, I it looks like perhaps my approach is over kill. I was under the impression that the LoadData
was a method in the Form that loaded data into the UserControl. If it is just a simple call then focus on the event portion of my answer and ignore the data container portion.