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

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

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

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.

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

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

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.

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.

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.

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.