Seems like an analogous method to the OverrideSearchTableName/Schema would be nice here, something like OverrideSearchSelectFields.

The Public Function Search() in the browsedialogwindow uses the bo allfieldslist







So it would seem if that list were exposed in the BO properties on the instance level that would pretty much take care of it and be useful in other areas as well. Present all the fields in a picker - either uncheck to exclude or check the fields to exclude, that sort of thing.



Alternately, a property that is a list of fields that if it is not blank would be used instead of allfieldslist.

OK....let me jump in here. First, there is already a way to do both. The BrowseDialog uses a QueryInfo class that gets passed all the way down to the DAL which in a query class written specifically for this class that is independent of any database on the back end. This is handled in the DbDataSourceItem which interprets the contents of the QueryInfo class and then properly builds the query necessary for the results. I have just made a change that will appear in the next update that fully exposes this property immediately before executing the query. It will be called BeforeSearchExecuted and it will give you the full QueryInfo instance that is to be used immediately before it is actually used. This is easier than using the Tokens that allows you to inject logic into the QueryInfo class through the Searching event.



When you get this update and if you elect to manipulate the QueryInfo class, you will just clear out the Fields collection on the QueryInfo and add in the fields that you want to be returned.



Now that this particular argument has been resolved....here is my opinion. You are better off creating a view anyway. It will be easier and was the reason it was introduced in the first place. Let's quickly discuss why the view or alternate table option was added. We had introduced the tokens within the Searching event that manipulated the QueryInfo class. However, there were still some issues that could not be fully realized until the underlying query was accessible. This was a need that came from our medical software. We had this very need, and we were also in control of the framework and knew that we could expose this QueryInfo class and manipulate it as well. Obviously we determined that the cleanest, fastest, and most scalable option was to create a view that could be injected as the query source which ultimately opens up the world in regards to result sets coming back in a browse dialog.



At any rate, you can do it either way...but I still would go the view route in this case.

Hi Trent,



Thanks for the explanation and for the new event to handle this kind of situation even though I agree with you that at the end, a view will serve much better and will be more flexible to work with.

Edhy Rijo