If you have multiple search fields in a BrowseDialog, the search seems to be based on 'Anding' the search conditions. Is there a way to 'OR' the conditions or have bracketed conditions. e.g. I want say 3 search criteria (Name, Email1, Email2) and I want a list returned where 'Gerard' is contained in 'ANY' of the 3 columns as opposed to ALL 3 colums

Hi Gerard.

The first thing I would say to accomplish this would be to execute 3 different searchs, filling each of the desired search fields each time and dealing with the results of each of them. Yeah, I know this is not what you want, so if not that way, I would deal with the BeforeSearchExecuted new event created for the BrowseDialog. This exposes the QueryInformation class that is already built and populated and you can manipulate the result set, fields, where, etc.

I haven't used it for this purpose, but it sounds like the place to try.

Hi Ivan.

Where I am coming from in this is trying to build a Generic BrowseDialog, which I have now more or less in place , thanks to yourself and Greg's help. I thought there might have been a property to control this (i.e. and/or betweeen the Search conditions) which I could set programatically as part of my generic browse.  To handle this generically I think is going to be difficult if I have to get into coding Events (generically).

Got it.

Unfortunately no, there isn't such a property currently. I will check if it is on the list for the next updates.

Gerard,

Ivan's suggestions are a good place to start, but likely this is going to get pretty exciting to try and do generically. The biggest issue I see is how you'd provide UI support for these more advanced options. I'm not seeing a way (currently) to allow the user to choose between using AND or OR with the criteria or letting them setup grouping.  You might look into using the information panel feature.  This allows for a user control to inserted into a BD.  While its purpose is to provide details related to the row  selected in the results area of the BD, you likely could instead use it to allow the user to change between AND/OR.  Grouping will still be hard though (i.e. I have no idea how that might be accomplished).

If you can stay close to what the BD is intended to do, which is provide an easy and clear way for users to quickly select a record or set of records to work with, then you'll have a much easier time (the famous Ivan/Edhy/Charles rule of Don't fight the framework).  I've also had some more complex needs in this area and ended up building my own. This is not a trivial task.  I needed to allow AND/OR, use of a field more than once (e.g. to end up with something like Lastname = 'jones' Or LastName Like('smith%') ), the ability to use views, the need to use sub-queries in select columns, sub-queries in In() expressions, sub-queries in the from clause, pivot the results, use of SQL Functions in select columns.  Bloody PIA.  My suggestion would be to work within the confines of the BD if at all possible.

Ok. I'll take your advice and work with exisitng BD at the moment. If it becomes a major issue in the future (at which time I should have a bit more experience of Dot net & c#),  I may try rolling out my own 

The BD has evolved a lot since I first started using SF, so some of these features likely will make it into the component by then too.