gmart

In LabVIEW 8.2, there were issues with trying to build applications that used LabVIEW Classes. The root problem in this particular scenario is that when excutables are built, the files are stored in one location so you can't have two files of the same name. So for name collisions, the mechanism app builder uses is save the files with name collisions outside of the executable in their own folders. This is the same mechanism used for name collisions within Libraries. With Classes, though, there was a bug that the names of the files would be changed. So overrides would not work since the names didn't match. The workaround would be to make each class go to a custom destination. This bypasses the automatic redirection that the app builder uses.

The above problem was corrected in LabVIEW 8.5. You will still get a hierarchy outside of the executable but the names will not be changed. In addition to this issue, other bugs with building apps with Classes have been corrected. Building apps with Classes has been greatly improved in LabVIEW 8.5.

QUOTE(Tomi Maila @ Aug 10 2007, 09:06 AM)

Does this have the same effect as Ctrl + Shift + Run when all files of the project are in memory?

Ctrl+Shift+Run will force everything to save. The project mass compile will only save things that need to save.

In LabVIEW 8.5, there is a Mass Compile option on projects themselves. This will only mass compile the VIs referenced from the project. This limits the possibilities of introducing cross link problems and would avoid the Subversion files.

QUOTE(PaulG. @ May 30 2007, 10:42 AM)

What version control software seems to work the best with LV? Does NI have any plans to develop their own? Does the industry seem to have a favorite?

The question is a bit loaded. The LabVIEW development team uses Perforce internally. LabVIEW also has a VI-based cross-platform Perforce implementation. So Perforce has had extra testing.

As far as it working "the best", you might say that, but others might disagree.

From what I've seen, ClearCase and MS SourceSafe are used more in the industry than Perforce (Both work with LabVIEW). If you ask LAVA users, the favorite SCC system is SubVersion (specifically Tortoise SVN). You can use SubVersion with LabVIEW via a plug-in developed by PushOk.

LabVIEW used to have a built-in SCC system, but that was dropped when 8.0 was introduced since it made better sense to support external providers.

QUOTE(Michael_Aivaliotis @ May 23 2007, 02:36 PM)

My stats:

LabVIEW 7.1.1: 30s

LabVIEW 8.0.1: 2m45s

LabVIEW 8.2.1: 1m30s

So, unless you can launch in 30s you're too slow for me, sorry.

I'm talking LabVIEW startup time without loading any VI's.

I think we're missing a key metric. Where are the stats for the 8.2 launch time? I thought your original complaint was that 8.2.1 was slower than 8.2.

QUOTE(JohnRH @ Mar 16 2007, 12:34 PM)

This just happened to me as well. Never had this problem until I changed the .ico file in my project. Now every time I try to change from the default icon, the project explorer locks completely, and I have to end task to restart. From what I inderstand, LabVIEW didn't lockup like this for the rest of you? Am I the first to have it completely lock up like this? Is this new bug behaviour that I should bring to NI's attention?

Thanks!

John

There was a reported issue (42UGCF3E) where double-clicking in the dialog that lets you select an icon file would cause LabVIEW to hang. I don't know if that is the root of the problem or not but just passing that along. There has not been a report of LabVIEW hanging from just unchecking the user default icon checkbox.

Try this:

Open LabVIEW 8.2

Create an empty project

Right click on the My Computer in the project and create a New VI

Drop a tree control or multicolumn listbox or table onto the front panel

Try to resize the column widths with the resize tool (looks like this: <-||->)

If you can do this, it is because you do not have a source control system setup with LabVIEW.

If you do have source control setup (I am using Perforce) and find that you cannot resize the columns (like me), try this:

Locate the App Instance indicator on the lower left corner of the front panel.

Change this from My Computer to Main Application Instance

Now try to resize the columns in the tree or listbox or table. It should work.

This must be the most bizzare bug I have ever seen in LabVIEW...

-John

The column resize issue has been reported to R&D (3Z98GSXE) for further investigation.

This issue has been reported to R&D (CAR 41HDO7D5).

LabVIEW seems to modify multiple VIs when you edit one, especially in LabVOOP projects. Do you always need to check out the whole project, then modify one VI and finally check in the whole project. Or how do you guys do this with LabVIEW?

Jim's strong opinions aside, there are some benefits to working with the source control integration in LabVIEW. One useful feature is being prompted to check a file out when performing an edit. This helps jimi's problem above. It would be good to know of users who are using Subversion with LabVIEW to see how it works during workflow.

