That was actually enough!
I must say I'm still not exactly happy about it, but not it makes sense and it isn't the end of the world to have to implement two properties. I'm sure that there are situations were this way of doing would be very handy.
For future reference (for when I forget this and need to remind myself of how it works), here are three articles on the difference between implicit and explicit interface implementation:
This one got me started thinking in the right way (check out the selected answer):
http://stackoverflow.com/questions/1077816/access-modifiers-on-properties-in-cThis one is actually a feature request to MS to update C# to have it match what VB can do. The short of it is they don't see why they'd want to do this...sigh... However, if you really want the same feature as is in VB, there is a "workaround" that simply (!) involves modifying the MSLI in the assembly!
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=287109This is the MSDN reference page for explicit interface implementation:
http://msdn.microsoft.com/en-us/library/ms173157.aspxHere is how you'd do IBusinessBindable in C# such that there was a BindingUpdateMode property on the control that implemented the DataSourceUpdateMode property of IBusinessBindable. The C# method requires two properties be defined. Only the BindingUpdateMode will be visible on the control and in the property window. You have to cast the control to an IBusinessBindable object to see DataSourceUpdateMode.
//-- Class level implementation. This is visible on the control and will be
// visible in the designer (as such, add appropriate attributes to it).
private DateSourceUpdateMode _bindingUpdateMode;
public DataSourceUpdateMode BindingUpdateMode
{
get { return _bindingUpdateMode; }
set { _bindingUpdateMode = value; }
}
//-- Explicit implementation. This property is only visible if you
// cast the control to IBusinessBindable. Note that when using
// explicit implementation you can't have an access modifier. It will
// public because of the explicit implementation. Note that this just
// calls the BindingUpdateMode property, which actually implements
// the property.
DataSourceUpdateMode IBusinessBindable.DataSourceUpdateMode
{
get { return this.BindingUpdateMode; }
set { this.BindingUpdateMode = value; }
}
These properties could be used like this:
//-- BindingUpdateMode is available on the control itself
MySFBindableControl ctl = new MySFBindableControl();
//-- This works:
MessageBox.Show(ctl.BindingUpdateMode.ToString());
//-- This doesn't (won't compile)
MessageBox.Show(ctl.DataSourceUpdateMode.ToString());
//-- But this does
IBusinessBindable bctl = (IBusinessBindable)ctl;
MessageBox.Show(bctl.DataSourceUpdateMode.ToString());