ShaunR

Why don't you just send me your code and I'll mod it.

Well. For controls ........none. Since I wouldn't use any of them. I'd use something like this: I can't remember off-hand how to get th BD reference (cannot seem to find it in the list). I'll have to dig into my old code for a refresher example (is it only available if scripting is installed and activated?).

You need to first install lapdog_lib_message_library-0.7.0.1.vip which has that class

Maybe worth exploring. But if you edit the case name after insertion (say insert a space then delete it). The broken arrow disappears.

It was a trivial point but I think it improves readability immensely. And (probably in the minority again....but) I will choose readability over elegance if performance is not impacted.. But I want it to fail. Because it means I have given due consideration to an unexpected behaviour and therefore is a part of the designed behaviour. In the absence of similar behaviour in other classes, I almost view this as a NI implementation oversight (and therefore all methods more of a bug fix) rather than a design pattern to be used generically for accessing objects. In most cases (where things are as they should be) it's a performance hit since the probability is that you will be trying invalid cases before stumbling onto the correct one is high. If all t saves is 1 case. Then I see no reason to switch from an accepted, proven method to a shiny new method that may have performance hits and is (slightly) less readable. You'll have to give me more than that (What are the benchmarks comparisons like out of interest? If you don't have time, post an everyday example and I''ll do them) All are as I'd expect EXCEPT graphs. Excused! Indeed I was. (It was late/early is my excuse and I'm sticking to it ) But my point (perhaps explained better after the sleep) was that I didn't need to create a case for EVERY class and subclass. And my memory from over 11 months ago, was that I didn't have t deal with subclasses. It turns out that was because of the consistency of implementation of the property node (In fact to handle any control in PassaMak only required 4 cases. So that's only 1 more than you have above.....for all of 'em).. Well. Get banging on the floor, tool up your Pikachu with an Uzi and tell them to sort the Graph class out Well I didn't miss it. And I didn't miss digital graphs either But. The string based system doesn't "fail". If you hadn't thought about the waveform graph or waveform chart, yours would "fail" too. I'm looking at the graph example and all I can see is that you are replacing a nested case structure with an iteratively nested case structure. Perhaps I need a different perspective?. Hmmm. Now I see no difference between the "string" based system and this one apart from the "string" one will always do it first time, every-time (if it can) but this method has to try a few different ones before either it hits one that works or it runs out of options. Same number of cases because there is no common denominator and each operation has different properties and methods. It seems to me that the graph example is indeed a one-off scenario where you save 1 case. How can you handle cases not originally thought of? If that were possible, you wouldn't have to add the extra cases because it can handle stuff you don't think about Moreover. If you haven't thought about them,how do you know it will handle them correctly? (Wavey lines, Soft fade.....) Many moons ago, in a galaxy far, far away. We used to use a similar approach for instrument identification. The SCPI spec was fluid and manufacturers all had their own way of identifying their device (to some extent that's still true today).. So we would have a list of all the ident commands for all the instruments we supported and try each one in turn until either we ran out or found one that worked Sales called it "Auto-detection". We called it the BFI method (Brute Force and Ignorance) . It was slow and cumbersome and with hindsight, didn't obtain the holy grail of "future proofing" that many believed. It also had a really annoying habit that if a customer happened to stick on an unsupported device that had the same ident command. it'd make them think it was compatible but fall over because the rest of the command set wasn't the same. Eventually, we decided to make it a maintenance issue and that if they swapped out a device for a different one they'd just select it from a drop down list, It was faster, cleaner, easier to maintain and also meant that "if it 'aint on the list, it 'aint getting in". Does this have anything to do with The "Any Cast Design Pattern"? Probably not. But but I'm having flashbacks

OK. Added:D Indeed. The really astounding (is that the right word?) aspect of it is that NI REALLY DO listen to thier customers and the changes are the evidence.

Oh, I don't know. I think some of the changes are really useful (like clusters as control-type icons). But they all seem to be cosmetic changes. So whilst I like the idea of a cleaner diagram, I would (as I think you are suggesting) prefer to see the more meaty ones implemented that enhance the program rather than the prettiness of the diagram. Or maybe that's a sign in itself. That we are having to spend too much time making diagrams "look" good instead of making functional code. But I think Aristos' suggestion is an excellent one (and long overdue). I use it a lot and it would save be bags of time. I'm in the same boat as jgcode so I'll have to create 3 more accounts and hire a medium

Having slept on it (after all wise words from NI are never to be taken lightly). I thought I'd better to refresh my memory. Unfortunately I seem to have remembered correctly (what? No crying emoticon?) as this works as I would expect However, Plot color isn't available, yet it is still common to all plots. Which brings me back to the summation that you have really highlighted a problem of inconsistency of the property node for waveform types since this also works. So. You don't have to create a case for every class and subclass. Only the parent (if at all). Apart from some properties of waveforms (there maybe others but waveforms are the only one I've come across).

Naaaah. I think they should supply them

Really? Its easier to read 0,1,2,3... than WaveFormGraph, WaveformChart, XYGraph... ? I find nested case structures abhorrent. I must admit I didn't even consider the nested error example a solution Even a case structure with many cases causes me to look for an for an alternative. Its the same argument as Sequence Structures. If the case number is small (<6), I'd much rather use a select so its all out in the open. For more then I will try for strings unless its numerical in nature in which case I will do the same as you. ummmm. "So"? Thought I did You mean the difference is that instead typing in the class name you wanted to handle you, would just "Copy Case" and change the cast constant instead? Not really. Because unlike graphs the a property node accepts all the numeric classes for the common properties. Certainly waveformchart,waveformgraph and xygraph don't have child classes. Neither do boolean, cluster etc Numeric types are consistent (whether they be a U16, DBL, slider, knob,gauge or whatever) since all the common properties can be wired to the same property node. The graphs, however (I think) are the exception and it is only because the property node doesn't allow it (which it should) means that you have to handle them differently. I found that out when writing PassaMak.