Regarding Jim's comments, be careful what you wish for, you might get it.

Ouch

Don't get me wrong, I've used directories and single VIs on my last three projects, including at my current client's, I just think think they're still useful and they're LabVIEW, so I'm partial. Plus, I admit, I really like to add and add to the tools and capabilities and seldom like to lose something if I don't have to.

Unlike some developers at NI, I like LLBs :thumbup:. My previous comment was self deprecating humor...but as they say, if you have to explain the joke, it wasn't funny

I feel like we need a support group for LLBs and should all start out saying, "Hello my name is <blank> and I use LLBs" Rather than get into a philosophical argument regarding LLBs, I'll try to answer Mike's questions.

A long time ago there were a lot of problems with corruption of LLBs, it was a pain. Then people started using SCC packages with LabVIEW and everyone said to move to directories and single VIs since the SCC tools couldn't handle it any other way. To me that is a fault of SCC, not LabVIEW LLBs. Professional LabVIEW should have it's own SCC that handles LLBs.

As I see it, SCC packages are designed to work with files as they exist on disk. Taking LabVIEW files out of the picture, how do SCC packages handle files inside of zip files? Does it treat the zip file as one file or can it translate the zip file as a directory hierarchy and control it that way? I have not run into settings in the SCC packages I've seen that handle zip files in a way where you can control the contents. I'm not saying there aren't but I haven't run into them. So performing SCC operations on the contents of LLBs is analogous. Regarding LabVIEW having its own SCC, this was the case in pre LabVIEW 8.x. NI moved away from that model since NI is not in the business of developing source control systems. There are many packages that do SCC well and it made more sense to allow integration within LabVIEW for these packages rather than invest R&D resources in developing and maintaining this type of tool.

PS: If Windows Explorer can be given an extension that lets it look inside LLB's why not an SCC?

Viewing into LLBs in Explorer is done via a shell extension. While this might allow SCC providers to view LLB files on disk as directories, I don't know how it would handle storing the files on the server. Plus this technology is Windows only so the same behavior would not be supported on non-Windows platforms.

The standard disclaimer is that NI doesn't officially "prefer" any specific provider. NI just happens to use it internally so we are more familiar with it. It just happens to be a good source control package (though the Subversion fanatics would probably disagree .

Regarding the prompt on edit, the feature in LabVIEW to do this is a dialog WITH buttons where you have to explicitly agree to check the file out. It might have been a Perforce specific dialog. There are two implementations for Peforce - Command Line and SCM. Command Line was written in LabVIEW and interfaces with Perforce. SCM is Perforce's implementation that LabVIEW calls.

Not to confuse you even more but the "Keep files checked out" box if for SCC providers that do an immediate add (such as SourceSafe). For Perforce during an add, because files are added to a changelist, the file is essentially "checked out" still so the option doesn't do anything. During a submit, the checkbox will reopen the file after you submit it.

mainly because I have the feeling, that I don't have this tool *under my control* and I have difficulties in understanding the documentation and therefore, how the software works.

It is true that Perforce's semantics take some getting used to. Why do they have to say "open for edit" when the rest of the world says "check out"? One good reason is that their semantic match how their software works. Perforce uses changelists so in reality when "check out" a file, you are really opening it for edit in a changelist.

what the heck is clobber ???

O.k. I found out, that perforce will not overwrite existing files if I have not checked this option, but what does that mean? Is it really that, what I want to have? What happens to my files? I introduced Source Code Control, because these files are *somewhat important*, and I'd like to be sure that my source code control will not mess up something ?

Regarding the "clobber" concept. From their documentation:

"Specifies whether p4 sync overwrites writable but unopened workspace files. (By default, Perforce does not overwrite unopened files if they arewritable.)"

The reason for this is because most files will be read-only if under source control, so if a file is writeable, Perforce doesn't want to overwrite it since it didn't explicitly change the read-only flag.

e.g. checking out files. I check out files in LV, but they are not realy checked out. OK, in the Project Explorer they get the "checked out" icon, but if you edit them, LV informs you, that this file has to be checekd out. why? I don't wanna have a pending changelist somewhere, I just want the files to be checked out or checked in. Is there a way to force perforce to write the files immediately?

What do you mean about files not being "really" checked out when done through LabVIEW? Once a file fis checked out, it shouldn't you to check out on edit. There is no way to get around changelists in Perforce as mentioned above so anytime you check out a file it will be on a changelist.

