I hope I can articulate what I have in mind here as I think it would be very very useful in a lot of scenarios.  (I am also hoping that someone will just say "Oh, you can do that now.  All you gotta do is ... ")

I have just started to really get into the BrowseDialog and for the first time I am "getting" just how powerful it really is.  I have been looking for a way to get the kind of functionality I have with VFE's dynamic viewparameters which allow creating remote views that can have multiple params which can be used or not used and the query for the SPT is built on the fly by a parser.

Now I see in the browse dialog all of that power, but so far is seems it is coupled tightly to interface. 

It would seem that the powerful parser that is building the query from the "search fields" (parameters) and provides a searching event would should be available without requiring the browse dialog form, so that it could be used as a fill method.  A browseobject would be dropped on a form just as the browsedialog is, properties would be set for the business object, the search fields and how they would be  processed and there would be access to the events. 

And then this object could be called as part of a fillmethod after values were set for the search fields you wanted to use.  So if I had a BO I wanted to fill in any of a number of different ways I could do so by setting the appropriate values programmatically, running the query and have a currentdatatable I could used anywhere without any interface being involved.  (perhaps there is a property that says don't show the browsedialog form or maybe don't make it modal or maybe hide it rather than close it so if you go back to the browse form you have the same result set in the browse)

Don't get me wrong, I love what is there now and I'm delighted about the way the interface is handled but I could also forsee situations where I would like to harness this same power (especially in returning only one record) where I don't want to have the browsedialog form come up at all.

On the interface level, it would be nice to have the search fields container and the results listview decoupled from the form so they could be dropped on the primary data entry form and navigating in the results set could be reflected in the single record editing fields, rather than just a displaypanel on the modal browse dialog form.

Now I'm hoping somebody will say I could already do all of that if I understood how the browse dialog works and after the class I will know how

Edhy, I think you get what I am talking about.  The first principle is to decouple business layer functionality from interface.  A query parser object that looks at "search fields", builds a query, ignoring params not used and knowing what to do with dates and having a method where you can fiddle the results of the process would be very useful. 

i.e. object has a collection of params with properties that determine if the param should be excluded if null or empty and how it should be used in the where clause if not in a default fashion

a property that determines what bizobj this parser is designed for

drop this object onto the form, set its bizobj property and identify the params in the collection.

At run time, set the values of the params and pass the object to the bizobj's fill.   Each time it is used you could use a different combo of params.  Now you can get the values from user interface or other stuff going on in the app and apply them as appropriate to query data dynamically.

Could be used with the getdata methods if you want a cursor that is the not main bizobj etc. Use for reporting, use for pretty much anything.  Flexible queries form a powerful onthefly parser and not dependant on interface constraints.  Params could be filled from scalar calls or whatever.

Seems like the plumbing is already there or the Browse Dialog wouldn't work so well.  Maybe after Texas when I know how to look at SF source better I'll be able to explain more clearly what I have in mind.

(this is a framework design issue we banged around a lot in FoxExpress and when we got it nailed it became one of the most versitle and popular parts of the product)