crelf

More like fraking.

That's what she... oh... nevermind.

Seems like Mike's active in the VIPM Idea Exchange - things are changing their statuses - might be an indication as to what to expect from near-future versions of VIPM... Oh, and while you're there, please vote for this and this

Ugh - that's ugly.

If you're using IMAQdx, it uses the names listed in MAX, not the registry, so this shouldn't be an issue.

Really? I've got it working just fine on my PC. I wonder: are you using NI-IMAQdx? Or something different?

You can change their names in MAX (Measurement & Automation Explorer). Go to "Devices and Interfaces", then "IMAQdx" (this might take a few seconds to show up as it scans for cameras), then your cameras should be listed - you can right click on them to rename them there.

All* of our code is ugly at times *Well, expect for mine, of course.

That's a great term for some of the code I have to deal with occasionally. I'm not surprised. I mean, LabVIEW shouldn't get into the tub-of-war that AQ descriobes above, but I'm not surprised that not closing refenences put you there. Glad to hear you've got a work around!

The LabVIEWWiki tells us that the defaultConPane key should work for new VIs. Are you saying the LabVIEW.ini file reverts after you make changes and save it?

And what's the real impact? Does it show up for a second and then close itself? Does it show up for 5 minutes? Forever?

I'm implmeneted the user manager a few times and haven't had any issues - maybe you're not closing a reference somewhere? Can you post your code? Or, at least, trim it down to as little as possible where the issue still occurs (make a little example) so we can fault find.

You know, if you programmed graphically it wouldn't hurt so much.

I guess everything makes sense if you don't think about it.

Yes, I know I'm probably the only person in the world that enables the warnings view in the Error List, but I'd like to be able to selectively ignore certain warnings. Read more here.

Right - we have a couple of projects that just use *.bin (or something more appropriate to show it's related to a project) so ppl are less inclined to accidentally find out that it's TDMS.

...or marketing...

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