Testing some of our V5 scripted tools in the WIP and can’t figure that out: in V5 I used to be able to read some of the settings not directly available via RhinoScript by checking the Rhino registry keys, in particular the Advanced Display Modes settings. For example: HKEY_CURRENT_USER\SOFTWARE\McNeel\Rhinoceros\5.0x64\Scheme: Default\Options\DisplayAttributesManager
In V6 however these keys don’t seem to exist over here, I am not sure if there is some other place to look or the display mode settings are no longer kept there. All I see now is: HKEY_CURRENT_USER\SOFTWARE\McNeel\Rhinoceros\6.0\Scheme: Default but there is not even Options category to look for DispplayAttributesManager.
I can also read some of these settings via exporting display mode to ini file and checking there but this is much slower sometimes, so I’d rather check in the registry. Please let me know if this will still be possible in V6, or is there any better way to handle this.
The entire settings system has been rewritten in V6. Only non-default settings are saved and those settings are stored in XML files on disk instead of in the registry.
Thanks, that’s exactly what I was looking for.
The concept of XML is a new thing to me, so trying to look at parsing them via RhinoScript, is using “Microsoft.XMLDOM” the right way to go about it?
Also, a few more questions:
Looks like RhinoScript UI dialog positions are still added to Registry once initiated. Is that still correct location to red/set their screen position?
What file should I look at for Display Mode Settings - would that be the one with all of them? AppData\Roaming\McNeel\Rhinoceros\6.0\settings\settings-Scheme__Default.xml
if so, is that a standard file name on each user’s computer? I guess I am looking for V6 equivalent of “HKEY_CURRENT_USER” & Rhino.RegistryKey(2) " that used to work in V5.
Are these settings in XML file dynamically written every time display mode changes or saved only on Rhino exiting? This used to be the case with registry but not sure if with xml there was any change. I am basically looking at the best way to read/modify display mode settings from the script while exporting display mode to *.ini, changing *.ini and reimporting usually takes noticeable time in script runtime.
I don’t believe so, almost all settings in general are now written to these XML files.
That is the file and is the standard name that you will see. Rhino has had separate schemes for a while, but they aren’t used a whole lot.
The settings files are updated at runtime by Rhino and not just when Rhino shuts down. All running Rhino’s watch this file and update settings when the file changes.
This sounds like a lot of guesswork at things that may change over time. Could you help us understand exactly what it is you want to change? Maybe we can improve our SDK to make these changes.
You are right, it was only the ones written by my own scripts that added these keys to the registry.
From what I have tested, the Display Settings update every time something changed in Rhino, but Dialog Positions (at least UI methods of RhinoScript) only get updated when exiting Rhino. So yes, this is may not be the most reliable way to dealing with it.
What might be useful is a method to be able to force Rhino to re-read the xml file, so if I make some changes to it via script (display modes, dialog positions) they would get updated. This is what I am doing now in V5 and registry for dialog positions and it works well.
So: I need to be able to change very specific display mode settings ‘on the fly’, ideally without exporting the mode to .ini file and importing it back, which is currently possible via RhinoScript but takes a while. Also, I need to be able to control where the RhinoScript UI dialog boxes show up. This is all related to some scripted interactive tools I have been working with where objects get placed at the cursor in the model or the cursor drives the camera, so many times I want to bypass the command-line input and rely on at-cursor UI input boxes and lists (PopUp menu is the only one that has built-in control where it shows up). And since these tools are real-time display, being able to control some aspects of Display Modes that influence the performance (Advanced Lighting, Shadows,Scene Lighting type, Line Thickness etc) is important. I have it all working nicely in V5 but now I see that in V6 it will no longer work this way with the registry.
Hope that explains a bit ‘why’. Now I need to figure out ‘how’ in V6…
I would imagine the correct way to approach this issue is to provide parameters to the dialog box functions for their initial position/size. Tweaking registry settings or XML files in the background is not a good long term solution. @dale, does this make sense as an addition to our scripting SDKs?
This also sounds like new functions for scripting.
thanks; I do realize this would be a lot of work to add to RS methods for quite a ‘niche’ use… that’s why I was looking into alternative ways to deal with it and trying to understand how new Rhino version will be handling that.
Ideally long-term we will have access to these parameters without workarounds.
Great, yes please - would be helpful to have control over this without registry/xml workarounds in V6. I counted 16 RS UI methods that would need this. So maybe not difficult but some more typing…
If you can come up with a slick and flexible way to access every aspect of Display Mode found in exported DisplayMode .ini file (or V5 registry, or V6 xml) that would be fantastic to have quick access to read/change them. So far I have no suggestion how this could be implemented instead of creating methods for specific, selected areas of the Display Mode… I vote yes, for access to all of these settings.
And could we get all of those for python/rhinoscriptsyntax? EditListBox, MultiListBox, and OrderListBox don’t exist yet (in V5 or V6 as far as I can see).
Great, thanks a lot for adding these… It will be so much easier to do a lot of things I do now in a work-around way now!
I will try updating my tools with these new methods and report back how it works.
With the impending release of V6 I’m trying to figure out a way to automate the installation process (not the core program, but all of my custom stuff), since we have over 150 installs spanning 3 countries. It was easy in V5 to just distribute the registry key that handled all of the settings, but now with the .xml files located behind user names, it’s not so easy.
One thought was that perhaps these xml files could be saved somewhere else? Does the user have the ability to define where the settings are saved?
Since the release of V3 I’ve set every user up with a folder in their C drive, and I’ve kept all the files there. Doing this allows me to keep everyone up-to-date with a batch file that is run at login. So if I make a change to the toolbars, scripts, plug-ins, etc., everyone has the latest changes.
I’m definitely open to suggestions on how to handle this in V6.