Don,

You should be able to implement this by using another search object, one that is not based on Form. This object could instantiate the actual form that only exists while the user is using it. The search form gives it's results to the search object and the search object interfaces to the forms that have this search feature.

You are also free to implement your own Windows menu item if you don't like the way the native one works. A form manager class can add/remove items from the menu as forms open/close.

>The reason is these are search screens and my users would like to see the search returned to where they left off in case they chose the wrong item.
>
>We have some older search screens and the way they were implemented is that they are destoyed when an item is selected. There is currently "spagetti" code to bring the screen back to what it was, but it is only about 80% correct. I am currently replacing these search screens with much more functional ones instead of racking my brain sorting out the existing mess.
>
>By Hide()ing the screens on Select or Cancel, the detail/editing screen can see if the user selected OK or Cancel and get the ID of the item selected and load it. If the user has chosen the wrong item they can click the Search... button and then return back to exactly where they left off simply by Show()ing the screen. But the user has to click on the Search... button to make the detail/editing screen capture the users current selection. When selected from the menu, the search form simply appears. The detail/editing screen has no idea the user has selected something different.
>
>IMO, I think the the VFP window list should remove those screens that are not visible. For now I have disabled the Window menu until I can write or find suitable code for my little problem.