crelf

I second this question. I know it's not the original intent of the thread, but I think it might make for interesting reading...

Mwwwuuuuhahahaha!

How about this: select two items that are the same (eg: 2 strings), look at the list - implement those. Repeat for all node types OK - I'd figured as much. Well, you might not think of it as "done", but your new feature list suggests otherwise

Yeah, sorry - I should have made that it was just one example. There's several difference between many items, and even shared stuff between less-like items. But there's still not as much as I'd expected for like (and, well, same) items... That makes is sound like you're implementing each and every item one by one? Wouldn't it make sense to just compare the items, and, if they're the same, allowed everything *but* restricted items? I guess it could be a similar impact, but my gut is telling me that the latter would be more efficient. Or are you saying the current architecture of the LabVIEW source code won't lend itself to that without a major re-write?

Actually, it was new in 2012 - see Productivity Improvements > Right-click menu option for multiple selected items. I was really excited about it when I heard this was coming (and it is neat on some things - try selecting multiple FP controls, right click and create references - BAM! I'm not sure what you mean by "visible labels", but there was a bunch of improvements in 2012, with some of them being in the IDE: http://www.ni.com/labview/whatsnew/ Ugh - I just realised that link would be overwritten with other stuff when 2013 comes out For perpetuity, here's a copied list from that link:

Maybe I'm not understanding it right (it certainly wouldn't be the first time), but the new right-click like-items feature seems kind-of bogus to me. Here's what I'd expect: say I put 2 string constants on a block diagram. If I right click on one of them I get a bunch of options in the right-click menu (like 20 of them, with submenus). Now if I select both of them and right click, all I get is 2 options. Now I'm not assuming I should get *all* of the options, but only 2? Yes, I know that the Properties option gives me access to a lot of the stuff that I'm after, and that's what I'm forced to do right now, but that's just not intuative - it changes my work flow in a negative (and much slower) way. Why can't those options be determined at right click time?

Right - we rarely use a customer's requirements document - they usually give us a "specfication" that we write traceable requirements to, which we then have them argee to (so we're all on the same page) - and it's that requirements document that we test to. PS: I'm still convinced we're talking about different things, but that horse is already dead and starting to smell.

Nope, we're comparing products to services - apples and oranges I like to think that the Agile process (not that I've ever seen anyone implement a true Agile process FWIW, but there are plenty of people who will tell you that they do ) and a vee model with added alpha/beta stages tracks relatively closely. Agreed - I can't argue with that Unfrotunately (and I"m not talking from any direct experience here) market forces can make or break companies in this situation, so there can be a business gamble here. I work in regulated industries with well structured processes, and customers who respect that, so there's not a lot of room for such shennanigans, but that doesn't mean it doesn't fit other fast turn around markets (like iPhone app stores, or, since you're an Android guy (as am I), Goolge Play. Sure - and I'd prefer an app that was written by a script kiddy who went through a formal alpha and beta over one who didn't. But again, that's a different market than I'm used to professionally - we have customers who pay for custom solutions, which means we sell services, not products. That said, some of those services come with products inside them. If we're only talking about services, then I'm more inclined (but not totally) to agree with you. If we're talking about products, then I'm all for alphas and betas. That's what I meant about models fitting inside each other (as a side note, sorry to harp on this, but if someone says they use the Agile model, they might use portions of it at some level in their process, but probably use a vee above it, and maybe an iterative below it - see what I'm getting at?) Rather than comparing a software app to a skyscraper, let's try something a little more apt: a software app to, say, a power supply. If I'm designing a power supply, I'd like to think I'd make a prototype before final release that I might get some of my key customers (whether they be internal and/or external) to play with and give me feedback on. I think that probably makes sense. And I think "alpha" and "beta" can be analogous to "prototype" in the product world. I should hope not - I don't think you've ever seen any of them - in alpha, beta or otherwise I agree that there's a trending mentality toward treating beta testers as free bug finders, and that, with the availablity of easier release platforms (think AppStore and Play), the temptation to release software that clearly isn't ready but not marked as such for the purposes of getting free bug testing, is becoming rife. In that, I agree with you wholeheartedly. BUT I won't accept that that means all alpha and beta testing stages of products is immoral. Both sides need to be fully aware of the consequences, and choose to opt in to such programmes. I'm warning that (again, we're talking about products here, not services) ignoring early drop techniques can lead to software that meets the requirements, but leads to unhappy customers. We have several customers who jump at the chance to pay for an ECO to change requirements while we're developming (that's a whole other discussion), but it's only during prototype demos/betas that they have the opportunity to think those changes up. And then it's on them if they want to pay for said changes. Sorry, I should have been more clear: I was referring to services vs products. Then I guess we philosophically disagree. I prefer to work closely with the customer during the project to make sure everything aligns to thier expectations (if possible, of course ) though all stages of a project's execution. As I alluded above, I prefer not to drop something in their lap that meets all of their initially defined requirements, but doesn't fit thier needs. And we circle around to the start: as long as both parties understand and agree to the terms of a alpha or beta testing programme, I see them as very powerful tools. I see no problem with a "prototype" kettle I'm not saying it's easy, but I know it's not unobtainable. Well, maybe it is for some customers

