crelf

I specifically don't want to include my plug-in VIs in the distribution with the executable - I want to call them by name and path only. Very droll Irene (or, at least, I think you're being droll - you forgot to add a smiley to the end of that sentance ) Hmmm - that's just crazy enough to work! My VIs do have subVIs, and I thought that the implicit internal location that is saved within the VIs that I call would be enough to load in the subVIs too... Thanks - I'll give it a shot!

Good point - my test machine has the LabVIEW dev environment on it, but I still can't get it to work - and the final install probably won't have LabVIEW on it Are you suggesting that building a VI in with a generic exe and then copying it out of it again works? you're right - that's nuts! I wonder if that means that there's some sort of flag in the VI that determines if it's been "built" or not... Anyone from NI care to chime in on this one? (pleeeeeeeeease?)

I thought this had been fixed before LabVIEW 8, but up until now I'd never had a need to check: I've got an executable that I've created, and in the spirit of modularity, I'd like to call a VI that is completely external to the exe - it wasn't included anywhere in the build. I use a strict-type call to trawl through a folder with a bunch of VIs in it until I find one with the correct connector pane (an old trick I got from the AAD course a few years ago), and then try to load it. Sure enough, I get a "Error 1003 occurred at Open VI Reference - The VI is not executable." - only VIs that I include in the build (even if they aren't referenced by any other VI) will load properly. Again, I thought I saw a way around this a while ago - can anyone please enlighten me?

Oops - sorry - they should be there now.

I would have stopped there I'm more than happy to bring up my 250th post by offering you a beer at NI-Week 2006 - add your name to the steadily growing list of people for me to shout...

Is there a Microsoft-based interpretation of Godwin's Law?

Go for it Michael! So the freelance alliance members that you used to hang out with aren't certified? I dunno, but I saw the requirement for certification a good step, otherwise anyone could just buy an alliance membership - personally I don't think that's right. I'm sure that NI didn't just go down the track they did to get more $ from their alliance members - I'm sure they understood that they'd loose some of their members, but they obviously thought that the risk was worth it to have control over the sort of people they allign with.

I think I do understand your point, so perhaps I'm not expressing myself appropriately. As for pride: certification isn't just about pride - ie: the certificate you can hang on your wall - there's a whole lot more than that in it, as I've tried to point out in my previous posts. Maybe I just wasn't clear enough...

Not at all - I used to own my own business as a system integrator, and I'm not changing my tune. When I worked for myself, my certifications (once I got them) were a great point-of-difference when bidding on competitive projects. Again, unless you've been through the certification process then I don't think you can speak with much authority on their worth. I also strongly agree with Jim's point that they are a valuable part to one's LabVIEW enlightenment - sure they're not the only path, but they're important nonetheless. Another component it work very closely with experienced and learned LabVIEW developers/architects - when I was in business for myself as a sole trader, I missed out on a whole lot of intellectual stimulation and learning - there just wasn't anyone else to push me to think outside the box. If you are working on your own, not doing any formal learning and/or not looking for certification amongst your peers, then you might not be pushing yourself enough - there's so much out there to learn, and if you rely solely on what you know yourself and don't try to expand then I can't see how you'd truly grow as a LabVIEW aficionado - you're just treading water...

I'm gonna go out on a limb and say that he's probably glad too

. Courses are designed to impart knowledge, certifications are designed demonstrate knowledge. . Is that really because you're intrinsically committed to the growth of LabVIEW, or that the earlier companies forced you to use it, or is it because you like using it? I'm with Ben: NI certifications only mean anything to people who understand what they truly represent, and as an employer, I'm looking for someone committed to LabVIEW, whereas I'd suggest that most of our clients don't care what development environment we use: they're more solution focussed. Although I agree that certifications aren't the best way to go (see my previous post), they are one method of evaluating someone's appropriateness and ability to do the job before seeing them in action. Again - I agree that certifications can mean little to those that want to hire a company to complete a solution, but when my desk is flooded with resumes from hopeful candidates, they form one part of the complete picture. It's certainly not a perfect system, but I can't afford (cost and time) to employ every candidate who drops me a resume just in case they might work out - I need to cut the list. I understand the NI certification process intimately, both its' strengths and weaknesses, so it's a very useful resource for me. If you're a one-man-shop on the other hand, I can see where it might be pretty-much useless unless your clients are also needing to decide between almost identical bidders, where only one of them is certified - then you need to wiegh up the benefits. If you never deal with clients like this then I wouldn't bother certifying, but I'd sure look into some NI courses though. Why? Reread my first sentance in this post... I'm with Ben (again!) - having never assessed one of his/her projects, I don't know that "RK" is a top developer - I know that he/she is certainly active in the wider LabVIEW community and certinaly committed to LabVIEW, so that would add weight to him/her being interviewed. Not having a certification won't disclude you from the interview process, as long as the interviewer knows what they're talking about

