Numerical separator for SetSliderValue causes strange behavior

Grasshopper Developer
1

Hello,

I’m getting some very strange behavior in Grasshopper using SetSliderValue(val) on systems that use , as a numerical seperator (for example, German Windows).

Setting the slider in this way will result in a output value that is separated by , instead of . ,which can break some definitions. Manually recalculating the definition will set the separator of the output back to ..

This is strange because I use decimal as a the type of input for the slider.
I’m parsing the input values from string to decimal, so maybe that’s the problem.
On the other hand, decimal should always be decimal, right?
(I’m using decimal.TryParse)

I guess I could get around this problem by setting tick values instead.
I’m just wondering if anybody has an idea what’s going on.

Thanks,
Thomas

2

What exact code are you using to set the sliders?

3 
  slider.Slider.RaiseEvents = false;
  slider.SetSliderValue(val);
  slider.ExpireSolution(false);
  slider.Slider.RaiseEvents = true;

and eventually

_doc.NewSolution(true);

4

You should set number format to invariant culture before using TryParse and other related functions.

For instance:

and

5

Like @nathanletwory said, points vs. commas is a Culture specific thing. Grasshopper sets the culture of the current thread to CultureInfo.InvariantCulture, but it’s always possible to set it to something else. The problem with culture specific number formatting is that thousand-separators and decimal-symbols are often mirror images. That means that if you get a string in the form of 5.978,54 it could be either interpreted as nearly six assuming points as decimal symbols or nearly six-thousand assuming commas as decimal symbols. So a simple ‘replace-all-commas-with-points’ approach doesn’t work as a quick-fix.

The code you posted though doesn’t involve any culture specific stuff, that’s all digital numbers (doubles, and decimals etc.) and they are mercifully culture agnostic. It’s only the formatting and parsing that’s affected. So the question is whether any other code is messing with thread-culture settings.

6

Incidentally, if you’re calling or running code that you suspect changes the culture context of the Thread it’s on, you can always call Grasshopper.Instances.EnforceInvariantCulture() to set it back to invariant.

7

Thanks @nathanletwory and @DavidRutten, for putting me on the right track.
I have a parallel thread, and setting it to invariant culture solved the problem.
(I was doing invariant parsing already, but the issue had to do with the thread as whole.)

Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.InvariantCulture;

1 Like
8

Awesome.