LabVIEW
Seperate Complied code
- last edited on by
Content Cleaner
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@cbutcher wrote:Quoting incase of a future broken link:
> When you edit the source code of the VI, LabVIEW automatically recompiles the VI to reflect your changes in the compiled version of the code. LabVIEW also automatically recompiles all VIs that call the changed VI, resulting in unsaved changes to the calling VIs.
I'm pretty sure that is not true. Sometimes callers are changed, but not always.
If a changed VI changes the callers, all caller callers should be changed (recursively). I don't see that happening. But even the direct callers do not always change.
Apparently, callers are sometimes changed because they need a recompile. If SepCC is off, the calling VI is changed. If SepCC is on, the calling VI isn't changed.
He quoted directly from the source: Facilitating Source Control by Separating Compiled Code from VIs and Other File Types
That doesn't make it true.
If Separate From Source is OFF, it is true. You change a subVI and your main VI would have a "dirty dot", indicating there are unsaved changes due to the object code being updated.
- last edited on by
Content Cleaner
@crossrulz wrote:
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@cbutcher wrote:Quoting incase of a future broken link:
> When you edit the source code of the VI, LabVIEW automatically recompiles the VI to reflect your changes in the compiled version of the code. LabVIEW also automatically recompiles all VIs that call the changed VI, resulting in unsaved changes to the calling VIs.
I'm pretty sure that is not true. Sometimes callers are changed, but not always.
If a changed VI changes the callers, all caller callers should be changed (recursively). I don't see that happening. But even the direct callers do not always change.
Apparently, callers are sometimes changed because they need a recompile. If SepCC is off, the calling VI is changed. If SepCC is on, the calling VI isn't changed.
He quoted directly from the source: Facilitating Source Control by Separating Compiled Code from VIs and Other File Types
That doesn't make it true.
If Separate From Source is OFF, it is true. You change a subVI and your main VI would have a "dirty dot", indicating there are unsaved changes due to the object code being updated.
Definitely not ALWAYS when I do it.
I can open my main, open a sub VI, remove an error wire connected to a node inside a case, and the main will not change.
When the error wire is on the sub VIs main diagram, it does change the parent.
Here's another situation.
If the sub VI has two message boxes in it, deleting one doesn't effect the caller. Deleting them both will. If there are none, adding one will change the caller, adding a 2nd doesn't.
The Sub VI has certain properties, like if it's ASync (has async nodes) and whether it "feeds through" (that's a sub VI property). There might be others. If these change, the callers needs to be recompiiled.
Search LabVIEW like a graph! 
@JÞB wrote:
By "feeds through" I assume you mean that the subvi is inlined?
No.
If terminals of a VI 'feed through' callers don't need to make a copy.
So, a simple error in connected to error out for instance... The caller doesn't make a copy of the error, simply because there's no need. The VI get's marked as 'feed through=true'. That's a scripting property...
If this property changes, the caller needs to be changed. Because this means it should make a copy, or can avoid making a copy.
Keeping it off causes more changes in callers, but not as much as suggested. Not every change triggers all callers to change.
EDIT: Feed Through is actually a method:
wiebe@CARYA wrote:
@JÞB wrote:
By "feeds through" I assume you mean that the subvi is inlined?
No.
If terminals of a VI 'feed through' callers don't need to make a copy.
So, a simple error in connected to error out for instance... The caller doesn't make a copy of the error, simply because there's no need. The VI get's marked as 'feed through=true'. That's a scripting property...
If this property changes, the caller needs to be changed. Because this means it should make a copy, or can avoid making a copy.
Keeping it off causes more changes in callers, but not as much as suggested. Not every change triggers all callers to change.
EDIT: Feed Through is actually a method:
I did not know that! Certainly what you demonstrated has buffer allocation effects on the caller. Thanks for sharing!
