Data conversion bug

Grasshopper
1

Hi all.
I have a .gh project where a small script read data from a xls file, than the output is managed with vanilla GH components. The data is always treated as simple text.
Then, at this step, it is converted to a number:

2024-08-05 12_06_34-Grasshopper - excel bici 12_
2024-08-05 12_06_34-Grasshopper - excel bici 12_869×346 18.9 KB

but it fails when first loading the .gh file.
I tried to internalize the data, but the bug doesn’t occur in that case.
I can’t share the script or the xls file…

If I manually re-connect from C data param to C number param, the conversion is correct.

My guess is that, while the .gh load the first time, the xls reading script expire the document in a way that causes the number param to misbehave.
I can repeat this any amount of times, happens always.
Only once, the first time the .gh is opened.
After the first time, it never occurs again. I have to restart Rhino to replicate it again.

Do anyone know similar scenarios? Any ideas?
@DavidRutten @Gijs

2

just a stupid thought -but it happened to me dozens of times- when importing text that might come from different keyboard layout / languages, some characters might not be recognised correctly (I mean at ascii-table level)

last time I saw something like that was in this thread from a few weeks ago: Sorting a tree by the first element in a branch - #7 by inno

just out of curiosity I would try isolating that mysterious “.” while is still text, and replace it with a “.” typed from your keyboard, and see what happens

3

Inside my .xls reader I have a piece of code like this:
.ToString().Replace(',', '.');
…because in italy we use commas as decimal separator :upside_down_face:.
So the “dot” is forced to be the actual dot from my keyboard…

1 Like
4

Even added a vanilla GH replace text:

2024-08-05 12_55_55-Grasshopper - excel bici 13_
2024-08-05 12_55_55-Grasshopper - excel bici 13_1860×716 182 KB

The selected components were added manually after the .gh file is loaded.

Recomputing the whole definition or manually reconnecting solves it… as said.

5

Internalized, but as in the .gif, not really useful. Internalized data works fine.
conversion
conversion bug 2.gh (7.8 KB)

Code used here:

  private void RunScript(string txt, ref object R)
  {
    if(txt.Contains(",")){
      txt.Replace(',', '.');
    }
    if(txt.Contains(".")){
      R = Convert.ToDouble(txt);
    }else{
      R = txt;
    }
  }

Seems really like the dots have some sort of problem after the .xls reader compile the first time.
… but the unicode of the dot seems correct…

6

There is a possibility that a plugin (re-)sets the localization to your computers default during initialization. After recomputation the invariant localization is set again. So this could explain, the behavior during first execution. Usually non-American developers are more aware of this problem, that is why I doubt its coming from Grasshopper. You could try to disable as much plugins as possible and see if this solved it. Have your written the Excel deserializer?

2 Likes
7

Omg, yes! I was going crazy!

It is the same thing I were searching about now!
I didn’t know that.

I’m using OfficeOpenXml library, from EPPlusFree.dll and I wrote my c# script to load my .xls.

Yes, during the first run of the script (while it compile) I see numbers having decimals with commas, but just after that it switch back to normality.

Thank you!

I know where to search now…