>>>>Hi,
>>>>
>>>>After examining the run-time error log (mainly for one customer), I see one case where the error was created in an INIT method of some main form (I see Stack Level 5 indicating this error my_form.init). Then the error (Stack Level 6) goes to the function dl_ErrorMessage (a function in one of my prg). The function dl_ErrorMessage() has the code:
>>>>

>>>>oErrorForm = NEWOBJECT( "dl_error_message", "dl_error.vcx",'', tcTxtMessage, 
>>>>tcTxtCaption, cParameter1, cParameter2, cParameter3 )
>>>>oErrorForm.show()
>>>>

>>>>
>>>>And here the actual error happens:
>>>>

>>>>Error reading file FQDN UNC Style\appfolder\libs\dl_error.vcx
>>>>

>>>>
>>>>Oddly enough the error log is written to the APPFOLDER. So, the desktop is not completely disconnected from the Share.
>>>>
>>>>So, basically, if I understand correctly the application cannot file dl_error.vcx, which is INSIDE the EXE program.
>>>>
>>>>Two questions:
>>>>1. How can I trap the error (or find out what exactly caused the error in the INIT method)? Should the entire INIT method to be within TRY/CATCH? Note, that even if I do that, the INIT initializes a bunch of BIZ objects that are dropped on the form. So, I am not sure where the error is generated, in the INIT code or in the code that instantiate all BIZ objects.
>>>>2. Could the error 1 (above) be a precursor that the desktop lost connection to the network? And hence even the dl_error.vcx cannot be found?
>>>>
>>>>TIA
>>>>
>>>>UPDATE: Probably main question. What code should check if the Application EXE is still available and that the library DL_ERROR.VCX in this EXE can be read? That is, what code should be executed before:
>>>>

>>>>oErrorForm = NEWOBJECT( "dl_error_message", "dl_error.vcx",...)
>>>>

>>>>
>>>>TIA
>>>
>>>This sounds like there might be some sort of antivirus/antispyware that's getting in the way, although the scan was likely completed when the EXE was being loaded, any subsequent access of the EXE file might trigger an additional scan (as such behavior is typical pattern used by virus/malware).
>>
>>It could possibly be the case, the AV blocking access. I am thinking that maybe - until I work on the Al Doman's suggestion - to have a LOOP around the code above. And try to instantiate the oErrorForm at least 2-3 times, before letting it crash. Let me know what you think of this approach.
>>I also wonder, if the call to FILE( "dl_error.vcx" ) will work on testing if the vcx is available.
>
>FILE( ) has a quirk: if the path-removed file name is present in the EXE, FILE( ) will always return .T., even if the file is known to not be present in the path specified. As the help ("Tip") points out in https://www.vfphelp.com/vfp9/_5wn12pql4.htm , use ADIR( ) if you're explicitly looking for files on disk.

But the file I am looking for is NOT on the disk. It is inside the .EXE file. So, ADIR() won't work.