Hi,
Hi,
Thanks for your posting and requesting new features.
We will look into them and implement it and update you asap.
This issue has been logged as CELLSJAVA-40037.
Hi,
We have supported LoadOptions.setLocale(Locale) for your requirement. Please try the new fix v7.0.3.1 (attached). But for the “DecimalSeparator” and “ThousandSeparator”, we think it should be determined by the given locale, just like MS Excel does when loading a CSV file. If you really need to specify one Locale and different separators of another locale when loading CSV files, we will look into this requirement later on to check whether we can support it because it will conflict with other logic of parsing numeric values.
Thank you.
Hi,
Hi,
Thanks for your comment/feedback. I have logged it in our database. We will update you asap.
Hi,
Can it fit your requirement if we let you set the specified Format object when reading CSV file? The API may like:
C#
TxtLoadOptions.setValueParser(java.text.Format[][] formats, java.lang.String[][] customs)
For the parameter ”formats”, formats[0] is all possible Format objects will be used to try to parse values of the first column in CSV template file, formats[1] is all possible Format objects will be used for the second column, ...etc. The last one(formats[formats.length-1]) will be used for corresponding and all following columns. “customs” is the custom string used for formatting the cell(Style.setCustom()) corresponding with “formats”.
To parse number with different separators, code like following:
C#
s.setDecimalSeparator(',');
TxtLoadOptions.setValueParser(new java.text.Format[][]{{ new DecimalFormat("##.###", s),},}, new java.lang.String[][]{{“##.###", },});
Hi,
s.setDecimalSeparator(’,’);
TxtLoadOptions.setValueParser(new java.text.Format[][]{{ new DecimalFormat("##.###", s)}}, new java.lang.String[][]{{“##.###"}});
Hi,
In fact the given java.text.Format objects are only the preferred parsers for parsing values in CSV file. We will try to use those user specified parsers to parse value at first, if one parser is matched, then we will use the parsed value and corresponding formatting string for that cell. If all those parsers failed, we will continue to use existing logic of parsing values, just like what will be done by current version when reading a CSV file. For a common string value, it will be kept as string value for corresponding cell, without failure or value lost.
Thanks for your understanding!
Thanks, then this sounds like a great solution!
Please try the new fix. Aspose.Cells for Java v7.0.3.2
We have added some new APIs for user custom parsers (a bit different from what we have discussed but more flexible):
This interface allows users to add their custom value parser for parsing string values to other proper cell value object. Its methods:
public void setPreferredParsers(com.aspose.cells.ICustomParser[] parsers)
class MyParser0 implements ICustomParser
Thank you very much, this looks really cool!
The issues you have found earlier (filed as CELLSJAVA-40037;CELLSJAVA-40037) have been fixed in this update.
This message was posted using Notification2Forum from Downloads module by aspose.notifier.