Stobber Posted December 8, 2014 Report Share Posted December 8, 2014 Has anyone put effort into defining a roaming environment configuration for LV? I work on several virtual machines, and keeping my LV settings, probes, glyphs, QD extensions, labview.ini tokens, etc. consistent across all of them is a nuisance. I'd like to put all that stuff in Dropbox so it syncs automatically. Are there known drawbacks or existing tools I should know about before I funnel several hours of tinkering into it? 1 Quote Link to comment
mje Posted December 9, 2014 Report Share Posted December 9, 2014 This is a good idea. I also chiefly work on VMs and have wanted to do this for a while, but never got around to looking into how. Quote Link to comment
ThomasGutzler Posted December 10, 2014 Report Share Posted December 10, 2014 Just check it into version control and force everyone to use your settings Or, have a utility vi that updates the .ini file in a clever way and have an enum on the FP so that every keen employee can make their own preferred settings Quote Link to comment
mje Posted December 11, 2014 Report Share Posted December 11, 2014 I suppose the thing that's kept me from just moving my LabVIEW Data directory to Dropbox is I have no idea how LabVIEW will tolerate concurrent access to the settings. I don't anticipate well. It's not uncommon for me to have two or more VMs fired up each with LabVIEW running. Quote Link to comment
Jordan Kuehn Posted December 11, 2014 Report Share Posted December 11, 2014 I have no idea how LabVIEW will tolerate concurrent access to the settings. I don't anticipate well. LabVIEW and Dropbox frequently fight when building executables on my machine. If I forget to turn off the syncing, often I get file permission errors while dropbox is trying to copy the file and labview is trying to delete the temporary file. Quote Link to comment
Stobber Posted December 11, 2014 Author Report Share Posted December 11, 2014 Sorry for not replying to update everyone. I have some quick and dirty code working to create junctions (a type of folder-based symlink in Windows NTFS) from specific config and data paths to my Dropbox folders. I'm not looking to share anything related to build or things that should be in a project repository; just general config and customizations. I started work on the code to detect and remove the junctions so the user can "unlink" a computer/VM, but it involves UAC elevations and a bunch of calls into the file system to figure out whether a given path is a reparse point or not. I'll post the proof of concept here when I have it working (or the final state of it if I don't finish before Christmas, so someone else can pick it up and keep poking at it). Quote Link to comment
Darin Posted December 11, 2014 Report Share Posted December 11, 2014 I have been doing this as long as I can remember using a combination of SyncToy and DropBox. Works great once the tasks are configured in SyncToy. I have various tasks configured, settings, work in progress code, all reuse code. As an added bonus, it functions as a touch-free backup/SCC/package manager safety net which lets me work away worry free on code which is not suitable or ready for the SCC lockdown. And it is just as easy to sync to a USB stick as it is DropBox so I am never without an up-to-date configuration. A few bummers, certain absolute paths and screen coordinate settings can be irritating when copied from machine to machine. Less of an issue for the VM applications. Second, there is no "merge" operation here, so you have to be diligent about keeping things serialized. Again, for my workflow it is more about being able to go from machine to machine and keep working, and not about bouncing around between machines and trying to keep them in sync. Quote Link to comment
mje Posted December 12, 2014 Report Share Posted December 12, 2014 I have some quick and dirty code working to create junctions (a type of folder-based symlink in Windows NTFS) from specific config and data paths to my Dropbox folders. This is a fantastic idea, I wish I had thought of it earlier. Specifically all I'm really interested in is preserving my LabVIEW.ini settings across systems. Mostly for the quick drop shortcuts, but some other environment options as well. A few bummers, certain absolute paths and screen coordinate settings can be irritating when copied from machine to machine. This is the main reason I'd likely not synchronize all data. I really just want the same config across all my systems. Quote Link to comment
eberaud Posted December 30, 2014 Report Share Posted December 30, 2014 I'm really interested in is preserving my LabVIEW.ini settings across systems. Mostly for the quick drop shortcuts I recently installed some MGI quickdrop shortcuts, but can't find related changes to LabVIEW.ini. What settings are you talking about in this case? Quote Link to comment
mje Posted December 30, 2014 Report Share Posted December 30, 2014 I'm on vacation for the next week so don't have a system handy to check the details, but I recall the quick drop settings are stored in a pair of config tokens. If you have any custom shortcuts defined, do a search for any of them and you should find them. This would be in your private LabVIEW.ini somewhere in your LabVIEW data folder, not the LabVIEW.ini in the main program files folder. Quote Link to comment
hooovahh Posted January 5, 2015 Report Share Posted January 5, 2015 QuickDrop is stored in the LabVIEW.INI but I tend to just blow these away periodically because I'll be developing plugins that then get in a limbo state. If these keys are in the INI it just reads the VI Description of the plugin VIs and sets their shortcut to what is in the description. Also as for synchronizing settings glyphs etc. We have large reuse library, and one package is for glyphs, and another is for "Templates" which has morphed into containing other settings too. During the package install it has a Post-Install VI that sets INI settings to how they should be. It also installs a few quick drop commands, and sets up the shortcuts for right handed developers. Generally we install the reuse library on a fresh machine from a base version, which includes all these packages. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.