Value List values (set by Python script) report being "None"

I am trying to populate value lists with keys from a dictionary (RhinoMac 5). I have written some Python code (cobbled together from guidance on this site) that sets the values based on an input list, but I am finding some strange behaviour. After the values have been set (and they are visible in the list), the Value List values turn out to be “None”. If the list contains numbers, then sometimes it is OK (but not always). I mist be missing something, maybe some sort of refresh.

Any help would be much appreciated. (15.4 KB)

Were the second set of panels were created on Windows or copied over from a Windows-created document? It’s a bug in GH for Mac, text in panels panels with Windows-style "\r\n" new lines get split wrongly, leaving a trailing \r which causes all sorts of problems.

You can see the problem by printing
map(repr, listnames)

In this case causing the value lists to be formatted and parsed wrongly:

As a workaround you can use this script to convert all newlines in panels to "\n"

@dan I reported the issue here before but noticed it hasn’t been logged on YouTrack, thanks :slight_smile: : Bugs - Grasshopper for MAC

Thanks for the reply. All of this was created on a Mac. I will test it out on a PC tomorrow when I am back at work. I noted that I had to type return to get a new line when I was typing numbers in a panel, but since the new Value List is created directly from code, I don’t see why this should be a problem…

Then again… I have played around some more, and I think you are probably right. It seems that Grasshopper treats number lists in a different way from text lists.

@dan Hi Dan, this is not an immediate problem for me (provided this code works on PC, but it is a significant problem for working on a Mac (if this is indeed the reason for the problem). Let me know if I need to log a bug once I have checked it.

I don’t think this will work in my case, because it is not a panel and the value list is created by the code.

Ah okay, I see what you mean now - there were actually two separate issues there, one of which was the odd panel formatting difference between the top and bottom panels.

Value lists will evaluate the right hand side of the expression, so you have to wrap them in double quotes to be parsed as strings, something like this:

for n in newlist:
    try: # to parse n as an integer
        rhs = n
    except ValueError:
        rhs = '"{}"'.format(n)
    vallistitems.Add(Grasshopper.Kernel.Special.GH_ValueListItem(n, rhs))

See attached (13.9 KB)


Thank you so much for your help.

I am not sure what you mean by “odd panel formatting”. However, I am very impressed by your fix - you have demonstrated that you understand the problem by fixing it in the document that you sent me.

However, I can’t see how to get the fix to work on my document - I have run your script on my grasshopper document, but the problem remains. Also I see no difference between your two “repr(x)” scripts, and yet the results are different. What is the difference?

EDIT OK - I see now that adding the double quotes to the string fixes the problem. I was a bit slow on that one… Thank you!

Ran into the panel-newline problem again earlier today, and dug at it a little instead of just applying the quick fix- so it turns out that copying and pasting multi-value panels actively mangles the newline characters, even if they were correctly formatted to begin with :open_mouth:

Check it out:

( pretty crazy that these legacy differences from the age of teletype printers are still causing problems in today’s software … )

1 Like

It seems that this is a significant ongoing problem in using Rhino on Macs. Although I switch between systems fairly regularly, I don’t normally have problems with other programs. Are McNeel taking this seriously?

I apologize for the delayed reply @Andrew_Mole and @qythium. Yes, we’re taking steps to remedy this. RH-44546 should go out in the 6.5 service release of Rhino 6 for Windows, which - in the long run - ought to alleviate this problem.

Thanks @dan - it seems strange that this is a Windows problem at its heart rather than one that can be fixed in MacRhino, but I acknowledge that I have no knowledge of the inner workings of Rhino. Glad to hear that you are working on it. Since I mainly work on WinRhino, this will not be a significant issue for me (provided the fix does not break anything in WinRhino, of course…). :wink:

Hmm, I find it strange too that this should be considered an “in the long run” sort of bug, it seems like a pretty significant issue that potentially affects the correctness of Grasshopper scripts, as shown in the screencast above -

Not in an obvious “why is this throwing errors” manner but a more subtle and serious “why am I getting wrong / different results” that one may not even notice, especially since we’re talking about invisible characters here.

(Also, isn’t this something that could be easily patched with a call to String.TrimEnd('\r') in the appropriate method? Even if the underlying bug takes some time to sort out,)

Sorry @Andrew_Mole and @qythium, I may have misunderstood the problem. Let me look into this a bit more. (I was making the - likely mistaken - presumption that these \r were being added by Grasshopper for Windows and had be opened on Mac. Sounds like I’m mixed up.)

This is not (directly) connected with Windows. I have had these problems working only with RhinoMac and Grasshopper without Windows files (as far as I remember).