Neil Pate

As someone wiser (and more sarcastic) than myself has already pointed out... Some people, when confronted with a problem, think “I know, I'll use regular expressions.†Now they have two problems.

I like to try and extend my understanding of things wherever possible, so I can make informed decisions later. This often means trying out features or design techniques I have not used in the past to see if there are better ways of accomplishing things. This is how I have evolved my style over the years. Sometimes the experiment works, sometimes it does not, but I always get to keep some knowledge from the exeperience. One thing I am trying to get my head around is proper OO design (forget LabVIEW for now). This is something I have some understanding of, but could certainly do with more practice; hence the original question. I agree now with Shane that this looks a lot like the Strategy Pattern.

the kool-aid is nice this time of year

Hi All, I have a set of classes representing an instrument driver which allows for different firmware versions. The instrument can operate in certain modes, and depending on the mode it periodically returns a different number of characters. What I would have done up till now is have a "mode" enum in the parent, and have a single Read method and inside that using a simple case structures read a different number of bytes depending on the mode, and then parse the string accordingly. No problem here, very simple to implement. What I want to do now is remove the enum, and make it a class. (it is my understanding that have type-defined controls inside a class can lead to some weirdness). So I figure I create a mode class (and child classes corresponding to the different modes my instrument can be in), and then at run-time change this object. Each of these mode child classes would implement a Read function, and they would know exactly how many bytes to read for their specific mode. This seems a bit weird as I would be implementing the Read function in the Mode class which does not feel like the right place to put it. Alternatively I can implement a BytesToRead function in each of the Mode classes and then also a Parse method. Does this sound sensible? Is this going to be complicated by the fact that my actual class holding the mode object is an abstract class?

If you truly want to do this from LabVIEW do yourself a favour and get a serial sniffer and capture a download that has been successfully done via the AVR tools. Doing this kind of thing from first principles is, in my experience, quite a bit of frustration finally followed by extreme satisfaction when it all works nicely. Good luck if you are trying to write the bootloader, expect much suffering!

Thanks for the help everybody. I think I am going to take a little bit of time to digest this all.

That should work, it certainly works fine on my PC. It is the technique used by the nifty Show VI In Folder quick-drop plugin http://decibel.ni.com/content/docs/DOC-22461

I am getting there... slowly... sometimes I think my understanding of something is like a really strong permanent magnet that resists all attempts to change it, but once it is finally done it is done for good . At the moment my understanding is resisting change! Can anybody furnish me with a simple example of when Preserve Run-Time Class is recommended/necessary?

Thanks for the explanation Shane; I am slowly getting the picture. Am I right in thinking that Preserve Run-Time Class only really makes sense when there is a sub-VI involved? I know the help does state this in the very first line, but I must have glossed over this.

Just to briefly revive an old thread, I still do not really fully understand the difference between To More Specific Class and Preserve Run-Time Class can somebody check my understanding here for this particular scenario I have a class hierarchy, say parent class A and child classes B and C. Actual class is only determined at run-time, so my wire is of class A Under certain conditions I wish to run a method that is only implemented in class B so I should use To More Specific Class, rather than preserve run-time class Is this correct? This is pretty much how I have always done it in the past, I thought it would be worth re-visiting incase I am not quite using things correctly.

I build to a temporary directory (like c:\t) if I run into these kind of problems. It is a pain...

Jack and Michael, if you are "listening", I think this kind of stuff would make a great topic for VI Shots live.

I also see the strange chars, but mine are replaced by a ? glyph/character in chrome

Interesting, but I am not sure how these are better than using the Get/Set Variant Attribute prims. Have you benchmarked these compared to the prims? I suspect the difference will be very little difference, but am curious anyway... Edit: your VI does not actually do very much, did you perhaps forget to save default values on the variants or am I missing the point completely? I tried to add a variant attribute using the standard LV prim, and then read it back using the library call, but I could not get this to work ("an exception occurred in the external code").

Simple example attached (LV2013). The callback VI remains reserved after the main VI has run. Any ideas what I am doing wrong here? Note: I have just tried to run the "Passing Data to a .NET Event Callback" shipping example and the same behaviour exists (i.e. works fine in LV2012, but the callback remains reserved in LV2013). Test5 Callback.vi Test5 Callback.vi

Hi All, I am dusting off some old code I use to get a Windows Notify Icon running. This code was originally developed in LV2009 I think, but recently used in a project in LV2012 with no issues. For convenience I have wrapped up the .net NotifyIcon API in several LabVIEW classes. My test code works fine, but I have some strangeness with the event callback VIs (these are invoked whenever you interact with the notify icon). Specifically, when I run the code my callback seems to change context from my project to something called <W>, and is in a reserved type state as shown in the second picture. When I stop my main VI this VI does not come back out of this state. This causes my classes to be locked in the project (reason for locking is they are apparently reserved for another application instance, which I can only presume is because of the reserved callback VI). In LV2012 when I run my main VI the callback VI does not get reserved like this, and when the main VI finishes everything goes back to normal. Any ideas here? What is the <W> context and why is it on localhost rather than My Computer?

Yair, your link for Featherweight seems to be broken (missing the colon after http), try this.

I love trying to understand lordexod's posts, they are like doing a cryptic crossword

Hi all, I am a bit embarrassed to say in my situation there is no bug in LabVIEW, this is clearly a case of PEBKAC. Sorry NI! The root of my problem was I created a sub-class from one of my main objects, and (for reasons I can not think of now other than it was very hot the other day) in the private data of the sub-class I added a data member object that already existed in the parent (same class, same name etc). Then when I was probing around I did not notice that I was looking in the wrong place in the cluster (basically I saw what I wanted to see...). I think I may still have the problem of a class not updating properly in a different part of my code, but I had already "fixed" that by re-arranging the class data slightly and the problem went away. Panic over for now. Thanks again Darin and Jack, I will certainly remember this thread for next time I get this problem.

Jack, I don't know how long it took you to type that out at the next CLA summit. Thank you. I will try those things, some I have done (or already do as best practice working procedure). The codebase is quite large, 140 classes, approx 4500 VIs excluding vi.lib, so this could all end messily

Yeah, did try an Always Copy, but it did not help. I will try putting them in other places like you suggest.

All my dislikes are purely aesthetic, I think they look quite cartoony and waste way too much space. I pretty much use System controls exlusively for GUI front panels.

Hi all, I have had some really weird behaviour in my app over the last few days. The problem seems to be related to several others mentioned on LAVA where the contents of a class are not being correctly updated via a bundle. My current problem goes something like this: I have a sub-VI where I update some members of a class, and then the class is used downstream in the calling VI. If I probe the class wire directly before the exit indicator in the sub-VI, the contents are correct, but if I probe it downstream (immediately after returning from the sub-VI) one of the member elements is not set correctly! This morning I had another issue with a similar class apparently not updating after a bundle operation, even though probing showed all the values to be correct. This issue is very very annoying as I now really do use classes quite a bit in my code, and this is such a terrible problem to debug as you can no longer believe what the probes are telling you. Any ideas? Next step for me is a mass compile or to clean out the object cache. Edit: cleaning object cache did not help.

Me! I pretty much use strict for everything except GUI typedefs/controls that I want to customise a little bit. I suppose I use strict over normal typedef just out of habit. What silver controls? I don't see any silver controls on the pallette. I think you are mistaken, silver controls do not exist. System, Modern and Classic are all I can see on mine

Well, hopefully my cRIOs are stable now. I have nine of them running a long term test, with uptimes of about 60 days so far, so hopefully my issues are resolved. Next time I will definitely go the time sync route.