Jump to content

gmart

NI
  • Posts

    148
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by gmart

  1. QUOTE (David Wisti @ May 28 2008, 11:01 AM) 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.
  2. QUOTE (Michael_Aivaliotis @ May 20 2008, 01:45 PM) Similar but different as they say .
  3. QUOTE (tcplomp @ May 18 2008, 01:56 PM) 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.
  4. QUOTE (tcplomp @ May 7 2008, 10:25 AM) 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 I use the SCC VIs: However when I do a checkin of a file the project does not update (unless I use the menu option). 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 Could you tell us where the VI is located that does update the project? I think the private method 'SCC Get Info' might help (haven't tested it yet): EDIT: Additional idea, could it be that I edit the SCC status from another application instance provide these problems? Ton 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
  5. QUOTE (tcplomp @ May 17 2008, 01:03 PM) 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?
  6. QUOTE (Jim Kring @ May 16 2008, 02:24 PM) 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?
  7. QUOTE (Omar Mussa @ May 16 2008, 11:09 AM) 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?
  8. QUOTE (Omar Mussa @ May 16 2008, 09:45 AM) There is no mention of using the built in LabVIEW SCC integration. Do you use it? If not, why?
  9. QUOTE (jgcode @ May 15 2008, 04:52 AM) 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.
  10. QUOTE (tcplomp @ May 7 2008, 08:17 AM) The Refresh menu is tied into the provider configured within LabVIEW. When you said you use your own SCC functions, what does that mean?
  11. 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.
  12. 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.
  13. Posting the errors you are getting as well as more information about what it is you're trying to build would be helpful.
  14. QUOTE (Aristos Queue @ Apr 8 2008, 03:13 PM) I turned off "immediate disclaimer" mode when I was responding. Thanks for backing me up.
  15. 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.
  16. QUOTE (Omar Mussa @ Apr 8 2008, 12:56 AM) 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"?
  17. QUOTE (Omar Mussa @ Apr 7 2008, 01:35 PM) 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.
  18. QUOTE (Omar Mussa @ Apr 7 2008, 12:07 PM) 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.
  19. QUOTE (Michael_Aivaliotis @ Mar 20 2008, 11:25 AM) 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.
  20. QUOTE (Michael_Aivaliotis @ Mar 20 2008, 11:25 AM) 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.
  21. 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.
  22. QUOTE (Michael_Aivaliotis @ Mar 17 2008, 11:16 AM) Can you give a concrete example of the directory problems you saw? The destination location should be relative to the project's location.
  23. 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.
  24. QUOTE(crelf @ Feb 19 2008, 05:23 PM) 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 In short, representing constants by any other means reduces the readability of the block diagram (unless, obviously, that constant is a cluster of arrays of clusters of...) 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).
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.