You nailed it!

Thanks for the advice and tips!

I am not going to go this route.  The mere thought of setting up one form to perform a "search-by-form" feature is terrifying.  Mostly because, if I do it for one, then I have to do it for them all.  That would be a huge task that would provide little in the way of ROI, or actually a negative ROI.

My goal is to convince the users that the browse dialog is sufficient.  We can address odd search criteria on a case-by-case basis.

Have a great day!
Bill

Hey Bill, Edhy had some good things to say and I agree with him on the viability of actually needing this type of functionality.  We get requests on a daily basis for all of our products, and though many are very good, others just really may not make sense in the whole scheme of things and so we very carefully review each request.

However, if you have to do this, then you can actually do it semi-easily on the SF side.  The time and energy on this will on for you adding the logic to your application for each field, etc.  But getting the SF BrowseDialog to do this is not too hard

You have two options.  First, you can just add every field in your BO (that makes sense) to the SearchFields collection of the BrowseDialog and then make the fields that should be initially displayed as Visible and leave the Visible for the rest set to False.  They can then open the Search Fields once they open their browse and choose which fields that they want, and even the order to display them.  This would be the easiest approach as you would not have to do anything on the UI...just add the fields and then let them choose what they want.  This is a base feature of the BrowseDialog and the approach that I would probably take.

The second option is to go at it the way that you mentioned and then programmatically add the chosen fields into the SearchFields collection of the BrowseDialog before the browse is shown.  You would just create a SearchField class and set the properties then add it to the SearchFields collection.

Either way will work, but it just depends on which will best suite your needs (and save the most time in the end).

Hi Bill, I am not sure, since I am also a new SF user, but for what I have seen about the SF Browser control, you could programmatically do the following:

• Change the field to be use for the search.
• Pre-build a Browser Dialog with all the fields available to be searched with Visible = True and then programmatically set Visible = True for the one selected by the end user.

My opinion is that this whole search feature is not really needed by the end user, most of the case they always end up using the same fields to do the search and the time and effort you could put into this would not be worth ($$$$).  Unless the customer believe that this is a MUST HAVE feature and if they are willing to pay a high price to mimic what File Maker does, then try to get out of this.

Edhy Rijo

One of the feature requests that I have had for the app that I am building with StrataFrame is:

Can I have the ability to search like I do in FileMaker Pro?

Basically, this means, can a user click a button to make each field on the form searchable?  Has anyone done something like this?  Can it be done utilizing the StrataFrame environment?

My thinking is that it would be an extremely difficult task.  Just trying to allow a search on one BO (outside of a browse dialog) can be tricky...I cannot imagine tying together several BOs to allow for this kind of functionality.  I could be wrong, though.

Thanks for your input,
Bill