Jump to content

Ed Dickens

  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Not working on Win7 64bit

    I seem to be having some similar issues as others have posted, but I don't yet see a solution. I just installed JKI TSVN Ver. on Windows 7 Pro SP1 64 bit with TortoiseSVN 1.6.12, Build 20536 - 64 Bit , Subversion 1.6.15. Running LabVIEW 2010 SP1 32 bit, the only JKI TSVN menu item that does anything is "About". I'm guessing something odd is happening between the 64 bit version of TSVN and the 32 bit version of LabVIEW. Ed
  2. Commit on Rename?

    Thanks I guess I just missed the fact that one of the dialogs I clicked through was the Commit dialog. I suppose I should slow down and read. I just didn't expect it since doing a Rename from the TSVN context menu doesn't invoke a Commit. Ed
  3. Commit on Rename?

    I just tried to rename a control using the tool. The control was renamed, but it then tried to do a Commit on the renamed file. Our repository is setup to not allow a commit unless you enter comments, so I received an error that the commit didn't complete. Is there a reason you do a commit on a Rename operation? Seems you'd just want to do a 'Delete' on the old file and an 'Add' on the one. Don't know if it makes a difference but this is on a Real Time target. Ed
  4. The newly released Array package (3.0.0) breaks my Real Time application due to the addition of the LV Class array handling VIs in several of the Polymorphic VIs. Had to downgrade to 2.7 to continue work.
  5. Upgrade install in non-standard location

    Well, my other machine does not have VIPM installed. I remember now I got that machine new to use temporarily on a project and didn't have time to install anything until I got on-site. I didn't have Internet access once there so I couldn't download anything. So I just dumped my user.lib and the openg directories from Resource and Menus to the new machine. If you could get me a copy of one of the pre-release VIPM installs, I could put it on this machine and run the 1.0 update and see what happens? Ed
  6. Upgrade install in non-standard location

    I don't remember any specific error messages. I do have another machine with the same setup I need to run the install on, but I won't be able to do that until later today. I'll post what I find from that. Ed
  7. I had the pre-release VIPM installed under my 'National Instruments' directory instead of in 'Program Files'. I ran the 1.0 release installer in upgrade mode. The first time I ran it, it shows it uninstalling the current version, then starting the install, but it fails. I re-ran the installer and it comes up showing the default path (...Program Files...) instead of where it was installed in 'National Instruments'. I ran it without changing the destination and again it failed to install. Ran it a third time, but changed it to the still existing 'VI Package Manager' directory under 'National Instruments'. The install completed without problems and VIPM runs. Ed
  8. I noticed today that if you attempt to register a version of LabVIEW with VIPM and there happens to not be an .ini file, you get an error that states either the path is bad or the port is already in use. Ed
  9. Something "New" happened today

    Thanks Jim, I uninstalled the package but it still didn't work. The NewDlg InitTree.vi was still calling the NewDlg InitTree__buggy.vi so I had to download your attached VI. All is now fine. Ed
  10. I selected New... from the File menu, and instead of the normal LabVIEW 8 "New" template browser, I first got a small dialog reading, "You cannot use "NewDlg InitTree__buggy.vi" recursively.", then I got what looks like the template browser from 6.1, but with a LabVIEW 8 banner. The "__buggy.vi" makes me think this was an OpenG fix for something in the normal LV8 template browser. I started to dig around and found one of the subVIs of of the "lv_new.vi" (which is now broken) is "NewDlg InitTree.vi" (also broken) and "NewDlg InitTree__buggy.vi" is a subVI of that and it's trying to call itself making it broken. Does any of this make sense or sound familiar? I used the browser just the other day and didn't have any problems and I haven't changed any OpenG stuff.
  11. Package cache

    Thanks Jim, Curiosity more than anything. I was poking around and just happen to notice it. Ed
  12. Package cache

    Just wondering why we need multiple copies of the packages? We start with the "master" copy that gets downloaded to the cache directory, then each package is copied to the databases directory for each version of LabVIEW we install to. Since all the packages are the same for all LabVIEW versions, couldn't the cache copy be used and just keep the "files-installed" file in the database directory? Ed

Important Information

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