separate compiled code from source, no effect?

[crossrulz]

If memory serves, I had to force a compile at least once before the separate took effect.  The mass compile did it for me when I made that change on a project to separate compiled.

[thutch79]

Worth a try. Thanks. I will have to wait until a good time to be able to check in all files to SVN again. I'll report back when I've tried it.

[Joseph_Loo]

Have you tried to place your items in a project and use the project property to set compile source as separate. It seems to work for me without problems.

[thutch79]

Huh....I tried looking for a global setting on the project in the past. I never knew that was there. I will try that after our next SVN branch merge.

[MikeBowen]

I am in the process of running your tool.   Will let you know how it works.  What prompted it for me is that an instrument class I was working on has one of the files show up as modified when I open it, and it is one of a very long list.  This beats opening them all up and checking them by hand, and I couldn't figure out how to check it programmatically.  I will get around to figuring it out, eventually.  🙂

Mike

[thutch79]

I have now setup my project so all VIs, class, controls, etc all have seperated compiled code. Also all new items created will have seperated compiled code. I've mass compiled everything. From my experience, it has absolutely no effect. Anytime I change a subvi, any VI that calls it wants to be saved as well. Maybe I don't have a good understanding of how this should work, but I thought it was to prevent unnecessary save requests, right?

In the mean time, I've also moved to LV 2013. It doesn't seem to help in 2013 either.

[altenbach]

---

@thutch79 wrote:

I have now setup my project so all VIs, class, controls, etc all have seperated compiled code. Also all new items created will have seperated compiled code. I've mass compiled everything. From my experience, it has absolutely no effect. Anytime I change a subvi, any VI that calls it wants to be saved as well. Maybe I don't have a good understanding of how this should work, but I thought it was to prevent unnecessary save requests, right?

---

What are you actually changing in the subVI?

If you change the code of the subVI, no changes need to be made to the caller. if you change the name of the subVI, the caller needs to be updated, of course.

(not sure what happens for inlined subVIs...)

[JÞB]

To follow up and expand on Christian's points.

Some changes to a sub-vi will always require a recompile of the caller. Some of these are obvious if you really think about it, some are not so obvious.  But, if you break the interface to the caller (the connector pane) you will need to resave the caller

1. Datatype change to a wired input terminal that is not dynamic dispatch (you really can't change the datatype of a DD terminal)
2. Direction change to a wired input
3. Connector Pane pattern change
4. Recomended or optional terminals marked as required
5. Change to a wired enum type def
6. Change to which terminal is dynamic dispatch

This list is not necessarilly complete

[thutch79]

I haven't paid too much attention to what's changing versus what callers require saving. I'm sure it's my understanding of the feature that is lacking. Thanks for the list.....that's helpful.

[Garvacious]

I too am disappointed- I was hoping that enum typedef changes would stop trying to recompile everything that called them.  I guess this cannot be prevented- not sure why as I assumed that the "source" part of the file only contained the block diagram itself and not the compiled code.  Which makes me wonder, what situations WOULD this option prevent LabVIEW from recompiling files that were not physically changed in?  The enum typedef propagation was one of my chief frustrations when trying to use LV with source code control.