LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW executable takes a long time to open File Explorer

Solved!
Go to solution

OK so what appears to be happening is that my installer is corrupting something with NI MAX.  The program works fine if I bring the executable with flash drive and don't use an installer.  But as soon as I run installer it starts lagging file explorer again until NI MAX is repaired through NI package manager

----------------------------------------------------
Studying for CLA.
LabVIEW, inherit from social media habits!
0 Kudos
Message 11 of 14
(558 Views)

I have studied this thread with some interest as I am having a similar problem. Unfortunately, the fixes offered here didn't work for our issue which seems even a bit more obscure.

 

Anyway, here's what we have going on:

 

I'm installing a LV (2019) executable on two essentially identical touchscreen PCs. On one of the systems -- let's call it System #1, the file dialogs work as intended. (This is the same behavior I have seen with other installations on other PCs using the same installer codebase.)

 

However, on System #2, an installation from the same installer archive has the problem similar to the one described in this thread. When opening the Windows file browser to select a directory to extract data, the file browser bogs down to a crawl and seems unresponsive. (If you wait long enough, you will see that it is indeed responding. Just.... extremely.... sloooow...ly.)

 

Perhaps the oddest part of all is that, other calls to the Windows file browser, from other parts in the same executable, are working just fine. It's only this one instance of the file browser that is causing the issue. (I looked carefully at the code, and there doesn't seem to be any thing out of place. And in any event, the executables installed using the same installer don't do this on other "model-identical" PCs.)

 

Following the suggestions in this thread, I tried repairing everything on this PC using the Package Manager. I recompiling the original code and built a new installer. For a sanity check, I even installed the recompiled code on a different PC the verify it works elsewhere. It works as intended everywhere except on System #2. 

 

When repairing the NI elements failed, I punted and removed all the NI software, reinstalled Windows, and reinstalled everything from scratch again. I also double-checked the BIOS settings to verify System #1 and System #2 are configured the same way from a hardware perspective. After all of this, the peculiar behavior remains. 

 

(This is a machine vision application, so the only hardware we have connected are a GigE camera and a USB DAQ unit.) 

 

At this point, I can't think of anything else to try. Has anybody else seen something like this? Any suggestions...?

 

-- Dave

 

0 Kudos
Message 12 of 14
(429 Views)

@The_Seeker wrote:

I have studied this thread with some interest as I am having a similar problem. Unfortunately, the fixes offered here didn't work for our issue which seems even a bit more obscure.

 

Anyway, here's what we have going on:

 

I'm installing a LV (2019) executable on two essentially identical touchscreen PCs. On one of the systems -- let's call it System #1, the file dialogs work as intended. (This is the same behavior I have seen with other installations on other PCs using the same installer codebase.)

 

However, on System #2, an installation from the same installer archive has the problem similar to the one described in this thread. When opening the Windows file browser to select a directory to extract data, the file browser bogs down to a crawl and seems unresponsive. (If you wait long enough, you will see that it is indeed responding. Just.... extremely.... sloooow...ly.)

 

Perhaps the oddest part of all is that, other calls to the Windows file browser, from other parts in the same executable, are working just fine. It's only this one instance of the file browser that is causing the issue. (I looked carefully at the code, and there doesn't seem to be any thing out of place. And in any event, the executables installed using the same installer don't do this on other "model-identical" PCs.)

 

Following the suggestions in this thread, I tried repairing everything on this PC using the Package Manager. I recompiling the original code and built a new installer. For a sanity check, I even installed the recompiled code on a different PC the verify it works elsewhere. It works as intended everywhere except on System #2. 

 

When repairing the NI elements failed, I punted and removed all the NI software, reinstalled Windows, and reinstalled everything from scratch again. I also double-checked the BIOS settings to verify System #1 and System #2 are configured the same way from a hardware perspective. After all of this, the peculiar behavior remains. 

 

(This is a machine vision application, so the only hardware we have connected are a GigE camera and a USB DAQ unit.) 

 

At this point, I can't think of anything else to try. Has anybody else seen something like this? Any suggestions...?

 

-- Dave

 


Dave,

Thank you for the detailed information.   I can help you best by summarizing your findings as:  "Action A performed on X has different results from Action A on Y."

 

The sane conclusion then is: X is not equal to Y.  Period, no other conclusion can be drawn.  Your post shows you have investigated and ruled out most likely OS and Software dependencies.   That leaves hardware as the primary suspect.   

 

I recommend following up by running diagnostic tests on the suspect system that may reveal corruption of the file system hardware.  Likely causes might include bad sectors or other inaccessible system resources, i.e. the machine is toast.


"Should be" isn't "Is" -Jay
0 Kudos
Message 13 of 14
(409 Views)

@The_Seeker wrote:


When opening the Windows file browser to select a directory to extract data, the file browser bogs down to a crawl and seems unresponsive.


At this point, I can't think of anything else to try. Has anybody else seen something like this? Any suggestions...?


I don't have an answer for why it's working slowly and I haven't looked at the thread, but I would suggest considering calling a different browse dialog to see if it would help. This can be something built in (like FolderBrowserDialog in .NET or the various versions posted to this thread) or you can implement it yourself. This could be something as simple as a listbox where you show .. on the first row to go one level up and the subfolders in the other rows and use the list folder primitive to get the data.


___________________
Try to take over the world!
0 Kudos
Message 14 of 14
(374 Views)