Wt

Hey Christophe,

But what's the point of using a spinbox to input a number that is more precise than what is shown?

Is that not entirely unintuitive to the user?

I would expect spinboxes to be used for integer numbers, of 'perfect fractions', like 1.0, 1.1, 1.2, etc... ?

Regards,

koen

You are right.

However i have 3 suggestions to improve the SpinBox :

1 - It would be better if the arrows were outside the line edit. It would avoid the numbers to hide them in some cases.

2 - Currently to enter spin mode, the user has to click between the 2 arrows (very small area). It would be much easier if the spin mode could be entered with a mouse click down on one of the arrows and vertical drag.

3 - the text formatting should avoid the display of remaining zeros after the last significant digit. For instance, if we want a precision of 3 digits after the decimal point, then 1.3 would be displayed as 1.3 and not 1.300. I can see in the code that you already tried to do this for integers.

Regards

Christophe

Hey Christophe,

1) That would be better, but, that is not consistent with how the HTML5 native implementations do it (I just noticed that chrome does it, so we will add support for this). The fact that the numbers overlap the buttons can and will be solved with some right-padding

2) Good suggestion, we will add it.

3) In that case, the current behaviour of lexical_caststd::string() is what you want, at least when current value is a 'perfect fraction' ? If a user himself enters 1.3002, then I do not see why you would want to correct the display of that to 1.300 ?

Regards,

koen

Hi Koen,

1) and 2) do you plan to do this soon ? i ask because i would rather wait for the latest revision before adding the new wt version to our clearcase repository

3) if the spinbox is setup to only display 3 digits after the decimal point, then if a user enters 1.3002, the display must correct the input and show 1.3 (or 1.300). The user then realizes that only 3 digits are supported (Maya works like that). That is why lexical_cast cannot be used. Shouldn't setValue and value() be consistent ? If you call setValue(1.3002) then 1.3 or 1.300 will be displayed because of the text formatting option. But value() will return 1.3. It does not make sense.

Regards

Christophe

Hey Christophe,

Since 1 and 2 are not connected to the complex format discussion, yes, we will implement that soon (say within a week).

I am still not confident we found a good solution to the formatting problem.

I can see the argument for correcting user input. Let me think about it. W.r.t. setValue() and value(): If you set an illegal value (1.3002 is not valid for the user, it should not be valid for the API either), then you should not expect the same value back? For valid values, the API should be consistent.

Regards,

koen