LabVIEW
Works in IDE but not in exe
And to remove all doubt...
The above code compiled into an exe will cause LV exe to crash & disappear if the PATH input points to a sufficiently large vi that does not contain compiled code.
@Frozen wrote:
@JÞB wrote:
@billko wrote:
The thing that defeats all my possible scenarios is that this doesn't happen all the time...
That's exactly what has had me thinking about the use of Mods.vi. that property simply makes no sense in an application. Why would the flag exist inside an exe?
I am not following your train of thought. The exe is running with LV code as the input file, not another exe.
Exactly like you point out here:
@JÞB wrote:
But, I could see a use case to have an exe parse through source code so, it is simply a bad usage or the error being thrown should be thrown more often.
I would get rid of the suspect property nodes in the exe.
Unfortunately, it is the open reference that is causing the crash with missing compiled code, as seen in the original post.
My attempt to check for compiled code first (seen below) still causes the exe to crash/disappear ☹️
Guess I will have to put a note into the readme file about the potential crash using dev code. Not an optimum solution.
No it is not optimal! Bug, quite likely! I can wave a hand \/\/
Note that although separating compiled code makes your SCC life easier, it isn't a requirement.
I have huge projects that don't have compiled code separated. Esp. if you're on your own it isn't that much of a problem (in fact, no problem at all).
Search LabVIEW like a graph! 
@Mark_Yedinak wrote:
wiebe@CARYA wrote:
Note that although separating compiled code makes your SCC life easier, it isn't a requirement.
I have huge projects that don't have compiled code separated. Esp. if you're on your own it isn't that much of a problem (in fact, no problem at all).
Even on a one man project it will dramatically improve the value of your SCC. If you have some typedef that is used in LOTS of VIs, whenever you modify the typedef SCC will mark every VI that uses it as modified. A week or two down the line when you discover a bug and want to track down what caused it, your SCC logs will shows tons of VIs that have been modified when in reality only a single typedef changed. Now you either have to have a stellar memory to know exactly what you changed or you have to start looking at all of the code that SCC marked as modified. You will also use less disk space which in these days is not a huge issue given the size of discs but it could still be a concern.
Also, if you modify a subVI, all the VIs that contain it won't recompile, so you don't end up with 100 VIs that changed.
@Mark_Yedinak wrote:
wiebe@CARYA wrote:
Note that although separating compiled code makes your SCC life easier, it isn't a requirement.
I have huge projects that don't have compiled code separated. Esp. if you're on your own it isn't that much of a problem (in fact, no problem at all).
Even on a one man project it will dramatically improve the value of your SCC. If you have some typedef that is used in LOTS of VIs, whenever you modify the typedef SCC will mark every VI that uses it as modified. A week or two down the line when you discover a bug and want to track down what caused it, your SCC logs will shows tons of VIs that have been modified when in reality only a single typedef changed. Now you either have to have a stellar memory to know exactly what you changed or you have to start looking at all of the code that SCC marked as modified.
Well, I don't use type defs that much. Maybe one or two per 1000 VIs.
Changing a VI doesn't change all callers, at least, not always. This would mean that callers are changed, and their callers would also change, recursively, which is definitely not happening.
Only if the connector pane of a VI changes, or if an input\output pair changes from\to feed through, the callers are changed. Or of course if the scope or reentrancy changes. Obviously if the VI is inlined.
Some changes to a type def will change callers even with separate compiled code. Or often they won't change, but break, so they should be changed...
In my experience, it didn't really make that much difference. Definitely not dramatic enough to change this on existing projects. I do prefer it on new projects, although it does seem to cause some problems.
@Mark_Yedinak wrote:
. You will also use less disk space which in these days is not a huge issue given the size of discs but it could still be a concern.
Locally, in fact you'd use as much or more disk space. The compiled code is still stored, and there's a probably (a tiny bit of) overhead.
There's less space used in your repo's, and that could matter as online storage could be expensive. Although it's probably better to focus on things like not storing executables and other binaries like manuals (that aren't source code).
@billko wrote:
@Mark_Yedinak wrote:
wiebe@CARYA wrote:
Note that although separating compiled code makes your SCC life easier, it isn't a requirement.
I have huge projects that don't have compiled code separated. Esp. if you're on your own it isn't that much of a problem (in fact, no problem at all).
Even on a one man project it will dramatically improve the value of your SCC. If you have some typedef that is used in LOTS of VIs, whenever you modify the typedef SCC will mark every VI that uses it as modified. A week or two down the line when you discover a bug and want to track down what caused it, your SCC logs will shows tons of VIs that have been modified when in reality only a single typedef changed. Now you either have to have a stellar memory to know exactly what you changed or you have to start looking at all of the code that SCC marked as modified. You will also use less disk space which in these days is not a huge issue given the size of discs but it could still be a concern.
Also, if you modify a subVI, all the VIs that contain it won't recompile, so you don't end up with 100 VIs that changed.
That is a myth. AKA as not true.
EDIT: OK, it is a myth that without separate compiled code, if you modify a subVI it's callers need a recompile. Technically, you're not saying that, you're saying that if you do separate compiled code that doesn't happen, which is factual.
Not any change to a VI will change it's callers. Not all callers always need a recompile.
If that was true, all callers would need a recompile and in turn all their callers would need a recompile, and as a result, the main VI would always need a recompile. It's not true.
Iff (if and only then) a VI changes in a way that potentially effects the caller, the caller needs to be recompiled.
This only happens (AFAIK) if the VI is inlined, on scope or reentrancy changes, if the connector pane changes, or an input\output pair changes from\to feed through (like error in\error out).
If such a change happens, the callers need to be recompiled. Only if that change effects the connector pane, or feed through of that VI, will callers need to be recompiled. That's rare, so if callers need to be recompiled, that's usually where it stops.
Once code settled well, you can make a lot of changes without getting much changes in SCC. Well, I can, and I do it all the time.
