LabVIEW
Labview 2011, Is this the buggiest Version ever?
I definitely can't echo that. LabVIEW 2011 is one of the most stable versions for me so far (and 2010 was and is also great as I'm still working on projects that started in 2010), maybe with the exception of the legendary 7.1.1. But for anything but single application development the lack of a project window is rather painful.
I had recently some problems with 2010 and 2011 suddenly starting to pop up with all kinds of errors. At the point when I couldn't start it up anymore because of an error message that it couldn't find various files in its resource directory I did a complete disk scan and it found several thousend damaged files all over. After fixing that I had on two occasions that the restored files where actually damaged and still caused problems. Reinstalling the affected toolkits fixed that. Of course the hard disk got in the mean time replaced!
This showed me several things:
- A computer with severe disk damage can still appear to work fine for quite some time but cause random errors.
- LabVIEW in itself seems to be rather stable nowdays but if you somehow pull the floor under its feet, (hardware problems, device driver issues, etc) it will sooner or later go flat on its face
- I need to be more aware about potential issues by doing regular disk scans and other monitoring options
Besides of this issue the only time I regularly or even consistently crash LabVIEW is when I'm doing work on external code. But that is hardly the fault of LabVIEW but the faults the person in front of the keyboard has built into that external code. 
@Timmar wrote:
Fresh Windows 7 x64 Install,
DS2012 (32 bit)t,
Use R/T quite a lot
Agin, this is happening on 4 different machines.
Hmm, the only thing that makes me suspicious here is the W7 64 Bit together with RT. Most of my applications are not RT (and none in LV2011 so far) and I still use W7 32 bit on my main development machine. So it could very well be that the RT Module has some issues on W7 64Bit. I faintly remember other people reporting such problems.
@Timmar wrote:
The bulk of my Code is OOP,
My Boss can crash it just by opening a project.
I just realised that I am usign source control software (Perforce), Easy to blame it, but well written code should be able to report and recover from any event caused by an external system.
Tim L..
GOOP is another thing I haven't bought into yet. For me the efforts to get acquinted with it, simply don't feel like wieghting up against some of the disadvanteges of not using it.
And that is despite having some OOP knowledge from C++ and Java. What I see in OOP often is that while it gets used, it is quite often not a clean and elegant architecture but rather a thrown together bunch of classes and hierarchies. To keep overview there seems almost impossible for me, and I have doubts that I can create a cleaner and eleganter class hierarchy that allows me to keep the overview. So why bother with it? 
@rolfk wrote:
...
GOOP is another thing I haven't bought into yet. For me the efforts to get acquinted with it, simply don't feel like wieghting up against some of the disadvanteges of not using it.
And that is despite having some OOP knowledge from C++ and Java. What I see in OOP often is that while it gets used, it is quite often not a clean and elegant architecture but rather a thrown together bunch of classes and hierarchies. To keep overview there seems almost impossible for me, and I have doubts that I can create a cleaner and eleganter class hierarchy that allows me to keep the overview. So why bother with it?
My first LVOOP code started out looking that way as well. I did not come away from that project with a single function I wanted to or could re-use apart from the rest of the application.
I had not yet "got it" with the OOP theory.
After reading more and applying more OOP theory, my code started to get more "re-usable" and classes started dropping out as re-use fodder.
Eventually I got to the point where I had a LVOOP library developing and each new project contributed another piece to the set.
But since I "write for my audience" and my audience is often LV Basic I grads, I wrtie more code in non-LVOOP that LVOOP. But I have come to realize that my non-LVOOP stuff is a lot like my LVOOP code and the leasons I learned from the foraml OOP theory has made my code easier to read and develop.
So OOP has had a good influence on my code and style.
Re: stability of LV 2011
I have read too many bad posts about LV 2011. Aside from one very short project (1 week) to get a new customer started, I have not developed in LV 2011 and I may actually step over that version completely. I like mnay of you end up at the wrong end of the stick when our project run too long due to LV failures.
Just my 2 cents,
Ben
