I wrapped a StrataFrame combobox and made it so if the user hits the F5 key, it shows a browse dialog which allows them to go on to add, edit or delete the records found in that combobox. It is a great feature but it is prone to developer error because I need to get the type of the browse as a string in the property (which then I use some reflection code to turn back into a real browse dialog that I got from the BrowseDialog source code).



What I'd like to do is re-use the StrataFrame BusinessObject UITypeEditor that you see below, but change it from looking for BusinessObjects to looking for BrowseDialogs. That way, I can offer a nice dialog to pick BrowseDialogs instead of typing out the entire namespace and name in the property window.




Description("The type of business object that will be used in the browse."), _

Editor(Constants.TE_BrowseDialogEditor, GetType(UITypeEditor)), _

TypeConverter(Constants.TC_SystemTypeStringConverter)> _

Public Overrides Property BusinessObjectType() As String

<...The rest of it....>



I've looked at making my own UITypeEditor and this problem isn't bad enough to make me want to try it. I would much rather inherit from the MicroFour.StrataFrame.Extensibility namespace and just override a property or two. Unless someone knows an easier way to offer a dynamic list in the property window of controls you've created?

Scott,



I'm wondering why you don't just have the property be of type BrowseDialog (not a string) and then just drop the browse dialog onto the form with the combo. If you do this, the drop down will show all drop downs also on the form...done.



This also means your code to open the browse dialog gets real easy (no reflection...the browse dialog on the form gets configured via the designer, etc.).

I just tried it out. I didn't know you could do that, I'll have to remember that for another control that I'm working on! Thanks for the tip.



Unfortunately, this is a case where the type keeps changing. I inherit from BrowseDialog to make a CompanyBrowseDialog and a LocationBrowseDialog and so on. So, no two browse dialogs are of the exact same type, they just inherit from the same base.



When I made the property the base type, it didn't see any of the browse dialogs. So, I think reflection is my only solution and is probably why the MicroFour guy's had to do it too. Unless you know another trick for getting it to look at base types? This answer is really close to what I need, I just don't know what my options are.

Scott,



You must not be doing something quite right, as this is how the BusinessObject property on ComboBoxes, ListViews, ListBox controls all work. When you go to select a BO, it shows you the sub-classed BOs you've dropped on your form. to demonstrate this, first create a sub-classed BD:







Then create a sub classed combo with a property for the a browse dialog:









Note that the property is for a base class, or it could be for an interface. In either case, the property sheet in the designer UI will list all types in the parent form that are of that type or sub-classed from that type (after you've built the project with the combo and BD).



So, build the solution, then drop an instance of the combo and the BD on a form. The combo should now have a FindBrowser property (in the "Examle Property" category) with a drop down that included the subclassed BD.

Technically it should work as Greg mentioned.  You can clearly create a custom UITypeEditor if you like (I have been living here lately on our medical software writing a graphic charting editor that uses the PropertyGrid).  So you can create one in 20 minutes or less to do what you are wanting...but you shouldn't have to....maybe.  It depends on where the property resides.  If the component (BrowseDialog) and the combo with the property are both accesible at the same level (i.e. dropped on the same form) then you should not need a custom UITypeEditor.  But if you are talking about user controls, etc. then you may have to write a custom editor.

I’ll have to eat my hat on this one. I called another programmer over to confirm that I had done exactly as Greg suggested, I compiled it and went to show him how that it didn’t work for me. Of course this time, it worked exactly as Greg said it would.



I swear that I compiled it all and tried to make it work because I changed it between using the BusinessObject UITypeEditor and my BaseBrowse object, where one worked and the other didn’t. I saw it work with Textboxes too. If I was to venture any guess about what happened, it would be that I had been editing my BaseBrowse object for some other issues and that somehow confused my IDE yesterday.



Well, this will make many bugs disappear and make the code much more maintainable. Thank You Greg!



Scott

p.s. Trent, I would really appreciate seeing one of those type editors if you wouldn’t mind posting the code. It seems like you’d need some sort of reflection magic to make them work right, and I would really like to know how to do it.

LOL! I once spent an entire day attempting to figure out a bug, posting here, finally making a sample to reproduce....only it wouldn't. Eventually, the sample was a copy of the broken code and it worked. So, I went back and ran the broken code and it worked, even though I had changed nothing . Still have no idea what happened (probably some app domain thing). Glad you got it working!