e.g. adding files. I just added a new project and wanted to get the last revision on my second machine. The files did not exist in the depot. I first had to open P4C, send the pending changes to the depot. check them in, check them out and then I could retrieve the files. strange. I added them in LV with "add to scc", why are the files not in the depot?

The "Add" concept in Perforce can be tricky if you're used to immediate add operations like in SourceSafe. Again. you are opening a file for add so the file gets placed on a changelist. It is not really added until you submit (check in) the file. Because of the generic interface in LabVIEW, adding a file to Perforce gets reported as the file being checked out. While it may look odd, it makes sense from a functional point of view.

all in all it feels like sitting on a bike with a twisted wheel, I can hold in a way the direction, but it's not precise ...

I would recommend sticking with Perforce a little while longer. It is pretty powerful and I think once you get used to the semantics of the software, you'll like it.

Ton,

I'm not sure TortioseSVN is recognized by LabVIEW.

Under Tools->Source Control->Configure Source Control, I have no choices for Source Control Provider Name. All of the options are disabled.

..and I'm also not too keen on endangering my setup.

Sorry,

James

Tortoise SVN is a stand-alone client for Subversion and does not have integration with LabVIEW (they don't have a plugin that supports the Microsoft SCC interface). There is a plugin written by PushOK that allows working with SVN from within LabVIEW.

Yeah there is no info on there website for it.. I have to go through too much red tape here for that.. if ther was a free plug in that would be better, but I will slowly learn and adapt to using TortoiseSVN outside of LabVEIW

I checked with PushOk and they charge $24 per license for their SVN plug in (similar charge for CVS).

While there is much love for Tortoise SVN for managing Subversion projects, you can try an SVN plugin for Windows made by PushOk that lets you work with your repositories (doing basic check in/out operations) from within LabVIEW 8.x.

Salut.

I am using Perforce for SCC. I have a to enter a password to enter into the depot. After a certain amount of time, i have to reenter that password. When the password is not valid anymore, LV acts like if there was no SCC around!!! Is it possible to make it ask for the password?

Are you using the Perforce Command Line provider in LabVIEW or Perforce SCM (LabVIEW 8.2)? Are you using the default settings option when you configure source control or are you specifying the port, user, and client? If you are specifying the information, there is an entry for password. I believe this should work. There is another concept called "tickets" that Perforce uses, that the Perforce Command Line provider does not currently support.

Until SCC settings are on a per project (rather than a per development environment) basis, I won't be using the integrated SCC. :2cents:

Make your voice heard - http://forums.ni.com/ni/board/message?boar...;message.id=173

The old error ring constant listed 112 of our approximately 2000 internal error codes and knew nothing of other error codes that our General Error Handler did (such as GPIB codes).

We chose to remove the old error constant even though we didn't have a replacement ready yet. In the meantime, we recommend that you create your own typedef enum that contains the error codes that are important for your applications.

Will we have a new error constant some day? In the infinitely applicable words of a senior developer: "It would not be unreasonable to assume that we might be working on something like that."

Jim,

You are correct that currently LabVIEW 8.0 only allows global source control configuration. While this can be annoying to those that have different configuration per project , the usability of the source control integration is much better than what it was in 7.x. There are LabVIEW options such as prompting on edit of a VI, checking out callers during a check out, and so forth that can only be taken advantage of if you use source control in LabVIEW :thumbup: . There are many in R&D who want project level configuration. Those on the "inside" do work on multiple projects at one time as well, so the motivation to add this support is there. It'd be great to have your feedback on a project where global configuration is ok to have.

Regarding different repository types, users typically only use one repository type at a time since sites typically standardize on one source control provider. There are those who do need to switch between types, but they are the exception rather than the rule. I am not aware of an IDE that supports projects connecting to different providers. What I've seen is that IDEs, such as Visual Studio, use the default configured provider for the OS. They read this from a registry key and typically don't allow the user to change this (again going on the assumption that users typically will only use one repository at a time). That's not to say the feature would not be useful, just not typical.

Check out http://digital.ni.com/public.nsf/allkb/26e...625706e00743997. Starteam is on the list of providers that were tested with LabVIEW 8.0.

I have recently tried PushOK's SVN plugin with LabVIEW 8.0. After some configuration headaches (mainly due to not knowing Subversion's semantics), I got it configured and working (check in/out, etc). It is fairly identical to their CVS plugin. I tested it locally and not with a *real* server setup so your milage may vary.