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

Hi Trent,



I understand your position, but what am I asking for is just a common control, easy to setup and subclass like the Browse Dialog to allow us to grab parameters and then do whatever we want with it and I see this kind of control in the Browse Dialog.



I know this will not be enough for every kind of report, but in fact like the Browse Dialog, it will be enough for the majority of simple reports that needs to be created in every application. In my case as a Consultant, I get to build all kind of applications for all kind of budgets and then get to do the same thing over and over again, that is the main reason why I get Frameworks to help me in this process, that is why I like the StrataFrame design and tools, RBS, DDT & Localization Messaging which I use in all my projects, it is just perfect for the kind of work I do everyday.



All applications I do will need some reports, some will be really complicated but the majority will be just standard simple reports which will require from 2 to 4 parameters, some of those will be dates which requires a "From - To" dates and the way the BD allows us, developers to create a filter dialog for forms is very impressive and easy, so I strongly believe the same concept could be apply for reporting instead of me creating the same type of dialog over and over again for every application and per reports.



I know this is not an easy control to build and once it is done if you decide to make it, developers will keep asking for more like I am doing now, but that is the nature of having a framework in the first place, to help us be more productive and to keep asking you guys for more and more

Edhy Rijo

I agree, Edhy.  Thanks for your input.

I just now read this and I see where you are coming from.  This would be really convenient to have something like you suggest and would be a big time saver.  It wouldn't have to be very complicated and handle every situation anyway because once ou get beyond a few parameters it becomes too much for the end-users most of the time.

To go a step further, a Query by Form (QBF) feature would be "nice" but I don't know how difficult that would be but I could see where it would benefit all users of SF.

Russ Brown (Using C#2010/SQL Server 2008)