Val Brown

Now again I may be missing it but all of these notes are confirming at least one aspect of what I'm saying: viz, all the different versions means there really isn't any good continuity to using OOP within LV. By-ref versions are recommended if you're not only programming in LV. The native LV version is recommended if you are only using LV except if...etc, etc. It seems to me that all of this inconsistency really defeats one of the core rationales for OOP within LV.

QUOTE (Ton @ Dec 17 2008, 09:21 PM) So, in a sense, it's like using componentized code from MS, eg COM object and ActiveX. You can use them but not edit them. OK fair enough but what really then is the difference?

In another thread jdunham posted: "Well at risk of both a thread hijack and a mild flame war, I suggest you take another look at LabVIEW's built-in OOP (usually called LabVOOP). It's pure dataflow. You could also call it clusters on steroids. As I see it, it adds two features. One is to hide the implementation (i.e. the messy details) of each component of your code from the others. This makes it more likely to avoid bugs, because without this, it's very easy to change a subvi or a typedef and have it break some other code which you were not paying attention to at that time. The other benefit is dynamic dispatch. If you've ever passed data in a variant (or a binary string, or a cluster with optional fields), and then accompanied that with an enum which tells receiving code how to unpack the variant, then you are better off using LabVOOP/Dynamic Dispatch because it does the same thing with less code and less chance for error." So I thought to start another thread here FWIW. Here's the problem with OOP and LV: which version does one use? Now one could say that, having to ask that question belies the wealth of options and that's a good thing but, on the other hand, it actually is a profound problem IMO, esp in terms of code reuse. Differing approaches (by ref vs by value, private vendor vs native LV, etc) all lead to code that can not be reused easily across differing implementations (unless I'm wrong on that) and yet isn't that supposed to be one of the many values of OOP? This really is just a personal opinion of a long time LV user and is NOT meant to incite a flame war, mild or otherwise.

QUOTE (Karl Rony @ Dec 17 2008, 07:18 AM) I can only reply from my perspective, which I suspect will be quite a bit different from the majority of responses you will hear from other LAVA members. If it were me, I would stay away from both OOP and X-Controls. I'm not saying that because I think OOP and/or X-Controls are "bad" in some way. I'm sure they're wonderful and very useful, esp in tandem. It's just that my experience has been with traditional LV dataflow and that's what I feel most comfortable with at this point. I've heard a lot about OOP and "getting the classes right" and how easy that makes the rest -- and truthfully, it probably does. But I've also not seen the value for me in learning OOP and translating over everything that I've done over the last 10 years of LV programming. Then again, I don't need to create reuseable controls to distribute for use by other programmers on a team. I'm a one man operation who sub-contracts at times for others to implement small sections of my code. I've long been concerned that the push for OOP etc will become an aspect of LV losing its central orientation and commitment to dataflow as it has been done since the beginning of LV. I hope that isn't lost but, then again, I also hoped that complete crossover of code between Mac, Windows, etc wouldn't be lost either. Perhaps that will come back but until then, I'm a bit disheartened by the continued push to OOP and Windows at the expense of the traditional dataflow and cross platform ideal of LV.

QUOTE (orko @ Dec 9 2008, 12:48 PM) I think it's a rendition of "Moon over Miami", fortunately there's a bit of a cover blocking the moon... Let's see, created the world in 7 days, made in video in less than 7 mins, probably has used that weapon, about 7 mins in total. Yep pretty godlike.

Darren, I like your idea and think some version of it should be included as the default or at least as a second menu-based option: eg Relink This SubVI (which is current behavior) and another Relink ALL Instances. If adding an option like that is problematic then the default should be exactly as your originally proposed it. For most LV users, most of the time, it will greatly ease an otherwise burdensome task. And those who are more advanced are much more likely to do the right thing from the beginning to not create problematic relinking and, if they do somehow do that, they would most likely be in a very good position to revert to a prior version (SCC) or know where to start looking for problems (inappropriate linkages due to the saved change.).

QUOTE (Aristos Queue @ Dec 4 2008, 05:06 PM) FWIW I'd definitely be interested in it.

QUOTE (orko @ Dec 2 2008, 07:53 AM) Yes, AFAIK that's the behavior so I always save the BDs on mon2 and they start up on mon2 when I next open up that project -- provided, of course, that both monitors are connected. I also use a different screen resolution on my external monitor. Since I use a laptop and have traveled a fair bit, I'm stuck with a 15" native TFT display on the laptop. My external monitor is 24" and I use its maximum resolution to maximize my screen "real estate". My primary system uses XP under Fusion on a MacBook Pro but I also have a Vista system for development as well as other Vista systems for testing builds of deployed apps.

QUOTE (pallen @ Dec 1 2008, 09:51 AM) Yes definitely -- congrats Norm!! And congrats to NI for getting it right it getting Norm.

QUOTE (TEK3B @ Nov 27 2008, 12:38 AM) I've used it for several years now, specifically to interact with MS Access and have found it to quite robust and pretty well documented. Work through the examples as described in the manual and you should have no problem. You can use a macro in Access -- calling it from LV -- or you can simply write directly to the relevant table with LV code without creating and invoking a macro in Access.

QUOTE (Norm Kirchner @ Nov 26 2008, 03:25 PM) IDK anyone who likes any of the other candidates.

QUOTE (Omar Mussa @ Nov 21 2008, 10:09 AM) Good catch! And, yes, it would be nice if that primitive could catch "not a semaphore refnum either".

QUOTE (Jim Kring @ Nov 17 2008, 11:36 AM) No need to imagine -- just get it, read it and keep it handy for reference!

QUOTE (TobyD @ Nov 17 2008, 08:10 AM) The stop light is a recent adaptation of what the semaphore was originally: viz, a means of communicating by the relative positions of "arms", either mechanical or human. Like Morse Code each position meant a single letter. This was a means of communicating between ships in a squadron, esp during battle conditions, and it's use for those purposes dates back several hundred years. The basis of the "stop" was that the communication protocol was not duplex. Each communicator had to finish their entire message and then STOP in order to receive the reply. The "shared resource" was the communication "channel" between the vessels at sea. This means of communication had the advantage that messages could be sent more quickly than via "flags" being set. Flag-based communication was essentially what we would call today a notifier. This arrangement of communicating by the position of "arms" was taken over by the railroads where early "blocking signals" had semaphore "arms" that indicated whether a particular section of track was free to access ("go" pointing straight up) or currently in used ("do not go, but wait" horizontal across the track) or about to be used ("proceed to siding to wait there" forty-five degree angle). Many early automobile traffic control devices used arms. Over time those devices were replaced by devices using lights (the familiar red, yellow, green) both for automobile traffic but also for railroads, with the "caution" position being moved to the middle signaling position.

QUOTE (TobyD @ Nov 17 2008, 08:10 AM) If it does then it's not data but an object... ;-) There is "Not A Semaphore" for the simple reason (I assume) that one might want to test for its existence. This is similar structurally, is it not, to having "Not A Refnum..." and such.

QUOTE (BrokenArrow @ Nov 16 2008, 05:26 PM) If I understand what you're posting, you essentially created a functional mutex without using the semaphore code in LV. And FWIW -- and I'm probably wrong on this -- but I thought that the CINs were dropped for semaphores in 8.5, if not sooner.

QUOTE (crelf @ Nov 16 2008, 11:08 AM) Yes, and in "old school" lingo these uses are known as a "MUTEXx" for "MUTually EXclusive" code section. cf: http://en.wikipedia.org/wiki/Mutual_exclusion Now for a more complex definition (somewhat outside the ken of LV), the word semaphore has come to be used for multi-threaded code whereas mutex has colloquially been reserved for single-threaded code; although my sense of that history of use -- FWIW -- is that those who use semaphore for multi-threaded code just forgot the origin and historical use of mutex. cf: http://doc.trolltech.com/qq/qq11-mutex.html and all of that is probably WAY more than you wanted to hear. in re: to "Q: What's a semaphore? A: ... I Googled "sema" but couldn't find anything useful." That's true, as far as it goes, but in the US the right answer is "to haul things and keep the Teamsters from becoming either a motorcycle gang or an ABBA cover group", and that's because a semi is an 18-wheel truck.... ;-

I'm no wizard when it comes to device drivers. Thankfully I essentially stopped dealing with that kind of "low level" coding about 20 years ago. But now I've got a really intriguing situation that just doesn't make any sense. I have a device that I communicate with -- in XP -- using VISA Read/Write operations. In XP it is enumerated twice once to device.sys the second enumeration to niviusbk.sys (this changes the PID from 1104 to 1124). I've used the Wizard to create INF files, both for XP and Vista and I also have a hand coded INF from the manufacturer. All works well in XP but in Vista, things get ugly. I can install using the device_vista.inf generated by the wizard but, even though the device appears in Device Manager as "NI-VISA USB Device", neither MAX nor VISA Find Resource.VI can find it. I suspect there is some issue with the double enumeration under Vista but the curious part is that the INF supplied by the manufacturer does work under Vista (including the double enumeration) when I use their deviceUSB.sys instead of niviusbk.sys along with their C++ built EXE. How could a device show up in Device Manager, correctly enumerated (apparently!) as NI-VISA USB Device and NOT be seen by MAX of VISA Find Resource.VI? It doesn't make a lot of sense to me but, then again as I said, I gave up coding device drivers and such about 20 years ago. Any help would be appreciated. .

QUOTE (Aristos Queue @ Oct 22 2008, 04:11 PM) I was going to suggest primesource, origsource or ultsource based on how I understood what I thought you were describing but, from the diagram you gave, I'm left wondering what "A" would be considered if not a sourcender?

QUOTE (rolfk @ Oct 19 2008, 06:41 AM) Huh,"to<sic> difficult for some LabVIEW newbies..."? There are a number of examples of just that process in LabVIEW for Everyone, Internet Application in LabVIEW, as well as via internet searches. These can be downloaded and used virtually AS IS for most uses of WMP. The problem is that LV actually ignores its own property (viz Autosizing) and no one in R&D tested this out apparently before it was released. I have to say that having worked with WMP in deployed apps written in VB, C++ and LV for over 10 years now, it's just a really silly decision to have taken and one that doesn't reflect much understanding of WMP -- IMHO -- on the part of NI. IME, NI generally does a far, far better job of integrating other kinds of functionality once it makes the decision to do so. Here I think they missed a really obvious thing -- esp since it was an issue that I had already reported on, had a CAR etc back when ActiveX containers were first introduced.

QUOTE (jgcode @ Oct 19 2008, 03:34 AM) How about if you post some code showing this.

QUOTE (Michael_Aivaliotis @ Oct 18 2008, 11:34 PM) I agree. Autoscaling involves an update to the graph. Defer Panel Updates is a boolean: either updates are allowed or deferred.

QUOTE (rolfk @ Oct 19 2008, 02:00 AM) I think you have it backwards here and I'm a bit confused as to why you would defend what NI did in the past, esp when the statements that I have received about this indicate that they will provide a fix in the future. FWIW the fix will be a property specifying whether the container resizes (the current behavior) or doesn't resize (the default behavior in VB and other deployments). There was no reason specifically to NOT implement this functionality except that it hadn't been noticed. The actual MO of the behavior is that, after every pause operation followed by a subsequent Play operation, WMP reloads the default characteristics of the media being played so that it CAN resize to the default size of the media. The assumption in WMP is that the container will remain sized correctly by the calling program if the desire is to NOT have WMP itself resize back to the loaded media size. Not implementing the relevant property in a DESIGNATED FOR WMP CONTAINER simply made certain that this behavior was what occurred. In prior LV versions it made sense that the ActiveX container was NOT specifically crafted to deal with this aspect of WMP. In prior LV versions the only way to utilize WMP within LV was via a generic ActiveX container/operation. The introduction of a specific WMP container (on the pallet) really means -- at least tome -- that this issue should have been researched a little bit more. After all, if it ONLY reproduces the then current behavior of a generic ActiveX container/operation, why develop and deploy a specific to WMP container?

QUOTE (rolfk @ Oct 18 2008, 01:20 PM) Actually it is a bug in NI's container code, that's how come a "solid" container in a VB6 OCX can perform the same function.

QUOTE (ned @ Oct 13 2008, 06:42 AM) OK, I'll give that a try.