Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
YAM2 on App Getting the EXE file
Message
From
05/05/2021 23:55:37
 
General information
Forum:
Visual FoxPro
Category:
Troubleshooting
Miscellaneous
Thread ID:
01680124
Message ID:
01680188
Views:
33
Newobject() is known to be slower than Createobject(). So this is a BAD band aid patch not benefiting performance of your app. At least go for fast first try with createobject, catch with newobject().

Besdes myself a few others chimed in with arguments for local install. Make that customer see the light -
Al agreed the worries stemming from local install vs. run from share are without basis.

MUCH better than crippling your perf switching everything to newobject IMO -
your other customers also have the benefit of an app now running like a car with always active hand brake ;-)


>First, thank you for your input. I will wait before suggesting to the IT to deploy the app locally.
>
>What I found - by analyzing the error log - is that most of the failures (if not all) happen when the class is opened by CREATEOBJECT(). That is, only class is known to the code, not the VCX. And the program relies on the fact that the library is known. Most of the objects are instantiated with the NEWOBJECT() where both the class and the class library are specified. And in those cases almost no errors. So, before I do anything else, I changed the code to almost always (as much as I can), when instantiating the class, rely on both the class name and the class library (VCX). This, hopefully, will minimize or eliminate the error all together. Tonight I will update the customer who has all these problems and monitor the error log.
>
>>File read errors occur if you application has some file handles open to recources over a network connection and the connection drops for one or another reason, even if it is for a short time.
>>
>>The way to solve it is that your application should run locally and all the files it accesses (except for the database) are available locally as well.
>>
>>Walter,
>>
>>
>>>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
Previous
Reply
Map
View

Click here to load this message in the networking platform