>>For the programmer, BROWSE is a great "quick-and-dirty" solution, especially for debugging. For the end-user, BROWSE should generally be substituted by a grid, which gives you more control.
>
>If I name the Browse I can handle it as a Grid. If I used an explicit grid would I then have a way to close it programmatically (other than closing the window as Dragan suggested)? What advantages would a grid control give me?

You can control every column via properties, events and methods. Events like Click(), RightClick(), and others are either difficult or impossible to reproduce on a grid.

>I like the BROWSE because it uses all of the available screen realestate without taking up any space when it is not in use.

A form with a grid that uses up all the space on the form should give you the same advantage.

>>Also, ESC to select something is quite contrary to the standard user-interface users are accustomed elsewhere. You should use ENTER to select a record (alternative: click on "Accept"), and ESC to cancel a selection (the receiving program should check for an empty value, which it will receive in this case).
>
>As I said I have been using this approach for years and none of the hundreds of users have ever complained about pressing Escape. Actually a lot of them click on the X (close button) anyway.
>
>I understand your esthetic objections but what are the practial problems?

If the user gets confused by a counterintuitive interface, that is what I would consider a "practical" application. It is not that it wouldn't work: once the user gets accustomed to the interface, ESC should work as well as any other key. In this case, it is only the interface I am worried about.