You are on the right track, but just a tad too abstract.
At a minimum, you should expose the collection as an IList, not IEnumerable.
Now, the DataGrid is pretty intuitive, and it might wire itself automatically to such an IList directly, but the more de-coupled design would be:
- Wrap your IList in a BindingList.
- Create a BindingSource whose DataSource is the BindingList.
- Set the DataGridView DataSource to the BindingSource.
-
public IList<Process> _currentlyActiveProcesses
-
{
-
get
-
{
-
return System.Diagnostics.Process.GetProcesses().Where(pr ocess =>
-
{
-
bool hasException = false;
-
try { IntPtr x = process.Handle; }
-
catch { hasException = true; }
-
return !hasException;
-
});
-
-
}
-
}
-
-
// Create a specialized list optimized for DataBinding:
-
BindingList bindingList = new BindingList(_currentlyActiveProcesses);
-
-
// Create a BindingSource in order to follow a more decoupled DataBinding pattern.
-
// This is not necessary, but decouples your UI from the Data/Business layer:
-
// Also, set its DataSource in one step using the constructor:
-
BindingSource gridBinding = new BindingSource(bindingList, "");
-
-
// Set the Grid's DataSource to the BindingSource:
-
myGrid.DataSource = gridBinding;
-
Now you can handle events from the BindingList or BindingSource instead of the Grid.
The concept is that if you bound your list to a different control, most of your event
handling would not change.
Plater is right about the Grid using Properties to auto-wire columns. Therefore your
grid will now show the public Properties of the Process object as columns. You can create
custom columns and bind to specific properties if your need to.
Regarding your second question, I avoid using the designer for data binding, so someone else will have to answer the
steps needed to get your IList to appear as a DataSource in the designer.