Interesting. I'll go back to my original plan. Thanks for your help!!

Note sure. There usually isn't a trick. The designer will show all public properties of your class, unless you tell it not to. So, unless the base class is messing with things, you should be able to see the property in the designer. I usually have issues of it not showing what I want it to show (defaults not setup, editor not setup right, type converters messed up, etc.), but the property is usually there.



Just to check, you do mean that the properties are not accessible when you drop the control on a form right? Because, they won't be if you mean the designer of the control itself. Only the base class properties (and below) are available there.

The properties are accessible from code but not in the designer. What is the trick?

Ok. Makes sense. I think. Sort of. Kinda.



Here is my adjusted code:







I thought that by using the SF constants that I would be able to see these properties in the control, but they still do not show up. I believe I am missing the boat here somewhere. I haven't resorted to head-bashing (my own or others), but I can see how that might happen.



Bill

This is related to interface implementation. This property:







is not a property of the control, but of the interface the control implements because you've implemented it explicitly. Try doing this instead:







and be sure that your class indicates your implementing IBusinessBindable.



Note that one of the IBusinessBindable properties is renamed. IBusinessBindable.DataSourceUpdateMode is renamed as BindingUpdateMode. If you want to do this in C# you'll need to do something like this:







Like I said, bruises to my forehead (due to high speed impacts with my desk).

The attribute exists...and a rebuild has occurred. The item is now in a group on the ToolBox. I can drag and drop it onto a form.



Now, I cannot get the new SF properties to show up (BindingField, BusinessObject, etc.). My BindingField property looks like this:







Basically copied from the source code. I must have missed something in the translation.

Oh, the toolbox thing, try adding this attribute to the class:



[ToolboxItem(true)]

public class MyTextBox



Not sure why, but sometimes you need to add this to get your controls/components to show up in toolbox (after a build of course).

Thanks, Greg...that does help explain what is going on with the implements and interfaces that I am dealing with. I am actually reworking the source code from the InheritedUI for the DevEx TextEdit control. Since it is all in VB, I thought I would start by converting it to C#. Next I want to add the newly formed control to the toolbox. Alas! That does not seem to want to work. I'll keep plugging away. I am learning a lot of new things. That, in itself, is exciting and is definitely keeping me going.

In C#, the how interface thing works is a bit different. I still have some bruises on my forehead healing from figuring the differences out.



In VB, you use the whole Implements keyword thing. This allows you to rename a property/method from that in the interface.



In C#, you either implement an interface implicitly or explicitly. When doing it implicitly, you just create a property/method/event that matches the one in the interface and you're done. An interesting note is that the property/method/event just had to be implemented somewhere in the inheritance chain. I.e one property can be implemented in current class and another in a base class.



If you do it explicitly, then you use the interface within the name of the property or method, as you are dong here:







However, when you do this explicitly, the property is only available when the object is cast as the interface object. I.e. if the above is defined as a property in a class called MyTextbox and you have an instance of this control a form and it's called txtTest then:







And as you've also discovered, when you explicitly define an interface, you can't use modifiers. They are assumed public, because they are only available when the object is cast as an interface object. If this is confusing to anyone, you're understanding where the bruises on my forehead came from...



What you actually need to do to get what you likely want (a public property on the control that implements the ControlSourceUpdateMode that is accessable directly from the control without casting) is to:



- explicitly define that you want to implement IBusinessBindable on the subclassed control:

public class MyTextBox : sf.Textbox, IBusinessBindable)

- Get rid of the IBusinessBindable reference in the property definition.

- Add the public modifier back on it.



As mentioned earlier, C# can handle some of the interface being implemented in the current class and some of it in bases classes. It also seems to handle just fine the fact that you are re-implementing IBusinessBindable on your new class, even though the base class is already implementing it.



Does that make sense?

To get past the error, I simply removed the "public" keyword.



Now, I would like to add this item to a group on the toolbox. How would I do that?