Ben,

It is still an issue with the latest update, also because I have modified the business layer (primary key is updatable) I am having to use my modified business.dll but I don't think that should make a difference. However that may be the reason why the type editors for the seach fields no longer works?

It would be great if you guys could take a look at this.

P

Have you tried the latest DLLs that Trent posted in his last update?  I believe he made several changes to the BrowseDialog to fix this as well as the issues when you use the same search field twice (and I believe the SelectedValue = -1 issue too).  I'm pretty sure that he posted the update, so you might give it a try.

He posted it in the updates forum from the main page.

Ivan I'm just glad you could reproduce it.!!!! I thought I was going crazy.

I'll tried what you suggested and it works, It looks like the search fields collection gets reordered so visible search fields are at the top when you save it.

It is not really a solution but hopefully will help trent and ben get it fixed

Trent,

I'm sure you guy's have lots of fish in the fryer but anything you could do to get this resolved would be great I am planning on releasing a beta at our annual manager's meeting on Dec. 1st

Yep, I was able to reproduce it.

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.

Ivan,

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

Hi Paul.

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.

Hi Trent,

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.

Hi Trent,

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.

Download the latest fixes for the BrowseDialog and let me know if the problem persists.  http://forum.strataframe.net/FindPost12630.aspx 

Trent,

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