Leaderboard

Thanks you. I was working on that on LAVA I. I seem to have lost about 400 posts so give some time to get back to where I was. Once I figure out how to navigate the new forum, I'll do what I can witout distrurbing the SNR. Ben

I posted a utility VI that does this here. -D

Just a few remarks here, although I'm not a .Net Guru at all. I'm not sure if app domain is the right word here but LabVIEW indeed registers the project directory for private assemblies. .Net basically only allows two locations for .Net assemblies and that are the GAC and the private assembly directory, which MS might call app domain. Obviously there is no project directory in a LabVIEW executable and therefore the executable uses the default .Net private assembly directory which is the executable directory itself. One additional complication is that you can only add strongly named (fully versioned and all) assemblies to the GAC. Supposedly, all these restrictions are to avoid DLL hell. The problem here might be really that the .Net reference stores the relative path from the project to the assembly, which would explain the mess you get on different computers causing recompiles all the time. Rolf Kalbermatter

No, I'm fairly sure the absolute path is kept in the VI. My reference to the project was because I remembered something (probably from Brian Tyler's blog) about the project serving as the appDomain and something else (which may not even be correct, since I'm not a .NET programmer, so it's possible I even made it up) about how the appDomain holds the references to non-GAC assemblies. That said, I didn't originally read the original question thoroughly, so here are some options: Make sure they're registered in the GAC instead of being all over the place. Use a typedef for the .NET reference (you might wish to do that anyway, since I seem remember problems from LV 7.0 where a DLL was upgraded and the reference broke, but that may have been COM). This probably won't help if I understand the problem correctly. Do a search. I seem to remember someone complaining in the NI forums about LabVIEW asking for similar saves in 8.5 or 8.6.

Ahh. I have a rule with our programmers. No .NET and No ActiveX. If a "Texty" wants a feature from one of those technologies, he can get off is arse and write it, and while he's at it, make it really easy for use in LV (i.e no obnoxious referencing). You'd be surprised at how often they come up with a far more elegant solution Your options are limited. Unfortunately, the modification bitset is read-only-no help there! You could walk the project list using a vi installed in the environment that re-compiles any vi's when a project is loaded,, but I expect your SC would still complain that the file has changed. The only viable way forward that I can see is to enforce a directory structure so that they can't put the files anywhere and can only check them out to a single "working area" which is the same on all machines. We do this anyway as it means anyone can go to a machines and not spend 10hrs hunting for files.

My work machine is a PC. My home machines & laptop are all Mac. My C++ development is always done under Windows where I have access to that wonderful tool MS Visual Studio. I haven't ever found anything for text programming that comes close to the usability of MSVS. On the other hand, most of my G development these days is done on my laptop where I can use my touchpad, which I find much nicer than a mouse for LV programming (easier to move back and forth from keyboard to mouse as needed).

Ummmmm, no it's not If you only think of OO at the level of encapsulation, sure you could consider it as a glorified cluster (and that's what I suggest when ppl are just starting to use LVOOP), but that's the very simple level of LVOOP. Once you get into dynamic dispatch, inheritance, etc, you'll find the glory of the glorified it more than glorious.

Why choose? You could decide to study scripting LVOOP!

I suggest UML, oh I meant OO of cause ;-) These videos haven't been officially released but could been accessed here at the moment. www.goop.endevo.net/GDS/videos/GDSFeatures www.goop.endevo.net/GDS/videos/GettingStarted www.goop.endevo.net/GDS/videos/DesignPatterns www.goop.endevo.net/GDS/videos/StateMachine www.goop.endevo.net/GDS/videos/Debugger //Mikael (soon releasing the new version of GDS with some UML updated)

Always the heathen . SCRIPTING! Since your only putting aside 1 week, you'll have loads of scripting goodies at the end instead of just a headache.