crelf

Crelf, you have proven that being a good LabVIEW programmer (not a fighter ...) does not carry over to having a rational debate about the GW scare, and the related real topic of re-distribution of wealth.

Actually, if you re-read my posts in this thread without the filter that you seem to have applied to them then you'll notice that I don't come down on either side - I'm asking questions, just like you are, I'm just asking them in different ways. I'm not a socialist, democrat (in the true definition of the word), a republican (in the politicized definition of the word), a Labour, Liberal, Green, Independant, Tory or anything else for that matter (well, maybe a constitutional monachist for the moment ). In fact, I'm about as anti-political as you can get. I'm disgusted like you are that some moron fiddled the numbers for whatever reason (you'll notice that from some of my posts) and that that moron, in a way, represents the field of engineering, but I'm also not so political that I'm going to assume that means that all of the research in the field is bogus. I'm also not going to try to use emotionally-charged terminology to try to bait a response out of anyone.

If you want to apply this horrific root issue to other socialtal problems like redistribution of wealth then I gotta say that I'm way out of my depth there, so I choose not to engage (since, it seems, that any attempt at conjecture on my part is assumed to be my staunch politcal and sociatal view of the world, which it most-certainly is not). I'm all for debate, and I live to to think outside the box - but don't for a second assume that every question I post in the LAVA lounge is representative of my views - they're questions, not statements.

That said, if the conjectures and ideas in this or any other thread form your view of me, then so be it - there's nothing I can do about that other than state my case and let you make up your mind. Until then, I'd ask you to keep away from personal profiling - if you want to talk about climate change, redistribution of wealth, systems of government or whatever other topic then go for it, but don't try to characterize me, especially since I haven't even done that myself.

How do you set the svn:needs-lock properties for use in a Lock/Unlock model in TortoiseSVN?

You can set it repository wide (I think that only works for new items?), or set it on a file-by-file basis (right click on the file, TortoiseSVN, properties, New..., property name = svn:needs-lock). Our IT dept has a script that runs after TortoiseSVN install that makes our clients add the needs-lock property to all items added to the repo - not sure if I can share that, but let me know if that's what you're asking for.

NI's exams are based on their training materials. If you've taken the classes (and really understand the concepts involved), then your best bet is to go back and thoroughly review the manuals. Your ability to accurately and thoroughly regurgitate the training concepts will facilitate your passing the exams.

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.

I have alos used a project for my re-use stuff.

Are the VIs in the project, or is it just a convienient way to access your vip files?

In addition to crelf's comments, you can also store LV projects in a LV project. So you can create your other projects and add them to the Big Project. You can double click on a project in the Big Project tree to open it up.

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.

Also, what vis should be listed in the project directory when I'm done? Right now, there's a whole bunch of vis that I don't need -- whatever I created while the project was open. Should the listing just consist of whatever top level vis and files I need to actually use to build the executables? Or should all 1800 vis be listed (hopefully not!).

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

Is there a way for users to tell what the current version of the forums is?

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

I find it amusing that you copied it with the spelling mistake, but I guess I'm too easily amused.

Yes Yair, you are

If anyone is looking for an Userinterface for TestStand, maybe this site would be a good place to start…

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)?

And here is the code we changed to and started generating problems.

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

How does one go about diagnosing such problems with GOOP objects?

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.

IMO, the single best thing you can do to avoid conflicting changes is to design your application to be as modular as possible and assign owners to each module. (i.e. RF Receiver, Propulsion, Vision, Chainsaw Controller, etc.) Create the rule that nobody except the owner can change a module's VIs. Define the interfaces (input and output VIs) for each module that allows it to send and receive whatever information it needs. Libraries (.lvlib or .lvclass) are very helpful for this kind of modular programming as you can set the interface VIs to be public and everything else to be private.

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.

One way of working around this is setting the tread read-only VIs as locked switch in the LV options...

Totally true - this should be the default setting IMHO. If you agree with me, vote it up over here!

I think that LabVIEW should be smarter about it and detect when the path is too long and if necessary rename/relocate the offending VI(s) so it just worked. For most people this solution would be ideal.

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?

Thanks to everyone who who had something encouraging, intelligent and/or challenging to contribute.

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

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 6 occurred at Create Folder in Create Directory Recursive.vi->AB_Destination.lvclass:Create_Destination.vi->AB_Build.lvclass:Create_Destinations.vi->AB_Application.lvclass:Create_Destinations.vi->AB_Build.lvclass:Build.vi->AB_Application.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: Generic file I/O error.

=========================

NI-488: I/O operation aborted.

C:\Projects\VI Engineering\Software Products\1-09-xxxxx - VI Engineering - Hardware Explorer\Engineering\5 - Release\Executable\VIE Hardware Explorer\VIE Hardware Explorer.exe\LabVIEW 2009\user.lib\_VIE Internal Reuse Library\_vie_lib_dialog_&_user_interface.llb

Due to operating system limitations, LabVIEW cannot create the folder because its complete path contains too many characters.

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.

You do realize that you are now responcilbe for any bug that sneaks in thru that door.

Hey man - my app's only repsonsibility is to report issues it sees

i got a nice warm feeling the first time I saw my exe start and find the new functionality dynamically.

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

One could assume that LAVA contributes significantly to the popularity index of LabVIEW

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.

scripting_workbench.beta3.zip

Thanks François.

Retrieve Shell Icon.vi (LabVIEW 8.6.1)

Beawdy - thanks mate.

Scripting Workbench and PMS Assitstant are still useful nowdays...

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?