Hmmm. I don't really see he difference between your using the class name "problem" example and using an iterative apart from the class name has a descriptive case name and the iterative "trial and error" just has 0,1,2 etc. You still have to have a case to handle the particular type to do the correct cast but with the iterative approach you have to try all the previous ones first before deciding its not supported. With the class name its either supported or not. Is there another benefit I'm missing?

Don't forget all the documentation

Add this line to the labview.ini file in your labview folder: disableMenuEffects=True Or if an entry already exists; change it to True. Then restart labview

Glad to hear it. Congrats. Always easier when someone is sitting in front of you (that knows the exam answers ) I noticed wired up the duty cycle to the simulator

Well. I would tentatively suggest the others are reinterpretation (dbl to uint64 is reinterpreting the bits to form an equivalent value). Why does it need a buffer? Don't know Implementation specifics that I'm glad I don't have to worry about. But I would guess a temporary buffer may be required as an intermediate step in the conversion process since the new type cannot be represented by a union (c terminology) of the memory locations unlike a transformation.. And before you ask I still have no idea no idea what 4.x data is either other than a vague recollection that it was something to do with a change in internal representation between LV versions some time ago.. where's Rolf when ya need him

I would classify this as a transformation.

Probably posting on here Glad there was something useful.

Well, you were the OP. Just remember. "There's no I in team". But there is a "ME" and no U

Name: Windows API Submitter: ShaunR Submitted: 09 Sep 2010 File Updated: 03 Jan 2011 Category: General LabVIEW Version: 2009 License Type: Other (included with download) Windows API Utilities. An eclectic set of wrapper VIs around some windows API functions. I wrote these many years ago (1998? wow!) but have used them to some extent in virtually all my windows programs. I've included all the original functions (accidentally re-compiled under LV 9.0) and just wrapped them up in a project and added the LAVA required stuff so your getting them "warts 'n all". Many functions have been superseded by LabView functions and I expect many people already have their own. But there are still some gems I couldn't do without and maybe someone will find them useful. Installation: Unzip to a directory of your choice. Required Packages: Labview 9.0 or greater Windows XP or greater (may work on earlier versions) Known Issues. None. Versioning: Current version 1.0. Contact: PM ShaunR on lavag.org (http://www.lavag.org) Click here to download this file

I wonder why NI pulled the LabView Player? That would have solved Cats code review problems at least.

Fantastic. Very talented guy. But a very expensive way to record a song

Once again in the minority. Its good to be back Afraid? Hardly (that's almost funny ). Can't argue with that I think you mean most people that program in Linux or Unix. When I write text programs in windows and I need a quick "tool" I write something in LabView On the rare occasions I am required to do something in Linux, I probaly still wouldn't use those utilities for task automation unless there was no other way. On windows the analogy would be using the cmd.exe do tasks which I think (personally) is a bit icky, But I recognise it is a standard method on Linux/Unix.. Now pearl I would use to write a script to automate a task after all it is a "scripting" language (if only i could understand my own code 3 weeks later ). I find the project manager is sufficient. Although perhaps you could elaborate? Hmmm. One of the areas I definitely wouldn't use scripting is data population. I would prefer a run-time solution so that I only have to replace the document not re-hash/re-compile my code every time there is a spec change.. We have a similar implementation where the design engineers create a spec, which I deploy as part of the distribution and is parsed by the software. The document comes under document control and i've offloaded the responsibility of keeping it up to date onto a technician. As for system documentation. Shouldn't this be generated from the requirements spec? Maybe so. But my time and budget aren't. There has to be a very strong reason for doing something that is not easily equatable to tangible benefit (damned accountants ). Should I spend 2 days writing a script that can only be used to make my life as a programmer easier? Or should I spend that time to write a piece of code, that I can deposit on the clients site,and means I save travelling expenses, board/logging and corporate face?. If it was deployable I could do both Tool developers don't have this dilemma since they can monetise scripting directly. Perhaps we should start another thread since we are now way off topic. Or maybe we're getting to the point where there we just admit there are 2 camps (ok one of them isn't really a camp, more of a sole resident )

What crossrulz. means (I think) is that events are more efficient for user selection than a state machine. Assuming that the goal is to make a selection based on user input. Although it is not a state machine in the classical sense, since the the next state is not dictated by the previous one. Note that I have changed the mechanical action of the booleans too.

I'm sure (as we've seen) people that create product will use scripting (the same way that a programmer will use more memory if more is available). But as it cannot be deployed it remains a feature that I (not being a tool developer) could have, quite happily, lived without . Tool developers, however, love it to death because it is the only way they can exist. It has opened up a 3rd party business where previously there was none and, previously, non-NI add-ons and tools were petty much free (this being a cultural change rather than a technological one) .I just find it really hard to get excited about scripting:P I can't comment on your LV 2010 (or indeed web-services) only to say that in LV2009 an executable, DLL, and .NETs build number is included and indexable and maybe the lack of one on a web service is an oversight that should have been reported. But you didn't need scripting to do that,. The useful feature (and I do think this is really useful AND in benefits all of us) is the additionof the pre and post vi's without wihich, even scripting couldn't help and you would have had to use your previous method (which was probably a vi you run after the build, manually)