[TYPO3-core] RFC #5595: Bug: Fix in evalFunc_parseDouble() in t3lib/jsfunc.evalfield.js

["Sylvère \"Siller\" Störmann"]

Martin Kutschker wrote:
> Ernesto Baschny [cron IT] schrieb:
>> Sylvère "Siller" Störmann wrote: on 01.07.2008 16:11:
>>
>>>> Looks good, but missing the part that saves the form (TCEmain).
>>>> Please also modify t3lib/class.t3lib_tcemain.php accordingly
>>>> (function checkValue_input_Eval), because there also the "intval()"
>>>> php function is used on the integer part of the splitted value,
>>>> causing the same effect.
>>> thanks, I completely had forgotten about that part. ;)
>>>> So the JS on the client is ok, as soon as you send it to the server,
>>>> TYPO3 will strip the "-" again.
>>> Additional patches for class.t3lib_tcemain.php attached. Now it works
>>> on the server side as well.
>> This addition wasn't clear to me:
>>
>>                      $value = intval(str_replace('
>> ','',$value)).'.'.substr($theDec,0,2);
>> +                    $value = ($value * 100 ? $neg.$value : $value);
>>
>> As far as I see, $neg is either "" or "-" at this point. Wouldn't it be
>> enough simply to prefix $neg to $value? $value is already has the "-"
>> stripped off by your patch.
> 
> And why check if $value multiplied with hundred yields true. Or is this
> what you're pointing out?
> 
> Masi

Sorry for the late reply (been quite busy).

The logic of this is for the unique case where a user enters "-0" as value
--> $value = "0.00", $neg = '-'
--> $value * 100 yields false
--> return value is set to "0.00" ($value, instead of $neg.$value)

If there wasn't the unary operator, the result would yield "-0.00" 
(which isn't mathematically correct).
If we can assume that "-0.00" is correctly inserted as "0.00" by the 
DBAL, then it really is unnecessary.

Siller.