I have had trouble reproducing this through the examples that you have provided.  I made a number of changes to the BrowseDialog today and thought I would look as this as well.  I did not make a change on this side as I could not make it fail.  I will look at your sample again to see if I can make it fail from that point.  But I may need some more information in order to address this.  Thanks.

Maybe you fixed it since the last release?

The problem is when you have nonvisible search fields. If you create 2 search fields one on the PK and another on some other field. Set the PK to nonvisible. fire up your app and show the browse, enter some data in your  other search field, when you search the query that is built will be something like

"select whatever from sometable WHERE PK_ID = my other search fields value".

instead of "Where MyOtherSearchField = my other search fields value"

The where clause is being built on the search fields collection regardless of visible or not

Paul

This is not fixed in that release.

I created a sample app that reproduces the problem.

Here are the steps I took

1) Created a BO and BrowseDialog mapped to your sample customer table

2.) create a search field on cust_pk with visible not checked

3.) create a search field on cust_firstname with visible checked

4.)create results showing pk and name

When you call showdialog() only the cust_firstname field is visible for searching. If you try to search on all customers with a first name starting with "a" you will get a input string error however search on "25" and you will get whatever record's PK is 25. When the where clause is built it doesn't respect nonvisible fields.

Let me know if the sample helps you see what I mean.

	Post Attachments
	test.zip (5 views, 31.95 KB)

Any word on this ?

I had to revert back to the original source code that I modified because using the latest release still causes all of my browse dialogs to crash or display erroneous results as I posted before.

(after reverting) the type editor for search fields no longer work's it simply does not appear. So it sucks to modify existing browse dialogs and to add a new one I ended up copy and paste all the code out of an existing one and modify the field names etc just to get it done.

I tried your sample, was curious.

I think this has to do with the change they might have made in order to get the RegistryKey working. Please, try in your end, put something in the BrowseDialog RegistryKey property (HKEY_LOCAL_MACHINE\SOFTWARE\Paul\test or whatever), run your sample and click the Search Fields in the toolstrip menu. Save it and test again. It works here.

It is not a solution, but might get you going and gives a clue about where to look.

Where you able to reproduce the problem prior to making the change you suggested ?

I will test on my end but have to re-switch dll's

I had to get rid of the "PrimaryKeyIsRowGuid" BO property first, as I think this is something inheriting from a base BO of yours over there.