Search locator shows when not expected

[Thys]

Hi,

I have a browse that's used on a form more than once. I don't want the search locator to show anywhere on the form. It doesn't show for the first instance of the browse, but from there it starts showing - at least just the entry control. I've selected "No Locator" on the browse, but still shows.

I there maybe another way to totally remove the search locator?

Thys

[Thys]

I got an alternative to work. I added "exit" in the start of the GenerateLocatorAbove and GenerateLocatorBelow routines - working fine.

But the template still probably needs so correction because "No Locator" should stop it from being generated.

Thys

[Bruce]

I think you are going to have some problems re-using the same browse multiple times on one form.
You may want to test that very carefully, especially if you are doing page-loaded browses.

Bruce

[Thys]

Hi Bruce.

Yes, I've reported the next problem earlier today. Seems like the DIV id is identical for all instances of the browse on the form, causing the update functionality not to work for all.

This actually has to do with my original question some weeks ago on how to have a browse on a queue. The answer was to save it on disk and then display it as a table browse. On the same form we have several such browses, so I got the generation of the underlying data working for each instance of the browse - but all from one table with different filters. The answer now seems to be table aliases with different browse procedures?

Thys

[Bruce]

Hi Thys,

>> The answer was to save it on disk and then display it as a table browse.

It doesn't have to be on disk, the INMEMORY driver is supported.
If you plan to have different data in the table, depending on the user, then be sure to add a SessionValue field to the table (and filter your browses using that) and of course don't forget to clean up the table in the WebHandler, NotifyDeleteSession method.

>> The answer now seems to be table aliases with different browse procedures?

Different browse procedures, yes. But no need for alias'es, they can work on the same table.

cheers
Bruce