>>>>>>Hi,
>>>>>>
>>>>>>I am looked at the error log and the images that the error routine creates when an error occurs. And everywhere where the application cannot find the file password.fxp, the screen image shows that the application was not loaded yet (not tool bar or menu appear). Sometimes just the application main windows without any toolbar or menu. The error log ends (as far as Stack Level) with the call to APPLICATION_SETUP.START (before it goes to the ERROR_MANAGER.ERRORHANDLER). And the main PRG does have a code
>>>>>>

>>>>>>oApp.start()
>>>>>>

>>>>>>The code in application class START method is as follows:
>>>>>>

>>>>>>PROCEDURE Start
>>>>>>	do while .T. 
>>>>>>		read events
>>>>>>              *-- method .cleanup() closes all open forms.
>>>>>>		if this.cleanup()
>>>>>>			on shutdown
>>>>>>                     *-- Method cleanup2() does basically nothing. Just two lines:
>>>>>>                     *-- POP MENU _MSYSMENU TO MASTER
>>>>>>	              *-- SET SYSMENU TO DEFAULT
>>>>>>			this.cleanup2()
>>>>>>			if type('oPassword') = 'O' .and. !ISNULL( oPassword )
>>>>>>				oPassword.Close_user_login_file()
>>>>>>				oPassword.destroy()  
>>>>>>				oPassword = .NULL.
>>>>>>				release oPassword
>>>>>>			endif
>>>>>>			exit
>>>>>>		endif
>>>>>>
>>>>>>	enddo
>>>>>>

>>>>>>
>>>>>>My understanding that on the Start of the application the code does not go below the line READ EVENTS above. So, the Cleanup() and cleanup2() should not really affect the start.
>>>>>>
>>>>>>Anybody see what could be wrong in the code above? Or what IS wrong in the code above?
>>>>>
>>>>>I see no reason why you have a DO WHILE .T. loop. I don't see why that would cause your problems, but I also don't see the point of it.
>>>>>
>>>>>Tamar
>>>>
>>>>First, thank you. I was wondering about it too. But I "copied" this method back so many years ago that I don't even remember where I copied it from and why I have it.
>>>>
>>>>The main question I had/have is what actually happens on the line read events that it triggers an error. Since the application stays on this line for as long as the application works.
>>>
>>>In the pre-VFP days, there were people who used DO WHILE .T. as a wrapper around many routines. I've inherited a couple of applications where most of the code does that. I think it was bad style in FP2.x days and I think it's bad style now. (It might have been reasonable in the days before the foundation READ.)
>>>
>>>
>>>>Now that I write it, I am thinking that if somewhere there is a code "CLEAR EVENTS" that fires inadvertently, the code moves to the next line. And this is - could be - what I see in the error log.
>>>
>>>I really, really, really think your problem is a flaky network. The fact that IIRC, only one client is having a problem strengthens that argument. If it were your code, it would happen everywhere.
>>>
>>>Tamar
>>
>>You are other are probably right, as far as my problems caused by flaky network.
>>
>>And I am sure I have enough things to fix in my code. For example, last night I discovered that in some places I have CLEAR EVENTS before READ EVENTS was called.
>>I "forced" one of these places - for testing - to call CLEAR EVENTS before READ EVENTS. The program didn't bomb, it simply went to the next line after CLEAR EVENTS.
>>
>>From the little you know about VFP (bg), can you think of what kind of "side effect" calling CLEAR EVENTS before READ EVENTS would cause?
>>
>>Thank you.
>
>From Help on the topic Clear Events:
>Stops event processing started with READ EVENTS. When CLEAR EVENTS is executed, program execution continues on the program line immediately following READ EVENTS.
>To be honest, this is something that you really need to re-read until you understand it!!!

I understand this. The question that I pose is, what does CLEAR EVENTS do when there is no READ EVENTS. That it, could this "orphaned" CLEAR EVENTS cause problems.