StrataFrame Forum

Confusing implementing IBusinessBindable in C#

http://forum.strataframe.net/Topic24234.aspx

By Greg McGuffey - 8/18/2009

I've been working a C# more and more and mostly liking it. However, I've run into something I either don't understand about C# or something I really don't like much. It appears that you can't rename an implemented method/property/event/etc. for an interface in C#. I.e. in VB you can do this:



'-- The interface specified a property called DataSourceUpdateMode,

'   but it is implemented as BindingUpdateMode here in VB.

Public Property BindingUpdateMode() As DataSourceUpdateMode Implements IBusinessBindable.DataSourceUpdateMode

End Property




However, in C#, I can't figure out how to do this same sort of thing. It appears that the name of the property implementing an interface must match that interface's name.



Now, to IBusinessBindable. As you see above, IBusinessBindable has a property defined called DataSourceUpdateMode. It also has two designer specific methods defined within it: ResetBindingUpdateMode and ShouldSerializeBindingUpdateMode. However, it doesn't have a property called BindingUpdateMode. In all the VB code (like above), the DataSourceUpdateMode property is renamed in the implementation. It looks like I'll have to implement these two designer specific methods, which will do nothing, then implement two more for the actual method and then finally, I'll have to add the [DisplayName] attribute the to the control so it has a consistent name with all the other SF bindable controls out there.



This kinda sucks as I understand it now. What am I missing?
By Greg McGuffey - 8/20/2009

bump...
By Trent L. Taylor - 8/20/2009

I am on the run, so I have not been on the forums lately...sorry. I can give you the answer...or I will give you a hint and you can dig it out. It is explicit versus implicit implementations in C#. Wink Let me know if you need more details Smile
By Greg McGuffey - 8/20/2009

That was actually enough! Wink



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-c



This 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=287109



This is the MSDN reference page for explicit interface implementation:

http://msdn.microsoft.com/en-us/library/ms173157.aspx



Here 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());