Opened 10 years ago

Closed 10 years ago

#878 closed defect (fixed)

Regression: Common Expression Engine cannot understand scientific notation when the coefficient is a decimal

Reported by: christinebao Owned by: david.ji@…
Priority: major Milestone: 3.8.0
Component: FDO API Version: 3.8.0
Severity: 3 Keywords:
Cc: External ID: DE6337

Description

Reported by Autodesk QA:

Steps:

  1. Install Deutsch Map3D L014AK
  2. Create an SHP FDO connection to connect the attached file region.shp
  3. Add to Map with Query
Area( Geometry ) > 1.5e+11

Result:

All the 34 features(check it in data table) are added to map, the filter doesn't work.

It works fine if the query are:

Area( Geometry ) > 2e+11
Area( Geometry ) > 150000000000

Attachments (1)

Fix878.patch (625 bytes ) - added by christinebao 10 years ago.

Download all attachments as: .zip

Change History (3)

by christinebao, 10 years ago

Attachment: Fix878.patch added

comment:1 by christinebao, 10 years ago

In German version, the filter like “Area2D(geometry) > 1.5e+11” doesn’t work.

The reason is that, in FdoLex::getnumber, it always set ‘.’ as the decimal point. And later, it invokes _wtof to convert the string to double value. Actually, _wtof internally invokes _wtof_l with a null locale, and _wtof_l will use the current or default locale to convert the string if the input locale is null. In English locale, the decimal point is ‘.’, but in German or some other locales, the decimal point might be ‘,’ or some other characters, this leads to the incorrect convert from a string to a double value. E.g. “1.5e+11” will be converted to 1.0 in German locale.

So the fix is quite straight forward, get the current locale and the decimal point from the system API localeconv, and set the decimal point into the string which will be converted to a double value.

comment:2 by christinebao, 10 years ago

Resolution: fixed
Status: newclosed

Submit on rev 7000.

Note: See TracTickets for help on using tickets.