LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Splash Screen Issues

I Played with the build spec some more.

Changing the source file settings destination for the class folder cures the apparent hang in the exe.  Probably some strange effect of the string constant into build path on the BD of Launcher.vi)

Capture.PNG


"Should be" isn't "Is" -Jay
0 Kudos
Message 21 of 33
(737 Views)

Jeff, you cheated.  The launcher is no longer dynamically called.  And the class won't be included, so I bet you are getting an error as well.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 22 of 33
(716 Views)

I noticed that Launcher.vi was no longer being called by reference, but was rather being loaded with caller.  Is that something you did for a reason?  Is it that or the source files thing that got rid of the hang? 

 

I do know that I definitely don't want to include all the source files in the data folder for my build though.  I'd rather have the pause.

 

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 23 of 33
(713 Views)

The call set-up was one thing I tried and it did not have any effect. the source file destination was the key that turned the pause off.  I suspect that string constant could be given a switch to look in the correct path for the class if running in the RTE based on App.AppKind property and you could avoid both the pause and the class folder


"Should be" isn't "Is" -Jay
0 Kudos
Message 24 of 33
(707 Views)

@crossrulz wrote:

Jeff, you cheated.  The launcher is no longer dynamically called.  And the class won't be included, so I bet you are getting an error as well.


Yeah, if you throw an error dialog after the Get LV Class Default Data there's a file not found error, since as you say it's not where it's looking anymore.  As Jeff noted you could put a App.Kind check, but that doesn't get around me having to include all of my source files, which is not going to happen.

 

The call setup probably didn't have any effect since nothing extra really got added to the VI Hierarchy, since the class was still being loaded dynamically.  I've made some slight modifications to my actual application to do the same.

 

Edit: The error is probably what's causing it to not pause more than the file settings, since it's not loading actually loading anything...investigating now...

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 25 of 33
(699 Views)

@elset191 wrote:

Edit: The error is probably what's causing it to not pause more than the file settings, since it's not loading actually loading anything...investigating now...


Confirmed

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 26 of 33
(687 Views)

@elset191 wrote:

@crossrulz wrote:

Jeff, you cheated.  The launcher is no longer dynamically called.  And the class won't be included, so I bet you are getting an error as well.


Yeah, if you throw an error dialog after the Get LV Class Default Data there's a file not found error, since as you say it's not where it's looking anymore.  As Jeff noted you could put a App.Kind check, but that doesn't get around me having to include all of my source files, which is not going to happen.

 

The call setup probably didn't have any effect since nothing extra really got added to the VI Hierarchy, since the class was still being loaded dynamically.  I've made some slight modifications to my actual application to do the same.

 

Edit: The error is probably what's causing it to not pause more than the file settings, since it's not loading actually loading anything...investigating now...


That is exactly what I suspected.  "Reading" of a file is really fast when there's no file to read.Smiley Tongue


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 27 of 33
(669 Views)

Trying to catch up here.  It seems that there is no good workaround to that issue.  As long as you want to load a VI dynamically, it will hang the UI thread.  Is this correct?  Some posts made it looks like recompiling and saving the VI may solve the issue but that was not reproducible !?!?  As for my original idea of loading the subVIs first and separately, if you are trying to load a class into memory, that obviously won't work as it has to be loaded alltogether.  It would only work if you are loading VI with lots of sub VIs.

 

0 Kudos
Message 28 of 33
(660 Views)

@OlivierL wrote:

As long as you want to load a VI dynamically, it will hang the UI thread.  Is this correct?


No.  We found that is was the dynamic loading of a class using Get LV Class Default Value.vi that caused the issue.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 29 of 33
(652 Views)

@crossrulz wrote:

@OlivierL wrote:

As long as you want to load a VI dynamically, it will hang the UI thread.  Is this correct?


No.  We found that is was the dynamic loading of a class using Get LV Class Default Value.vi that caused the issue.


Well, if Darin is to be trusted, it seems like dynamic loading always happens in the UI thread, regardless if its Get LV Class Default Value or any other means of dynamic loading.  I think this is true because when I switched my call to Launch.vi to be static the progress bar moved just a bit until it then got to the class loading.  If I called Launch.vi by reference the bar didn't move at all until Launch.vi and the classes were loaded.

--
Tim Elsey
Certified LabVIEW Architect
0 Kudos
Message 30 of 33
(646 Views)