Hi BhavBhuti,

I see you still have a CLEAR EVENTS in the Deactivate method of frmSelectDataFolder and a READ EVENTS in the calling code. It looks to me as though you are still writing the code for a straight set of READs. This is the old method of producing apps. But if you want to continue with this approach,the old READ command still works, thank goodness. So try slipping a plain READ into your code at the point you want the object to pause. If it works, it's time to tiptoe away.

But if you want to use the current approach. It should be possible to implement the app with just one READ EVENTS and use the CLEAR EVENTS only to completely end the application. If your framework already inserts a READ EVENTS in the generated code this means adding no more READ EVENTS yourself (it will have no effect anyway), and only using CLEAR EVENTS to exit the application. The frmSelectDataFolder object is created before the READ EVENTS.

So now, in order to control the frmSelectDataFolder object, the Visible property of it is used to present the form for selection when and as you need it. As a result, there will be no need to handle tlFirstTime, as all uses of the object are the same. To use it, just make it visible. On selection by the user, it makes itself invisible. The record pointer in your DF table will have been moved to whatever the user has selected, so you can then use the selected record to return the information you need.

One part missing is handling the case where the user selected this option by accident and wants to back out gracefully. This could be coded by checking for ESC in the KeyPress function and setting the DF table to EOF.

Has your earlier problem, where the table was sometimes not available, gone away?

I had a co-worker once who's apps all started with just a menu. The users hated it, as did I. When I got my hands on one of his apps, I added a little animation routine for them to watch during loading.

I would always choose to present the user with a form at start up. Preferably the form that they would normally choose to start with themselves. But I wouldn't choose to start it by stuffing the keyboard buffer. If it is a form, why not DO formname just before the READ EVENTS? Otherwise I would add a general information form, to at least let them know that the app has started and is ready for their input.

HTH

Alan