Random long loading time when opening program 1

[ducklord]

One of our user desktop PC is facing an unusual long loading time (~10s) when opening a program (written in VFP6). It would show an unusual loading screen before a login screen. The slowness occurs randomly and normally will happen the very first time the said program is opened (e.g. after a computer restart). However, if I close the program (after successful opening) and reopen it immediately, the program would be loaded normally (< 2s) showing us the login screen without showing any of the abovementioned loading screen.

Fortunately, other of our users (including those using desktop PC with similar hardware) do not face the same issue. I am wondering is this something that can be solved with Windows 10 settings? I have tried resetting network but the issue still persists. Wired LAN is running at 1.0Gbps and a ping network test (to server) does not give any error.

Below is the loading screen that appeared when slowness occurred:

Below is our program login screen which we should expect to see instantly whenever we launch a program:

 

[Chris Miller]

The "loading" screen you show is the _SCREEN, a Foxpro Window that's part of the VFP development environment but also always present in an EXE at runtime.

This will always show at least for split seconds, even if you start your main.prg with _screen.hide() or _screen.visible = .f., but usually not for 10 seconds.
A way to not show it at all would be having a config.fpw file with SCREEN=OFF as one of its lines. And including that into the built EXE. I assume you're just an application user, not the vendor, so you won't be able to make that change.

It won't make any difference of loading time, though, as it just suppresses showing the _SCREEN. The time it takes before the first actual application form appears will not change, likely. I don't know what could cause this. Since you can see the screen that's strange, because the only cause I could think of is the loading of the runtimes. At that stage they should have been loaded, already. Unless this FoxPro system window _SCREEN does not depend on the VFP runtime to be loaded and is created by the C++ runtime VFP itself and all VFP applications also depend on. And the EXE may find that locally within the Windows installation.

If that assumption is right, you're broadly speaking having a network problem at least for that client, having difficulties to load even just the runtime files from a network share. That could be due to hardware faults, wrong routing that make a network package go rounds before arriving at its destination, and many more network problem related reasons.

But all that said, even if you suppress the _SCREEN, your only chance for a fast load/start is having both EXE and runtimes (that is vfp6r.dll and some other DLLs) on a local drive. If that's already the case then I'd be surprised and would check if the local drive is healthy.

Chriss

 

[Mike Lewis]

You say that this is the only computer that has this problem: that the other users don't see it. So you need to ask yourself how this one computer is different from the others. You say they all have similar hardware. But are there any differences in the configuration? In the software, or the network connection, or in how the individual machines are configured? In general, answering that question is a good first step in solving this kind of issue.

One possibility is that the offending machine has a more aggressive anti-virus system. (I'm not saying that that is a likely solution, only that it is sort of thing to look for when examining the differences between the computers.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Tore Bleken]

If you have non existent folders in your path, startup may be very slow.

 

[GriffMG]

If you have non-existant printers that can slow things down initially too

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
​

 

[Chris Miller]

From an administrative perspective, it would be the simplest to replace this one computer. If only temporarily, when you connect a working client to this network place, ie. network cable hub this computer connects to (even if it's wifi, the replacement client would have the same wifi conditions), then you can easily find out whether it's the network environment of the failing client, because another client that's ok for itself where it is right now would have the same network difficulties.

If, on the other hand another client works at this place, you can find out what computer configuration differs, or for sake of reducing analysis (time) costs, which can easily rise over the rest hardware value, you simply replace this computer and install it like other clients again.

Chriss

 

[Ig mod apk]

The issue you're describing with the unusual long loading time for a program written in VFP6 on a specific desktop PC seems to be isolated to that particular computer. Since the problem occurs randomly and generally only on the first launch after a system restart, it may be related to the PC's configuration or environment.

Here are some steps you can take to try to diagnose and resolve the issue:

Check Hardware and Drivers:

Ensure that the desktop PC has the latest drivers for all its components, including network drivers, graphics drivers, and storage drivers.
Verify that there are no hardware issues, such as a failing hard drive or insufficient RAM.
Review Startup Programs:

Check the programs that launch at startup. Excessive or unnecessary startup programs can slow down the boot process.
You can use the Task Manager's Startup tab to manage these programs.
Examine Anti-Virus or Security Software:

Sometimes, security software can slow down the initial loading of programs. Try temporarily disabling the security software to see if it makes a difference.
Clean Up and Optimize:

Regularly clean up unnecessary files and folders on the PC. You can use built-in tools like Disk Cleanup to do this.
Consider defragmenting the hard drive if it's not using an SSD.
Review Group Policies:

Check if there are any Group Policies on the PC that might be affecting program startup.
Windows Updates:

Make sure Windows 10 is fully updated. Sometimes, performance improvements are included in Windows updates.
Event Viewer:

Check the Windows Event Viewer for any error messages or warnings that might provide clues about the slowdown. Look in the Application and System logs for relevant entries.
Profile and User-specific Issues:

Create a new user profile on the PC and see if the issue persists. This can help determine if the problem is related to the user's profile.
VFP6 Configuration:

Review the VFP6 configuration on the problem PC. Make sure it's set up correctly and isn't conflicting with other software.
Network Configuration:

Check for any unusual network configurations on the affected PC. Ensure that it's connected properly and has the correct network settings.
If none of the above steps resolve the issue, it might be a specific software or system configuration problem unique to that PC. Consider seeking assistance from an IT professional or your software vendor for further troubleshooting.

As for your request to "add insta mods," I assume you're referring to your website for sharing Instagram mods. If you have specific questions or need assistance related to that, please feel free to ask, and I'll be happy to help.

 

[ducklord]

Dear all, thanks for the feedbacks. I have finally found the cause of this issue. The issue persists whenever the "File and Printer Sharing for Microsoft Networks" option of the user pc network controller is unticked. Once I tick it, the issue is solved. Thanks again.

 

[Chris Miller]

Then that application likely uses the function ANETRESOURCES to find two types of network resources: File shares and printers. That can take very long especially and ironically if no network resources are available.

That's not happening for every EXE built with VFP, which is a slight relief.

Chriss