>Hi,
>
>I know you must be tired of me, or my messages. Be patient; another 10 years and I will stop :)
>
>Good news is that I no longer get the errors (from this customer) of the lost connection to the SQL Server. I have already wrote about it.
>
>But I still see in the error log issues related to the application "reading" some libraries. Here is an example:
>
>A user clicks on an item of a toolbar, the program calls a method OpenAppForm which actually (as name suggests) opens a form. But the log file says that OpenAppForm had an error:
>
>Error reading file \\.......\appshare\libs\formfile.vcx
>
>The location \libs\ is where the library formfile.vcx reside at design time. And I understand that since the application cannot read this .vcx it refers to the design time name. This is fine.
>
>My question. Inside the OpenAppForm I can enclose the instantiating of the form in formfile.vcx (or any other) in Try/Catch. Then if the problem is determined, where should the code go? Simply informing the user that they have a problem? Creating a loop and attempting to instantiate the form 2-3 times? What else can I do with this Try/Catch?
>
>TIA
Today I saw another error in the error log. The error says:
Cannot read file c:\users\dmitry\appdata\local\temp\password.fxp
Note that the error points to the location on my PC (my development PC). The end user does not have the c:\users\dmitry....
How could it be that at run time his application attempts to read a prg/fxp file from location on my PC (that is, in location that does not exist in his environment)?
TIA
UPDATE. I think I know how to fix the above problem.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham