gmart

QUOTE (David Wisti @ May 28 2008, 11:01 AM)

Nice article Jim!

I hope I'm not thread jacking but I thought that 8.2 would put same namespace vi's inside the exe with mangled names? But in 8.5 this was changed to placing them outside the exe. I wonder why mangled names is not a build option.

The name mangling (renaming) was one of the main problems with building apps that used LV classes. So for 8.5, the algorithm that handled name collisions was made the same for all project library types.

QUOTE (Michael_Aivaliotis @ May 20 2008, 01:45 PM)

I tried this and it seems to do what I want. May I suggest this be added to the LAVA CR? It's pretty useful.

I haven't tried this but it appears to have what I want too, however I needed SVN integration (can't you read my mind?).

Wow, this will do what I want too! Hmm, looks like NI has some code duplication here.

http://lavag.org/old_files/monthly_05_2008/post-2-1211312716.png' target="_blank">

Similar but different as they say .

QUOTE (tcplomp @ May 18 2008, 01:56 PM)

Why? Why? Why?

So I write a tool that solves a lot of problems for me (checking everything is in SCC, up to date and in the right place) after running this tool I have to inform my users to manually do a Tool->SCC->Refresh?

A lot of items in the LabVIEW Tools menu have a http://zone.ni.com/reference/en-XX/help/371361A-01/lvdialog/application_item_tags/' target="_blank">application item tag why not this one?

The one thing I can currently think of is closing the project and reloading.

Not very sophisticated but it should do the trick.

EDIT:

