crelf

I couldn't agree more - sure, reading books is going to to nothing but help you improve your skills, but if your aim is to simply pass the exam, review review review the courses.

Are the VIs in the project, or is it just a convienient way to access your vip files? Totally! I have a small app that is a hardware explorer that loads hardware classes dynamically - it's great to have the lvproj files for all those classes in the main app's lvproj for quick access.

Bope - only list the VIs in the project that you need to get access to or call dynamically and need to add manually to the build definitions - all the other ones will be listed under the dependancies section (if they're being used). For example, I have a few projects with 100s of VIs, and I only have 5 or 6 VIs in the top level project. You can also put other files in there two (I usually have a link to the application's ini file, if it has one, as well as documentation, etc). The project isn't just for building - it's for managing the project. Sure, there may be issues (you mentioned that you're stuck with an "improvement" that you don't like) - if it's really in your way the let us know about it - one of us may have found a work-around, or maybe you're not using it in the way it was intended. That said, if it's a real issue, let NI know and maybe they'll fix it...

It's in the admin console. I assume that your real question is if we have the latest version installed, to which the answer is "yes".

Yes Yair, you are

V I Engineering has a bunch of out-of-the-box operator interfaces (including 1-up and multi-up verbose and laconic OIs) - I don't think we've ever sold them as a separate product (they usually come bundled as part of our ATES product, or as part of a turn-key solution), but if anyone's interested please give me a yell. The OIs also come with a LabVIEW/TestStand Extension reuse package with a bunch of VIs that encapsulate the TestStand API if you want to modify the OIs or create your own.

Have you since tried using peekheap to see what the LinkObj error was referring to (obviously, this would only work for anything that existed at last successful save)?

I'm not so sure what you're trying to do here - you delete the file if it's there (have you though of using the OpenG "File Exists?" before trying to delete it?), then you write some text into the file, then you try to open it using the Config Open. Yeah, I'd say there's a fludhing issue. Also, unless the initial text is formatted correctly, it's not going to be interpreted properly by subsequent Config File Reads...

You can start by uploading some code for us to look at Also, is it GOOP or is it LVOOP (or a different flavor of OOP)? GOOP specifically refers to classes/methods written using the Endevo toolkit, LV-OOP is the built-in LabVIEW OO framework. It's important for us to know what we're dealing with to help you.

That's a good plan, but there may be exceptions (eg: working on a system at 3am and you need to fix a small bug). That said, if that was the case, I'd do it, but then follow up with the "owner" as soon as practical. Totally true - this should be the default setting IMHO. If you agree with me, vote it up over here!

Exactly. IMHO LabVIEW is having a problem during it's build, not me. LabVIEW created the issue by trying to do stuff out of bounds, not me. Sure, I can make changes to my code to work around the problem, but that's exactly what that is: a workaround, not a solution. I beleive this is a bug. Anyone from NI care to comment?

You're welcome

Hey hey your two - let's keep it civil. Saverio: I think Yair was being sarcastic.

I understand why this is happening (LabVIEW is struggling with the filename length limitof temporary files during it's build) - but I still think that has nothing to do with me - shouldn't it just build somewhere further toward the root (in, say, a temporary location? These files are, afterall, temporary).

Cross posted here. So I just tried a build in 2009 and got a curious error The files that it's complaining about are going to be inside the exe, so why is it an issue? Surely the filename length check should stop at "C:\Projects\VI Engineering\Software Products\1-09-xxxxx - VI Engineering - Hardware Explorer\Engineering\5 - Release\Executable\VIE Hardware Explorer\VIE Hardware Explorer.exe", which is well under the Windows filename length limit, right? Even curiouser - changing the "Advanced" build option "Use LabVIEW 8.x file layout" seems to fix the issue...

No experience with Git, but I'd use SVN with locking.

Hey man - my app's only repsonsibility is to report issues it sees Mine too - although that was a looong time ago. I've done heaps of dynamic plug-in sutff before, just never LVOOP. The posibilities are endless...

I think that's logical

Follow-up: I did some testing over the weekend and this works great! I now have a sleak application that can remain a closed product, and then when each project needs to use it they can "install" LVOOP plugins (I have several built up) and create their own that are project specific. This makes me happy.

Thanks François.

Beawdy - thanks mate. Thanks for that vugie - I'd forgotten about those. Hmmm - looks like the LAVA 1.0 crash lost the Scripting Workbench files - if anyone's got them, please post them here Scripting Workbench.

We haven't been able to recover the files for this thread - does anyone have them that they'd like share? Maybe this should go into the code repository...

Hey Phillip - where is the "Get Shell Icon of File" method? If it's not exposed anymore (I'm using scripting on 8.6), can you please upload a VI with the method on the block diagram?

...and nor should it - but it's good to get the confirmation - thanks Stephen!

Ohhhhhhhhhhh.... Of course that totally makes sense, although it's not quite what I'd expected