Jim Kring

Debugging classes is #1 on my list. It is impossible to track down an error inside a class, since a broken member causes every VI in the class to be broken. broken member VI ==> broken class ==> every member of the class is broken I've talked to others who have spent enormous ammounts of time trying to track down trivial bugs in classes.

I feel that the decision of whether to employ OOP is mostly a matter of balancing effort with result. As the OOP tools continue to improve, I will be using OOP more often :-)

Hello All, I'm trying to figure out a way to achieve something that seems a little bit tricky. In fact, the problem I'm having might be a bug. Basically, I want to use the tree control's Allow Dropping Between Item feature (a built-in drag and drop function) along with the tree's Drag Over event which allows you to programmatically enable/disable the user's ability to drop the item that they are dragging. Here is what the Allow Dropping Between Item feature looks like: The problem is that whenever I register for the Drag Over event, the Allow Dropping Between Item feature/behavior goes away. Here is an example of the problem: Download File:post-17-1156820022.vi FYI - I've tested in 8.0 and 8.2 and this behavior is the same in both versions. Thanks :-)

Well, that still depends on the original question -- is the question what percentage of projects use OOP or is the question what percentage of your programming is OOP? My point is that there is a time and a place for OOP. I do not use OOP for every problem. For example, if I have to add two numbers together, I will not create a class called Numeric and implement an Add method. This is just too much effort for too little return.

Yeah, I use a lot of different GOOP styles, too. Which one I use depends on the requirements and my mood. I am not sure how to answer the question of what percentage of my total development uses GOOP, but nearly every non-trivial application employs some OOP analysis, design, and implementation.

Actually, I heard that the .20 idea came down from the very Top of NI ;-)

Mark: Actually I was working on the same thing, for the past couple days :-) I've got some ideas too. I think that we're going to come up with something great, here!

Aart-Jan, > I only looked at project 3, and I like it. I REALLY like #3, too. I think that it is the way to go, moving forward. > One of the great features of storing by queue reference is the ability to cut loose from the dataflow paradigm. Therefore I added a modified example to project 3 to emphasize the different nature of ReferenceClass.lvclass: its value is static and there doesn't require dataflow. The thick green wire suggests a real object, but it doesn't require dataflow wiring like ordinary objects do. One does need to be careful to prevent race conditions, though. My 2 cents.. Yes, I took it for granted that most people here (on LAVA) would already understand the implications of by reference objects -- this is the GOOP, forum after all . The implications being the following: data does not flow. only a reference flows, unchanged, which points to the data forking a wire copies the reference but not the data race conditions and locking must be considered, since calls may be made in parallel I think that your additional example drives these points home. Another example that I like is a dual loop, where each loop has a reference to the object and one loop modifies the data (calls SetValue) while the other loop reads the data (calls GetValue). On that note, there is a very nice (IMO) overview of by reference GOOP in appendix D of LabVIEW for Everyone, 3rd edition (this appendix is 20 pages long). Cheers,

Hello All, I have posted an article on my blog called Refactoring the ReferenceObject example in LV 8.2, which is an brief analysis of the by reference object-oriented programming example that ships with LabVIEW 8.2. I have created three new examples, which (IMO) greatly improve the usability of this pattern. I look forward to your feedback (please feel free to discuss it here) and any ideas that come out of it that might improve the designs. I have attached the downloadable examples to this post. (They are also available for dowload on the article page.) [update 8/19/2006: I have updated example 3, after learning about a new LabVIEW feature that allows a queue reference to be linked to a type definition of the element type. Thank you, Philippe Guerit, for telling me about that. ] Cheers, Download File:post-17-1156035929.zip Download File:post-17-1156035941.zip Download File:post-17-1156055411.zip

Jason: I dedicated three whole pages of LabVIEW for Everyone, 3rd edition, to the Mixed-Signal graph. I think that it is a very cool feature and I can't wait to use it on a project -- In fact, I think that I might be able to use this on a customer project, right now.

I recommend always using the Variant to Data function, in order to perform normal numeric coercion to and from the enum data type. If you use the Type Cast function and your numeric representations don't match, then you will not alway get what you expect.

I have attached your document to this thread, so that it will always be available. It seems that this document likes to play hide and seek Download File:post-17-1155782259.doc Download File:post-2-1155783337.pdf

Use the NI Example Finder and search for "object-oriented". There is a "by reference" example, that shows how to use a queue reference as an object that refers to global data. Other global/shared object frameworks can be implemented in the same way.

I, too, hope that the Amazon shipments will arrive before Monday. The first shipments (sent directly) from the publisher have arrived, but it is difficult to say when they will start shipping from Amazon. If you swing by the JKI booth on the NI Week expo floor (booth # 1106), you are welcome to thumb through one of our display copies. Also, if you come to the LAVA/OpenG BBQ, you might even win a signed (by Jeffrey Travis and me) copy. Regards, -Jim

Danny, Please see this thread on the OpenG discussion forums, about the pipes library. Regards,

I have no idea, actually. It could be pure chance or it could be a conspiracy Either way, I guess that's what happens when you sit in the front row Sorry, Norm, I wasn't trying to take sides. I really want to learn about The Art of Creating Dynamic; Flexible LabVIEW Applications, too. I'm looking forward to the arm wrestling match, guys.

Hey Richard! I'm looking forward to your presentation and seeing what's new and exciting in LabVIEW Embedded. See you next week

In that podcast, Christina Rogers mentions that she worked on the "navigation window with the bird's eye zoom." Hmmm, that feature description sounds familar.

But, the software (is still) the instrument. ;-)

This is a known issue with the latest version. Try installing version 2.2.0, as I think this one is working fine. Also, you might want to install VI Package Manager while you're at it.

I've had a lot of success using Enterprise Architect from Sparx Systems.

Pete, LabVIEW for Everyone is a good read for someone getting started in LabVIEW. (Of course, this is my biased opinion.) Also, here is a LabVIEW for Dummies website. Regards, -Jim

Yes.

That depends on whether the driver DLLs have the same interface on Linux as they do on Windows. If that is the case, then you should be alright. However, you will have to link to the .so files instead of the .dll files, unless you happened to have entered "dllname.*" as the shared library name, -- this allows LabVIEW to link to the platform specific shared library name when moved to another platform (assuming that the shared libraries have the same file name, minus the extension).

I like this technique, too.