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

Well, some of this can be done and other bits can't.  If you look at the overloads for a FillDataTable, you will see that it accepts a QueryInfo object as well.  This was implements and put in place specifically for the BrowseDialog to create queries without being tied to a specific database type (i.e. SQL Server, Oracle, etc.).  So you could create queries this way if you wanted to.  If you just want to use the BrowseDialog instead and use the SearchFields, etc. then at present, the dialog will have to be displayed (as that was it's intent and purpose).  You can already force the query to execute without user intervention.  But the user would still have to select a record at the moment.  We may consider adding the ability to just execute and return the results regardless of what happens, but there is a lot of other logic that this could impact (all post "OK" logic currently expects that there were results).  This is the first request for this that I have heard of or recall as the purpose of a browse is for a user to make a selection, not just perform a query and hope something comes back, so that is how it was designed and implemented.  So this is something that we would have to inspect to see what would be involved to make this a feasible request.  We can discuss this more when you come to class as well.

Hi Trent,

Just for the record, I second Greg's request.  I see a lot of places where this functionality will work for my projects.  Also I am thinking about reporting, the Browser Dialog would make it a great Query tool for reporting, where the end user will use a familiar interface to enter the parameter info and then preview/print the report.  I don't know how is this addressed in SF since I have not done any report yet, but would imagine using the Dialog Browser just for that.

I would be amazed if you surprise us with a beta code to test during the class

Edhy Rijo

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)

All my reports need some sort of parameters, I have been using Browse Dialogs in order to grab those parameters values from the user and get the records, pretty much the same way used in the StrataFlix sample.



This is OK but have some issues:

1.- All the records are shown in the listview before we can show the report, it is somewhat acceptable but not very clear to end user why they need to see all records in a listview when they are trying to see the report.

2.- You can not use JOIN conditions for the query, so we get the parent record, then do another trip to the server to get the rest of the records after closing the Browse Dialog.



I believe that the dynamic functionality existing in the BD to create the search fields and show them to the end user in a nice dialog is just great for us (developers).



We need a Browse Dialog control for reporting with the following functionality:

1.- Same design functionality as the BD without the listview or panel info.

2.- Allow us to access the parameter values entered by the user so we can send those to a stored procedure to get the desired data in one trip.

3.- A collection of Business Object Property which will allow us to use the FillMultipleData from the control and fill all BOs needed.

4.- Any other functionality I may be missing.



I believe that since you know very well the BD control that this kind of control can be easily created based on what you guys have been done already with the BD and leave the BD the way it is now.



Right now I have a report in which I need to allow the user to filter the data and had to create a quick form just to capture this data and manually add the fields needed and code to grab the entered data and pass them as a parameter to the stored procedure, I could not use the BD in this case because of the kind of query used in the stored procedure, a BD for reports would allow me to create my own subclass and manage and maintain this kind of need in a much better way.



Please put into consideration the creation of a Browse Dialog for reporting purpose.



Thanks.

Edhy Rijo

Edhy,

I am not sure how to respond to this post as I pretty much would not use the BrowseDialog for reporting...at all.  The BrowseDialog is intended for working with a single result set.  Though we have added the ability to create joins, etc. through the override properties, this is still not a good mechanism for capturing information prior to a report.

First, you should have a base class in your report environment that is a critera class.  This criteria class is populated with custom properties for each report.  You then have a root "Populate" method that takes this criteria class and executes a stored procedure (or other query) to retrieve all result sets necessary.  In our medical application, we even save off this criteria class by serializing it by user so it remembers the settings use on a per user basis the last time the report was run.

Here is the deal, Edhy.  Though we could create a low-level criteria class like you are suggesting, most reports, especially the bigger the app becomes, really need more sophisticated queries.  So the end-user should just be presented with a dialog to capture the information necessary, then the criteria captured passed over to the report engine.  If you will recall, in class we talked about how to create a criteria and report data source for each report in your application.  The report data source and criteria may actually be used across more than one report, but this gives the most granular level of flexibility.  StrataFlix tries to show this as well, though it doesn't actually save off the criteria, etc.

Also, Edhy, some of our criteria screens are far too complicated to be used in a "boxed" situation like this.  We have some report criteria dialogs that are very complex and something like this could just not be canned.  For simple reports, I see what you are getting at.  But more likely, we should create a reporting criteria capture and management environment similar to our medical application.  But even if we do this, the query portion should still fall on your applications responsibility because report queries become too complex.  Heck, in our medical application when dealing with billing transactions, we could be dealing with millions of records, dozens of different tables, and at times, 10-20 result sets coming back from a SPROC.  So though I see what you are trying to get at, I just don't see how this would be feasible for most environments.

We will sit down and talk about your situation, but ultimately, I think our time would be better spent creating a broader reporting criteria, data source, and criteria capture management tool within the framework (which BTW, is actually already on the list for the future).

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.

Could you please give us a simple example showing this base class and how do you populate it with different fields of different tables joined?

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)