04-03-2013 01:32 PM - edited 04-03-2013 01:34 PM
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)
04-03-2013 02:22 PM
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.
04-03-2013 02:28 PM
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.
04-03-2013 02:39 PM
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
04-03-2013 02:59 PM - edited 04-03-2013 03:07 PM
@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...
04-03-2013 03:44 PM
@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
04-04-2013 08:16 AM
@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.
04-04-2013 09:54 AM
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.
04-04-2013 10:21 AM
@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.
04-04-2013 10:27 AM
@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.