I’m encountering an error in GH for Mac that doesn’t happen in the same definition in GH for Windows.
I’ve isolated the components where the problem occurs into a very simple definition to illustrate the problem.
TextNumberConversionProblem.gh (3.7 KB)
The error message is “Data conversion failed from text to number”
I wonder if it’s a comma/point decimal thing. What language is your Windows running in?
This is indeed a culture issue. This definition fails on my windows machine. I have its Location set to Finland. Using numbers with , as the decimal separator makes this definition work.
@dan, is that enough information for you to track this down?
The conversion code in GH looks quite daunting, so I couldn’t quickly pinpoint the correct spot, but generally for this kind of stuff strings should be parsed with invariant culture.
Sorry, for the confusion. It actually is not because of culture.
There is an empty line in the first panel point XY. Remove that and your grasshopper definition probably will start working just fine.
FixedTextNumberConversionProblem.gh (8.8 KB)
Hi Leo-
Thanks for reporting this and providing a sample. Let me look into this more and see if I can figure out what’s going on.
-Dan
Hi Nathan,
Thanks for looking into this problem. I cannot find the empty line you’re referring to in the first panel.
The fixed file you posted exhibits the exact same problem on my machine.
I don’t know if it’s any help, but when I hover over the input to the Numbers to Points component I can see that every second number is being lost in the input and a NULL is showing instead, except for the last number (-6.0) which is showing correctly.
So items 1(4.375), 3(5.25), 5(1.75) are not converting to numbers correctly in the Numbers to Points component.
Just realized I never answered the first question from David:
Both the Windows and Mac operating systems I’m using are set to English.
Hi @LeoPedersen,
This is what I see when I open the definition you attached to your original post. I made the panel a bit larger to show the entire input. Note the <empty> tag. It denotes the empty line that exists.
Double-clicking on the panel will shows you the text all selected and the cursor on that empty line. Remove the empty line (so the cursor is right after the 0 of -6.0) and click outside the panel (so as not to add the newline back). It should give you
Of course if you don’t want to worry about cleaning up the text input you could add a small cleaner component in-between, maybe something with GhPython like
/Nathan
Hi Nathan,
I’ve stepped carefully through your examples several times, but on my Mac the panels do not display “empty” at all, regardless of whether there is a carriage return after the last -6.0 number or not. I’ve expanded the panel to check, but it’s not there.
Also the Numbers to Points remains in the red error state with the same error message about text to numbers conversion regardless of whether there is a carriage return after the last number or not.
Again the fixed file from your previous post exhibits the same error on my system as my original file. Very puzzling.
Can you also capture a screen of the message(s) from the little balloon of the red component? Thanks.
does this one work for you Leo?
TextNumberConversionProblem__jh.gh (4.6 KB)
works here on mac:
i remade the pointXY panel… and it worked.
?
Yes!!!
Thanks very much Jeff.
This was taken out of a huge Grasshopper definition I’ve been working on for a few years, but it will actually be pretty easy to rebuild the text panels as there aren’t very many of them.
Ok so does this indicate that text in a panel is getting broken in translation between Windows 7 and MacOS?
@dan, I punt this one back to you, as I don’t have a Mac to test with. This appears to be a EOL issue. When I open the panel from @jeff_hammond’s definition to edit the text I see:
Sorry for the delayed reply @LeoPedersen …and thanks again for submitting this definition. I’m glad to see that @jeff_hammond got you up and running and that certainly provides some clues here. I think this warrants some further investigation. Before I peek in the definition, did you create this definition on Windows 7 using the Grasshopper in the RhinoWIP? I guess I should say: on which platform (Windows or Mac) and with with version of Rhino did you create this definition originally?
I’ve logged two bugs here. @DavidRutten I thought that this item (RH-37202) was worth looking into first. It’s not a cross-platform thing, but rather a version 5 to version 6 thing. Not sure what to expect in terms of behavior…errors or no errors.
Perhaps this other bug (RH-37203) I’ve added to @curtis’s list can wait until you’ve looked into the one above. That said, I guess my expectation would be that definitions created with Grasshopper 1.0 - regardless of platform - would be consistent…errors in Num2Pt or not.
@nathanletwory Indeed. I wonder if there is some sort of inconsistency between System.Environment.NewLine at play here. Strange…needs more sleuthing, but I just wanted to get it logged because I didn’t have time to dig deeper right away. Thanks again!
If GH2 is supposed to be a single code-base on multiple platforms, I think a solid approach to EOL would be called for. Does anyone have any suggestions?
I was noticing some strange behavior with Environment.NewLine today here. I don’t know if it’s related or not. I was going to ask @curtisw to take a look…I couldn’t figure out why this was not working.
