crelf

I use the plug-in architecture with executables and it works as expected. It is important that the whole hierachy of the VI be accessible and that the executable installer has correctly... I usually do that by Save with option>Application distribution.

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.

Hmm... too bad that CLA courses do not teach how to solve problem.

Very droll Irene (or, at least, I think you're being droll - you forgot to add a smiley to the end of that sentance )

I guess (I am not NI, so guessing) you got error message because your dynamic called vis are broken because couldn't find some subvis. LabVIEW runtime engine does not know where to search for subvis, unlike development environment.

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!

It seemed like you were ok if you had the LV development environment on your computer, but if not it became a real hassle.

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?

...but <VI list> are missing.

Oops - sorry - they should be there now.

Well I'll take the beer...

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...

I see it as a negative by NI overall, and really a MS envy type of play some manager probably got a bonus for.

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

There's an old Greek saying that my dad always said to me. "Once you get on the dance floor, you gotta dance"

Go for it Michael!

...I was hoping to get a few more of the truly freelance styled alliance members posting here. Perhaps they have, not sure, but the ones I know from work over years are now no longer seen on alliance webpage resource.

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 probably understand more about your perspective than you give me credit.

I don't go for the intellectual pride aspect of it though.

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...

If you were your own employer instead of an employee I think you would be saying the same thing as me.

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...

Wow, I had a boss like that once. I am glad I don't work for him!

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.

.

I am committed because I stay with NI material from job to job, company to company, then my own company.

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.

...untill the world does away with the obsurd notion that people can be evaluated using tests, certifications are an evil we will have to "confront or die".

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...

The last time I checked, one of the worlds top LV developers who's initials are RK is not a CLA.

If my boss came to me with his resume and someone with a resume identicle to mine, I would advise him to interview RK.

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

NI has always been a supporter of the do-er and not the talker.

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.

...is all type of digital camera can do the same thing like webcam (as long the digital camera has the usb)?

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

...I decided to build my own activex version of the MFC CListCtrl with integrated sort functions...

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.

If you want to talk about genozide, race discrimination and despotisme, then I do not see why you couldn't use Hitler or Nazi in that context but you shouldn't try to use them out of context for something else.

Very well put Rolf

Need to collect a picture from a webcam, and to save it do disk.

Check out NI-IMAQ for USB Cameras.

That cannot be anything but wrong, because if history cannot be told, there is nothing to be learned from the mistakes that were made.

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:

As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one.

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'd share more, but I forgot what it was Jim Kring said about how to keep you-know-who from copyrighting my ideas.

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:

From the OpenG website:

OpenG is an organized community committed to the development and use of open source LabVIEW tools, applications, frameworks, and documentation. Through participation and continuous improvement, we empower ourselves and others within our community while creating new opportunities for LabVIEW developers.

Is there a really easy way to get a picture of the block diagram from within labview? something easier than printing to HTML, that is...

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.

I'm perfectly willing to take Knuth's word on algorithm correctness!

Indeed!

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

I would think that this is equivalent to the "cluster shuffle", but I don't really want to try and prove it...

: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!"

...shouldn't we begin discussing beer? :thumbup:

Well done - you've invoked Kring's Law - you win!

I'll get data with no discernable pattern for sure...

Depends on you definition of "descernable"

However, since time is bidirectional (or is it quasi-directional? ), let's pretend I didn't do that yet.

Didn't do what? I didn't see anything