From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Executable flashes at startup if the top-level VI is in a library

I noticed, when one of my LabVIEW executable starts, the front panel of the top-level VI always flashes briefly from its "development look" to its "runtime look", as if it was opened before the LabVIEW runtime starts.

 

Front panel of the top-level VI in development:

raphschru_1-1730507853083.png

 

Window Appearance config:

raphschru_2-1730508922620.png

 

Window Run-Time Position Config:

raphschru_3-1730508981953.png

 

 

When starting the executable, the front panel always flashes like that:

Executable Front Panel Flashes at Startup.gif

My application is only 1MB, so it should load quickly.

 

I've tried all sorts of hacks, like:

 - checking "Window runs transparently" with transparency to 100%.

 - setting the runtime position to "Minimized" (with "Allow user to minimize window" checked).

 - adding "HideRootWindow=True" to the executable ini.

 

Anything I've tried, there was always some kind of ugly flashing...

...Then I dragged my top-level VI out of its owning library, recompiled and the issue disappeared completely!

So I wonder if it is a bug or if it is a somehow a performance issue due to the fact that the top-level VI forces the library to load before starting?

 

Attached is an example project to reproduce the issue.

Executable "Main in Library.exe" uses a Main VI from a dummy library > flashes at startup.

Executable "Main.exe" uses a similar Main VI that is NOT in a library > no flash at startup.

 

I could reproduce this behavior in LV2020-32bit (SP1) and LV2023-64bit (Q3) on Windows 10.

 

Regards,

Raphaël.

0 Kudos
Message 1 of 3
(228 Views)

Thanks for the links.

 

Ah, too bad I didn't find your first linked thread before.

Anyway, the objective of my thread was more to point out a potential bug (which is apparently known since 2015).

As I understood, there seem to be a ton of workarounds (that may of may not work) but the root cause has still not been addressed/identified/corrected after many years...

 

Regards,

Raphaël.

0 Kudos
Message 3 of 3
(72 Views)