I slept a night and can understand the why (some smart ###### would blame you for too heavy network load or something).

But somewhere there is a piece of code that takes in a lvproject reference and updates the status of the icons.

Where is that piece of code?

Ton

As I said earlier, there is no one piece of code that does the refresh. The VIs are called as part of the LabVIEW project code and isn't designed to be used standalone. As you noted, reloading the project will cause the states to be refreshed since when the project is next loaded, we have to determine the SCC status of each file. Programmatically closing and reloading a project could be a problem since you never know what a coustmer has opened at the time.

QUOTE (tcplomp @ May 7 2008, 10:25 AM)

Is it?

It functions the same when using MS SourceSafe and PushOK SVN.

I probably wasn't clear since I didn't know what you meant by "my own functions". What I meant is that the Tools>>Source Control>>Refresh menu calls into the currently configured SCC provider. So yes, it would work for both VSS and SVN. What I should've said is that the menu is independent of any custom tools that you may have developed (see below).

QUOTE

The palette VIs are not linked to the functionality of the Tools menu. So if you check in/out via the palette SCC VIs, you will need to manually refresh the project you are working within. It was a design decision to keep the palette VIs and the integration behavior separate.

QUOTE

I don't believe there is one VI that will do the refresh by itself. The code is part of the SCC code that works from the project. As far as that method goes, it won't return what you are looking for. I'm not even sure if it will work right since it's not a public method. Let's put it this way, I don't use it

QUOTE (tcplomp @ May 17 2008, 01:03 PM)

I am using Subversion and the LabVIEW integrated tool at home via the PushOK plugin. The repository resides on a local Ubuntu server.

I have hardly a problem with the locked not-checked out items in the LV project.

I am going to enjoy this, at work I created a tool that checked all the files in the project, and reported those that were either old, not checked in or not in SCC. If anyone is interested in testing, PM me. I will try to get it up to CR standars (shouldn't be too hard though it contains express VIs).

Doe anyone know how to setup a https subversion repository on Linux?

Somehow I can't get it right.

Ton

Ton,

Since Jim feels the SVN model doesn't work with the check in/out model of the LabVIEW SCC integration, would you care to give your feeling on working with Push OK from within LabVIEW. Have you just learned to deal with the differences of the development models? Does this impact your productivity? Do you feel working with the plugin within LabVIEW helps you beyond using Tortoise SVN?

QUOTE (Jim Kring @ May 16 2008, 02:24 PM)

Omar mentioned that he was using TortoisSVN, so I'd assume (actually, I know) he's using Subversion. Using subversion with LabVIEW's SCC provider is like swimming against a current. Subversion wasn't designed for the check-in/check-out development model that LabVIEW and SCCAPI assumes, and there is no native support for Subversion. You have to use a third-party SCC API adaptor. All this just gets in the way of things, IMO.

I understand SVN's development model is different. In general have you worked with an IDE (not client like Tortoise) that doesn't get in your way when using SVN (for example, Visual Studio)? Is the check in/out model such an impediment that even with the third-party SVN plugin for LabVIEW, you feel your productivity is diminished?

QUOTE (Omar Mussa @ May 16 2008, 11:09 AM)

Good point, I haven't tried using built in SCC integration for a while. The main reason I stopped was that I have different SCC repositories/servers for different projects and in the past LabVIEW SCC could not handle that. I haven't looked into it for a while but just from quickly looking at the LabVIEW 8.5 SCC options it doesn't look like that has been addressed.

I'm currently using TortoiseSVN from Windows Explorer for all of my SCC operations.

8.5 allows you to configure the SCC proejct on a per LabVIEW project level. You still have to enable SCC at an environment level. Also, only one SCC provider is supported even on a per LabVIEW project level. What SCC package do you use?

QUOTE (Omar Mussa @ May 16 2008, 09:45 AM)

I just posted an article: Fighting Corruption: Using Source Code Control Systems (SCC) with LabVIEW Class Files to ExpressionFlow.com.

The article highlights ways that LabVIEW class and project data can be corrupted and some SCC practices that can help you to recover from them.

There is no mention of using the built in LabVIEW SCC integration. Do you use it? If not, why?

QUOTE (jgcode @ May 15 2008, 04:52 AM)

The http://zone.ni.com/devzone/cda/tut/p/id/6893' target="_blank">National Instruments Product Compatibility for Microsoft Windows Vista explicity states that 8.2.1 works with Vista.

I believes this means 8.2.0 does not, but I can not confirm first hand.

8.2.1 was specifically tested on Vista so that's why it is listed as compatible. There isn't some magic bit that makes previous versions of LabVIEW not work. I want to say I've run 8.2 on Vista (I haven't tried 8.0), but the officially supported version is 8.2.1.

QUOTE (tcplomp @ May 7 2008, 08:17 AM)

Does anyone know how to refresh the SCC status of the LabVIEW project?

If I use my own (LabVIEW based) SCC functions the project isn't refreshed. It would be nice if I coul execute the same menu as the Tools->Source Control->Refresh status on the project window.

Ton

The Refresh menu is tied into the provider configured within LabVIEW. When you said you use your own SCC functions, what does that mean?

If you can make the move to 8.5.1, I would say go ahead. Obviously, you know your situation best and can determine if you can update without impacting your project.

Regarding your dependency question, I would expect that 8.5 would have picked up the dependency better than 8.2.1 did since it does automatic dependency tracking whereas it was manual in 8.2.1.

Thank you for the additional information. What I've typically seen regarding error 7 is that there is a library/class/xcontrol that has a link to a missing file. During the build when we try to copy the file, we get the error that the file is missing. Unfortunately, in 8.5, we don't report the file that had the problem (that has been addressed in 8.5.1). I would suggest examining any libraries/classes/xcontrols for missing files. Also, you could try modifying the options in the Additional Exclusions page that deal with libraries.

Posting the errors you are getting as well as more information about what it is you're trying to build would be helpful.

QUOTE (Aristos Queue @ Apr 8 2008, 03:13 PM)

Bzzzt. Almost true, but at the end you turned it into a lie.

8.5.1 will load any VI saved in 8.5.

8.5 will load any VI saved in 8.5.1.

So it is completely correct to say that the two versions are compatible.

HOWEVER, this does not mean you don't need to mass compile your files. Please read http://forums.lavag.org/-t10528.html&view=findpost&p=43814' target="_blank">this post from LabVIEW's product support engineer.

I turned off "immediate disclaimer" mode when I was responding. Thanks for backing me up.

I would be tempted to try your code with 8.5.1 because what you describe sounds similar to the problem that was fixed. I think we're at a point where having sample code that reproduces the problem would facilitate debugging the issue. If it is possible to narrow down the problem to a subset of your code, that would be helpful. You don't have to have code if you can come up with steps that reproduce the issue. You could also post your code if that would be possible.

Regarding 8.5.1, it is compatible with 8.5 such that you don't need to mass compile your files. I don't have any other good suggestions currently.

QUOTE (Omar Mussa @ Apr 8 2008, 12:56 AM)

Ok, sorry for turning this thread into an NI support page -- not my original intention. I just want to vouch for the fact that this has worked and helped my build a working EXE... The one problem I have now is that when I try to build an Installer now, the installer seems to look for the files without regard for destination or name changes. I'm pretty close to waving the white flag and just leaving everything with default settings even though I finally have my EXE build output looking the way I want.

There was an issue with the Installer builder in LabVIEW 8.5 where some files were not being placed in the correct location. This issue was corrected in 8.5.1. Would you be more specific regarding your problem? What do you mean that it looks for the files "without regard for destination or name change"?

QUOTE (Omar Mussa @ Apr 7 2008, 01:35 PM)

I tried setting the destinations but then I get the following error:

"Error 1357 occurred at AB_Source_VI.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_Build.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: A LabVIEW file from that path already exists in memory, or exists within a project library already in memory."

I think that this is because "the auto rename does not run on the files" :headbang: -- without auto renaming I'm stuck. What I need is autorenaming WITHIN the speficied destination. I guess this is a damned if you do, damned if you don't bug.

You'll need to have a separate destination for each class. You can't send them to the same location because then you'll run into what you have now. That is why if you notice, the autorename creates a separate directory for each collision per class. So essentially, you'll need to try to do the same thing.

QUOTE (Omar Mussa @ Apr 7 2008, 12:07 PM)

Ouch I forgot about that :headbang: ...

and it explains why I was getting the mysterious and always ellusive error 1502 during the build (Can't save a bad VI without its diagram) -- this error message is the terrible because it does not specify the bad VI path/name or anything.

Maybe you can help me figure out the solution to my original problem. I want to distribute the application without having LabVIEW auto move/rename VIs/ctrls during the build (or at least I want to move all of the output from the auto movement to the 'data' directory instead of the target app root directory. How do I do this?

The error reporting was improved in LabVIEW 8.5.1 to return the name of the VI that had the problem.

To avoid the auto rename, what you should do is in the Source File Settings page, manually set the destination of files that appear in the warning message to the "data" directory. By doing this, the auto rename does not run on the files.

QUOTE (Michael_Aivaliotis @ Mar 20 2008, 11:25 AM)

Aaaarg! Definition of "relative"? Response from support:

Just to remind y'all, the project file is located under the "mycode" folder.

So out of the three above folders, only the last 2 remapped correctly when the project file moved. I consider this a bug. What do others think? It sounds like, "leave everything as default and it will work". huh? The one good thing from this discussion is that now I finally understand the mystery of why the destination path behaves like it does and I hope I've saved others form smashing their computers to the wall.

First, a little history to put this situation into perspective. The decision of what to use for a default destination directory was based on the attempt to not cross link the output files and source files. This is why the default build location is a sibling directory of the source directory instead of a directory under it. If the output directory was under the source directory it could be possible that if a source file was missing, LabVIEW's search algorithm would find it in a subdirectory under the source location.

The calculation of "relative" is based on the above situation. The primary destination directory is considered "relative" if it's a sibling directory to the project's parent. This matches the behavior of the determination of the default destination. This choice for "relativeness" was chosen to avoid issues of having a destination path with many relative locations. For example, in your example, we could store the destination directory as "..\..\..\builds". Now if you move the project to C:\temp, what should happen?

I think we have this behavior because we don't have a user defined base path from which we determine our relativity. We use the project path as the base path but that may not be what you want. It works in a majority of the cases, but since projects can be moved anywhere, you do run into these types of problems. So, while this may not be the answer you wanted, I hope it sheds some light as to why the current behavior is what it is.

QUOTE (Michael_Aivaliotis @ Mar 20 2008, 11:25 AM)

Aaaarg! Definition of "relative"? Response from support:

Just to remind y'all, the project file is located under the "mycode" folder.

So out of the three above folders, only the last 2 remapped correctly when the project file moved. I consider this a bug. What do others think? It sounds like, "leave everything as default and it will work". huh? The one good thing from this discussion is that now I finally understand the mystery of why the destination path behaves like it does and I hope I've saved others form smashing their computers to the wall.

I wasn't trying to be flippant when I said definition of "relative". I believe the support response is what I was trying to say. We are doing the relative-izing based on some definition of relative. I'll get you more info when I find it.

I haven't got a change to look more into this, but the default destination directory is not the directory you listed. It is something like "D:\_Projects\Experiments\subfolder\buildpathissues\source\builds\mycode\My Application". So the directory in your example may not fall into the definition of "relative" from the algorithm that calculates this. I'll look more into this when I get a free moment.

QUOTE (Michael_Aivaliotis @ Mar 17 2008, 11:16 AM)

[LV 8.5] I've just only now noticed this issue. When I open the exe build specification on different computers, where the *.lvproj file is located in a different folder, the Destination directory path setting in the Information section is absolute. This has serious implications in a multideveloper environment. Each developer has their project folder in their own location and when they open the build it will fail to execute because the path doesn't exist on their machine. This destination path needs to be relative to the project file. How many years has NI had to get this right?

Can you give a concrete example of the directory problems you saw? The destination location should be relative to the project's location.

This issue has been reported to R&D - CAR# 68069

It seems that one of the project libraries (probably the one listed in the error message) may be missing a file. I would open your project and search for the missing item. I believe that once that reference in the library is removed, you should be able to build.

QUOTE(crelf @ Feb 19 2008, 05:23 PM)

I think that it's the expected behaviour for a strict type def, but not an ordinary run-of-the-mill general type def.

In my experience, a strict typedef is typically used for keeping the look a certain way for front panel controls. Strict-ness doesn't really apply for block diagrams constants. Hence why the confusion with strict typedef ring constants not updating their strings when the typedef is updated. But that's a whole other discussion .

QUOTE

The above is case is why people would want the option to view massive clusters as icons. Yes, it is optimal to be able to view a diagram and see what is going on, but it gets really annoying to have to make room around a huge cluster constant just because you need to initialize a shift register with default values. While it would not be my first choice, I would be ok using a VI just to hold the massive constant if it acted just like a constant (which it doesn't now).