These days, when I'm looking for a LabVIEW or TestStand developer/architect, I need both - they need to be able to be a great wirer and a constructive thinker. Before certification came around, all the prospective staff I'd interview would come to me with a great resume, telling me that they were the most fantastic LabVIEW programmer ever invented. I would then get them to do a short supervised practical exam that would, in most cases, prove them otherwise. This is a process that I still use today, and seeing that someone is NI certified tells me two things: they are somewhat committed to the area that they were certified in, and they see value in a third party grading of their skills. I'm not saying that NI certification is the only reason that I'd hire someone, but it sure adds some weight. No disrespect intended, but unless you've gone through the levels of NI certification, you don't really know of it's value. As for learning, the NI specialised courses hold more weight with me, and I'm not sure what you're getting at saying that you've never done any NI courses - I've done several of them, and whilst some were more helpful to me that others, there were a couple in there that really helped me out (eg: the NI Advanced Application Development Course - written by V I Engineering - is an awesome course for developers wanting to make the move to architects). The problem is that it's often impossible to distinguish the talker from the doer - I've seen some amazing websites that promise the world in system integration, until I find that it's for a back-yard operator with no knowledge of proceedure, architecture or quality assurance in their projects. Sure, they might be good at programming (although often they are not), but it takes more that programming to be a truly great programmer. Certification is a method of helping me know who's comitted and those who are just blowing smoke. I know it's not the best method, and it's certainly not the only way, but it helps. Possible Perceived Conflict of Interest Notice: I'm a NI Certified LabVIEW Architect, and I now work for V I Engineering.

You can acquire more digital physical formats than just USB (CameraLink and Firewire for example), but if all you're interested in is USB, then the NI-IMAQ for USB Camera driver supports any camera with a Direct Show filter. Check out this article for more information.

Here's a couple of VIs that will help you sort a multi column listbox based on which column header the user clicks on, and resize the columns in a listbox to the width of the widest test element (essentially expanding to show all items). Download File:post-181-1146403499.vi Download File:post-181-1146403509.vi Download File:post-181-1146404066.vi Download File:post-181-1146404097.vi Download File:post-181-1146572866.vi Download File:post-181-1146572894.vi

Here's a link to a native LabVIEW VI that'll sort your multi-column listboxes.

FYI: http://www.holidayinsights.com/moreholiday...stralianday.htm Note: beer will be happily accepted in lieu of hugs...

Designing a folder structre can be a little odd due since you often can't really replicate the depth of you code That said, my folders are usually structured with modules in mind - irrespective whether you use GOOP or not, there's plenty of good reasons to keep modules separated in their own space - reuse for one: it's much easier to copy reuasble components across to new projects. I usually start with a template (not a vit, but a whole project architecture) that I've honed over the years, and there's a folder for common components (that the other components share) as well as folders for documentation (I use the VI Engineering documentation tool for that). I'm not a fan of keeping all my UI VIs in one folder - I don't really see the reason for it - I'd rather keep VIs that share more than a show front panel attribute together. I also only have my splash screen launcher, top level VI, their associated ini files and the project file in the top level folder - I have a separate folder, parallel to the top level code folder, that has all the appplication and installer builds in it.

Very well put Rolf

Check out NI-IMAQ for USB Cameras.

Actually, what you're talking about is an extension of Godwin's law and was not proposed as part of the original law at all. The law very simply states: Godwin's Law is purely observational - I don't think the practical implementation of the bastardized version was ever meant to be taken as seriously as you're making it out to be.

I wouldn't be worried about feeping anyone from copyrighting your ideas - your posts (and all their attachments) here on LAVA are covered by the Creative Commons License (see the at the bottom of the page?) so you're safe! If you'd like to go even further and increase your contribution's value to the wider LabVIEW community, check out OpenG:

Windows: click on the window that you want an image of and press Alt+PrintScrn - this'll put a screen shot of the selected window on to your clipboard and then you can paste it into your favorite image editing / saving tool.

Indeed! There's some theory that may be of interest here.

:thumbup: Very nice! Yep - this is an excellent solution, statistically equivalent to the pervious solution, faster and more memory efficient too! crelf says "Five :star:s - A must see!" Well done - you've invoked Kring's Law - you win!

Depends on you definition of "descernable" Didn't do what? I didn't see anything