Ok, so we were trying to compare apples to oranges. 'nuff said That's not entirely true, but it's not entirely unture either. I think that some new softwares are expected to be buggy, possibly because they haven't gone through alphas or betas, and/or the market has forced an early release on a less-than-mature product. It's also one thing that makes software so awesome - changes (whether they're bug fixes or feature additions) can usually be made with a much faster turn around than hardware. That's not always the case, but if we're talking about product platforms here (which we're not ), then it's a great way to go- especially if you have more than one customer: you can weight feedback on feature requests and make strategic business decisions based on them, which can be super efficient during alpha and beta cycles, as opposed to waiting until full releases. Again, apples and oranges. Image an iPhone user who wants an app that allows them to read their email: if you said to them "I've got an app that does 98% of what you want, but 1% of the time it'll take an extra 30 seconds to download attachments, so I'm not going to release it for another 3 years until it's perfect". The iPhone user goes and downloads another app. Also, skyscrapers aren't ever perfect - they're good enough. And I'm pretty sure building owners are given tours of their buildings before they're completed As for the type of systems you build, I agree with you - and we make similar-sounding systems too. Such tings are decided at requirements gathering and design phases, and are usually locked down early. That said, we also have a suite of software products we use on these programmes, so it's a balance. In summary, as Jeff Plotzke said during his 2010 NIWeek session: "Models can, and should, fit inside other models." That's an admirable goal, and works extrememly well in some industries. I sometimes find it useful to get feedback from end users during development, because, in the end, we want compliant systems, on time, on budget, that make our clients happy. That last item can be tricky if the first time they see it is the last time they see you Anyway, it depends onthe idustry, technology , and client. All I'm trying to say is that deriding alpha and beta programmes completely doesn't make sense to me - every tool has a place.

I agree that you can't dump it in someone's lap totally unfinished, but I couldn't imagine dumping it my customer's laps without them having an opportunity to tool around with it before its officially released. What you're suggesting might work for systems that have few and very well defined features, but once you scale up even just a little, the possibilities of what your customers might do with it grow quickly. Look at LabVIEW: I'm glad they have betas, because, without infinite resources or infinitie time, they can't possibly imagine to test all of the combinations of awesome things we're going to try to make it do. Maybe we're comparing apples to oranges, or I'm missing your point. It's a thread hijack anyway, so I'm going to split to t a separate thread.

...and the opportunity for your potential customers to help shape the direction of your product by pushing it through use cases you hadn't thought of

Maybe that's part of the stuff that Wirebird Labs is working on? I'd keep an eye on them...

Yes! I was skeptical when we ordered these, but they work great - and have LabVIEW drivers (well, wrapped DLLs ).

Revoked.

Is your exe builder/installer pointing at a custom ini that has this line in it?

1.27. PS: The cake is a lie.