To add to the tally, apart from the ‘defbtn’ is not defined issue, I have been successfully using GetString with a list of options in the past to provide a minimum UI allowing to select a block name from the list of blocks’ instances present in the model.
With the latest 20140701 build of IronPython, although I am still picking up the correct number of blocks definitions from the context, only a small random number amongst them is displayed in the dialog. It looks like there is something broken in the gs.AddOption(s) …
This should also bring python on Mac Rhino up to the same level of functions that are available in Rhino for Windows (with the exception of a handful of user interface functions that I am still working on an implementation of.)
Please find attached the python script and screen shots of the issue: on the right hand side you can see the result of the script getOption showing sevral blocks have been found (confirmed by the block manager open next to it) but they do not show in the script getOption window.
As a matter of fact, by looking at the screenshots, it appears that only block names without embedded blanks spaces are listed. Maybe this is the actual reason behind the list not being complete.
This is how Rhino has always worked. Spaces are not allowed in options. I can tweak rhinoscriptsyntax to automatically ‘tune up’ the strings, but I’m pretty confident that this is not a regression in behavior and that you would have had this problem with the older builds of Mac Rhino / python (also Windows Rhino)
I must admit, I frankly do not precisely remember if there were spaces in my previous tests…
It will be a good idea to “tune up” the string as a general feature in rhinoscriptsyntax, but I would not put it on the top priority list right now, you may have some bigger fish to fry
That would be fine with me. By the way, getOption() doesn’t seem to be listed in the offline docset (I’m using Dash) for Rhino.Python. A note in the docs would be helpful whether or not any behavior changes.