kevintho

It is my pleasure to support the forum. This community is a tremendous resource.

Parallels 10 was released today for those wanting to upgrade from Parallels 9. Optimism abounds. ) I don't know if this new version will fix this problem, but there's reason for hope. Has anyone here experimented with Parallels 10 yet?

I too have been struggling with this inconvenience for quite some time. I can go for several weeks just ignoring the issue, and then something comes up where it causes me to descend into a battle of will and spend at least a couple hours re-trying settings and experimenting to see if I just missed something the last time around. The lack of Ctrl-Shift-G functionality and quick drop shift keyboard shortcuts are particularly discouraging. It's all very annoying, but not so annoying that I'm willing to stop using VM's in order to gain back the use of the shortcuts that native OS users enjoy. (VM's are a way of life. I don't know how I ever managed to survive without them...) Unfortunately for me, Michael's suggestion (and good fortune) of changing the Parallels' Mouse Shortcuts settings to disable 'Secondary click' and 'Middle click' does not fix the problem for my setups. I have several development Mac systems with a variety of Lion, Mountain Lion, and Mavericks, all currently running Parallels 9.0.24172. I have many WinXP and Win7 x64 VM's. Some are run from the local hard drives, others on an external drive used for portability between Mac development systems (with the VM's running directly from the external drive - it does work very well with almost no performance hit, and what a convenience). The bottom line is that nothing I do or change seems to fix this issue on any of the VM's across any of the development machines. For me, the problem has always existed, starting with Parallels 7, then on Parallels 8, and now on Parallels 9. LabVIEW seems to be the only application I've found so far that is affected, from versions 7.1 all the way through LV 2013. As Jack mentioned earlier, other applications like Notepad++ do not have this issue. I have used VMWare Fusion in the past, but have not upgraded in a long time. I'm wondering if the latest VMWare Fusion might behave differently. I understand from an earlier post that VirtualBox VM's do seem to exhibit the same problem. Has anyone here tried a recent version of VMWare Fusion to see if there are similar issues?

I'm so glad you mentioned this. I thought I was loosing my mind. During project development, I typically create a "Load All" vi to make certain that all components are loaded into memory and quickly available while modifying code. The Load All vi also serves (or at least it used serve well in previous versions of LabVIEW) as a quick and convenient way to detect vi's that need to be resaved due to either explicit or inexplicit modifications. By closing the Load All vi in previous versions of LV, I would be prompted to save vi's needing to be re-saved. Now, in LabVIEW 8.5, I cannot simply "save all" to flush all changes to disk, nor does LV 8.5 prompt for saving vi's which do not have their front panels open. Now I have to actually open all of the vi's front panels to be sure that they are fully opened in order to ensure they are all up to date. I mentioned this odd behavior to a colleague and he thought I'd been smoking something or functioning in some altered reality. I see now, it is not me, its LV 8.5 Thanks, KT

OK. I thought I would follow up on my results. The above approach works fine, so far. I can easily switch between LV71 and LV711 development environments on the same computer. I simply swap names for the top level folder for LabVIEW. 1. Make a backup copy of the LV71 folder, leaving the original folder (I

Thanks for the reply. Another idea, along similar lines, was after patching 7.1 on the development system, and then copying LV71 to a unique folder name from another installation, manually manage renaming the top level folders depending on which client I am currently supporting. In other words the folder name would always be for example "..\LabVIEW 71" that I run the development environment from, which would be swapped with folder names "holdLV71" and "holdLV711" as temporary locations. Don't know how well that will work since I am dealing with windows and all the rubbish from the registry. I guess the key is to what degree running the LabVIEW development environment (whether 71 or 711) is dependent on registry entry distinctions between 71 and 711. Should be fun... I may have to use Virtual PC, but I'll need to determine if the re-saving / revision control system hassels I'm going through now would be offset by the hassels of buying and maintaining another Windows installation via Virtual PC (anti-virus, MS updates, anti-spyware, networking issues, blah, blah, blah puts me in a bad mood just thinking about it :thumbdown: ).

I'm wondering if it is possible to have an installation of 7.1 and then another installation of 7.1 with the 7.1.1 update patch applied, both available on the same system, (obviously only needing to work in one environment at a time). If it is possible, what are the steps to follow for successfully switching between them? This question arises out of the need to support multiple clients from the same set of libraries and tools, and hence from the same development computer system; not wanting to add additional efforts of dual boot or virtual PC, etc. Specifically, I have a client that can't / won't upgrade to the patched version (cost of his test systems being down is too high for that kind of maintenance / updater downtime and risk, especially since it doesn't seem necessary for his needs), and at the same time I'm supporting another client that has updated all of their systems to the 7.1.1 patch. Neither plan to move to version 8, and I need to support both from the same set of my own libraries. Up to this point, I've been just re-saving after re-compiling each time, but that certainly gets to be tedious due to revision control system hassels, etc. I'd be grateful for any suggestions.

I was wondering if anyone has had any experience yet with LV8 being installed on a machine co-existent with previous versions of LV. Since now that LV8 will seemingly have better project orientation and structure, how will that effect currently organized projects in other versions, particularly while coexistent on the same computer? Are there any discovered "gotcha's"? In other words, can we expect LV8 to play nice with its older siblings in the same house, so to speak... Yet another concern is for coexistent add-on tools and tool-kits, libraries, modules (e.g. vision, motion, DAQ, etc.). This is not really a question about upgrading LV, (NI details published in "Upgrade Notes"), but rather a concern regarding coexistence during a methodical or slow migration (or in some cases, perhaps no migration). Any early thoughts, comments, concerns, or suggestions? Thanks, Kevin Thompson