>> I see you still have a CLEAR EVENTS in the Deactivate method of frmSelectDataFolder and a READ EVENTS in the calling code.

>That is the original problem, same function is called, BEFORE the FrameWorks READ EVENTS is triggered and it is again called from the menu by the user AFTER the FrameWorks READ EVENTS is active. That is the reason I have the PARAMETER tlFirstTime, so the first call from PostDoProcessingHook() methods passes to CREATEOBJECT() a .T. and subsequent calls from the menu passes a .F. to this same function which in turns just activates the class again.

I think my problem with understanding this point is because I don't have the actual code to trace through. But I would expect the selection object to be created, your menu to be activated (by whatever means) then the selection object made visible, then for the framework READ EVENTS to hold program execution at that point with form and other objects held ready for use.


>>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.

>Couldn't tiptoe away <g>. I tried putting a READ in the IF's ELSE part after loDF.VISIBLE = .T. but it in essence works pausing (READ effect) for a form/window/control that is not there, press any key and only then is the class available for selection.

Ah well. It was worth a try.

>>The frmSelectDataFolder object is created before the READ EVENTS.

>Yup, created and used once BEFORE the frameworks READ EVENTS and then multiple times activated by the user from the menu AFTER the frameworks READ EVENTS comes into play.

Provided the program execution is 'resting' on the framework's READ EVENTS this sounds good.

>> 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.

>That is the ELSE part in the calling code, but the problem is that after the VISIBLE = .T. it does not stop for user interaction and proceeds to execute the wait window I have put in the code and onto the other logic to change the data folder access, etc. of the function. Once this calling function is over, does the user get the control and interaction of the class, by then it is too late as the path has been set using the first record of the DF cursor.

This sounds like a sequence problem. If the user is indeed getting the chance to select a folder on subsequent calls, why not set the path after this point rather than before?

>>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.

>That is the good intentions we have.

>> 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.

>Thanks, that is a nice idea.


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

>Yup, I have stopped the cursor from going away and the problem went away like you said.

Lovely.

>> 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.

>Okay I have a splash screen showing the loading messages, so that is not a problem I guess.

It was just a nit pick. Programmers are like that.

>> 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?

>No it is up to the user to select forms all I do (by KEYBOARD) is open the menu, rest is upto the user.

OK.

>>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.

>We have a lot of dumb operators here, the better ones are outsourced <g>, these guys though they use a lot of windows application expect the locally developed business applications to do things automatically as and when they think.

Warn them that if you automate it much more, they wont have a job to do.

>Again I will try to put the sequence in simpler words. Keep a clear mind (not a blank one <g>) and read on:

>1. The app is starting
>2. I am setting up ODBC
>3. I need to know what data to use
>4. PostDoProcessingHook() calls SetupODBCFB(.T.) which in turn does a CREATEOBJECT our class with the .T. it received as a parameter (calling code), the wait window shows the right data path as selected
>5. Client selects the data folder (this is always successful, incl the READ / CLEAR EVENT I have in the class code)
As you can guess by now, this is a bit I have trouble with

>6. The frameworks READ EVENTS kicks in
At which point the selection object should be visible in my scenario.

>7. User works on the data and now wants to work on other data folders
>8. User opens the menu and selects Change Data Folder menu bar
>9. The menu bar calls again SetupODBCFB(.F.) this time the ELSE logic which only does a VISIBLE = .T. as far as the class is concerned.
>10. But before the class has the time to activate and display the form for interaction, the execution of the code involving the wait window (meaning that an assignment is already done to the variable I need for changing the ODBC path) is already executed and in all probability the SetupODBCFB() method is also completed.
Don't set up the ODBC at this point.

>11. The selection form comes up all too late.
Do it after the selection above

I'm sorry BhavBhuti, but I'm already late for my German lessons. I'll get back to this later tonight (yes I know that will probably be too late for you, someone needs to do somthing about time zones). As I said before it would really help if we had a lump of 'not working' common code to deal with then I could compare your comments with the app.

Alan

>A. I have also tried putting a WAIT WINDOW TIMEOUT 5 after the VISIBLE = .T. line
B. One thing I noticed in these subsequent call is that class.activate() is not fired, even when I have manually called it after the class.visible = .T.
C. As I have put in a browse window in the class.activate it does trigger for the very first time the class is created but subsequent calls from the menu does not trigger class.activate, not even manually.
D. This class.activate in subsequent calls will fire only after another application form is opened and closed. This the point when the activate of the
E. I have tried replicating the class.activate code in class.gofocus, no luck.


One interesting thing I have noticed is the following code for calling code:

ELSE
loDF.VISIBLE = .T.
loDF.ACTIVATE()
ENDIF
class.activate:

FUNCTION ACTIVATE
THISFORM.nOldSelect = SELECT()

SELECT df

THISFORM.lstDataFolders.SETFOCUS()
ENDFUNC
Setting focus to the list object, makes the subsequent calls to the class work for every second call

I. Start app with a selection for eg. DataB, perfect display as always
II. Use menu and select a data folder eg. DataC, data reverts to first record's data folder DataA
III. Use menu and select another data folder DataA, data reverts to the data folder DataC
IV. Use menu and select another data folder DataD, data reverts to the data folder DataA
V. so on.