LabVIEW
Labview 2011, Is this the buggiest Version ever?
In terms of reuse I have two viewpoints. As long as it is a library LVOOP is usually not necessary unless you start to think about implementing some truely universal interface to various different components. Then the OOP dynamic dispatch mechanisme really makes LVOOP interesting. It can be solved with other means such as VI Server dynamic dispatch and I have done so in the past, but it is a bit cumbersome and LVOOP makes maintenance of such an interface quite a bit easier. Now if LabVIEW had real interfaces, that can be used for this it would allow to develop and modify such hierarchies without the need to keep them all in memory during development, but it's still useful.
In terms of applications frameworks I see some real benefit in LVOOP. Traditional frameworks based on templates all have one big problem. Once you use such a template framework and build your application with it, there is virtually no possibility to add in a new version of the framework into an existing application, as the application has modified the framework in several ways and hooked into it on many occasions. LVOOP could allow to define these interfaces more clearly, so that replacing the framework later on with a new version is still pretty straightforward. But that of course requires that you define those interfaces well and I mean really well, or you end up with the same mess as with the traditional template frameworks. And this clear interface definition could be in fact done with the more traditional approach too, only I have never found the time and spirit to really go through with it. And this makes me skeptical that I would go through with it in LVOOP. LVOOP facilitates this to some degree, but the hard part of defining those interfaces still needs to be done.
Ben wrote:
Before I was thinking LVOOPidly, I would just implement the difference in the code that used to DO functions to use one method or the other.
Applying OOP I added another abstraction layer that i called the "Cylinder-Selector" set of VIs that knew which version to use based on init settings.
That's what I end up with almost anything in my application, but using Action Engines instead of LVOOP. I know Action Engines are in fact some sort of OOP but then upside down and inside out. They contain in fact the methods and data at the same time, which is sometimes a problem, but for a lot of things work perfectly for me. They are a bit hard to handle for someone not used to this kind of architecture, but allow me to add quickly new features into the application without many changes to the rest. Basically it often boils down to some kind of UI changes to make the function available somewhere and some program changes in the action engine and everything works with minimal changes to the rest.
This all gets sometimes a little more problematic when I have data that is in fact some sort of array or such. Then instantiating a new object is easier than adding some sort of indexing mechanisme to the action engine. However I still have this feeling of LVOOP being a somewhat heavyweight implementation for the purpuse of handling large amounts of data as individual objects, so even there you often end up encapsulating the array itself into the object instead of creating an array of objects, and then it looks quickly much more similar to my action engine solution, and has the same limits.
Action Engines work so well for me that I have a really hard time to justify the efforts to learn LVOOP 
@rolfk wrote:
Ben wrote:
Before I was thinking LVOOPidly, I would just implement the difference in the code that used to DO functions to use one method or the other.
Applying OOP I added another abstraction layer that i called the "Cylinder-Selector" set of VIs that knew which version to use based on init settings.
That's what I end up with almost anything in my application, but using Action Engines instead of LVOOP. I know Action Engines are in fact some sort of OOP but then upside down and inside out. They contain in fact the methods and data at the same time, which is sometimes a problem, but for a lot of things work perfectly for me. They are a bit hard to handle for someone not used to this kind of architecture, but allow me to add quickly new features into the application without many changes to the rest. Basically it often boils down to some kind of UI changes to make the function available somewhere and some program changes in the action engine and everything works with minimal changes to the rest.
They work so well for me that I have a really hard time to justify the efforts to learn LVOOP
I'm not going to try and convert you Rolf, dont worry. I am just shaing ideas.
What I was saying was the OOP theory suggested the extra layer of abstraction that I implemented in a non-LVOOP app.
Here is a challenge that I am sure you have run into and is dirt simple to implment using LVOOP.
You have an Action Engine that controls a widget and it works fine. Your customer says "Great, now I want ten of them running at the same time." Depending on the details of how you implemented your AE, you are either modifying the AE or resorting to clones and VI server techniques (insert cringe emoticon here).
But in LVOOP the data is not inside the Methods but is stored outside them and only pointe to when invoking the method. So all I need to use 10 of the widgets is 10 instance of the class data stored outside the methods. The most I have to do it make sure the methods are set re-entrant.
I have to say that your observation LVOOP and AEs are "Action Engines are in fact some sort of OOP but then upside down and inside out" was one of my observations as well and did require a paradigm shift. But it was a good shift.
Take care,
Ben
@Ben wrote:
Here is a challenge that I am sure you have run into and is dirt simple to implment using LVOOP.
You have an Action Engine that controls a widget and it works fine. Your customer says "Great, now I want ten of them running at the same time." Depending on the details of how you implemented your AE, you are either modifying the AE or resorting to clones and VI server techniques (insert cringe emoticon here).
But in LVOOP the data is not inside the Methods but is stored outside them and only pointe to when invoking the method. So all I need to use 10 of the widgets is 10 instance of the class data stored outside the methods. The most I have to do it make sure the methods are set re-entrant.
I'm aware of this and even mentioned this specific case in my previous post
And yes there LVOOP wins hands down, BUT...
In most cases I would probably already have forseen the possibility that this is something that might be desirable at some point and likely have added the index support in the AE to start with. 
Yes it makes the AE somewhat complexer and the need for wrappers to access the AE more desirable but it works quite well.
Now if I would offer that change to the client as a small minor update or as a new feature is of course a different question. 
After all I did spend the extra time to support that feature at some point, just not at the time it might get billed.
@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.
OK, back to the original problem. Did you make any attempt to narrow it down to something more specific? (e.g. third party dll or driver). Did all installations occur from the same network location? Maybe something was ccorrupt?
What kind of crashes are these? Do they trigger any kind of automatic error reporting? Is there anything in the error log?
Here is another Nail:
Why am I working Saturday morning (Because I am Debugging Labview!)
I have 2 seperate threads that have the same base class.
I have found one class consuming queue commands from the other.
Ah, You say, Bad Programming, You have shared a Queue you Noob.
Alas, this is not the case, I have checked the References, they have different Hex values (See Attached)
They do share a Queue Check .VI though, it reeks of some sort of Buffering problem.
