Hi Marc, > No, in fact it is the other way round: I need to convert displayed > number strings to real (database ready) numbers for creating SQL > statement strings. The number formatter is only one way in converting > un-localized strings into localized ones. > > I really think there should be a service for de-localizing values. A > perfect place for this would be an optional method or a set thereof at > the number formatters of the DataSource (and maybe the Connection).
Forgive me, but I don't think I completely grasp your scenario .... Originally you wanted to convert the number into a string, now vice versa. Do you get the values from a Calc cell, then why can't you use it's (already mentioned by you) getDouble (or so) method and let it do the de-localization for you? There *is* a service for de-localizing strings: the number formatter. Use the locale in question (see below) and a standard numeric format (always format key 0, IIRC, else obtainable via getStandardFormat), and let the formatter convert your string to a double. The locale might or might not be the Office's UI locale, but this depends on where you got the number/string from. I'm not sure about Calc cells, if their getString in fact retrieves the string formatted with the UI locale, then this is (should be) probably documented at the service. If not from a Calc cell, where else do you obtain localized string representations of numeric values? > Something else deeply needed (at least by me, as always ;) would be a > database compatible way of asking a SpreadsheetCell for it's value > contents. Having such a thing would make a lot of conversions > unnecessary (dunno if this is for the dba or sc project). Probably for DBA (and a separate thread :). If you elaborate what you mean with "database compatible" (and be it for the records and for reasons of reproducibility), then this could justify an RFE. > Concluding one could say the way from the document or GUI back to the > database should get into the view of responsible API designers. ;) Like a few other "Problem X cannot be solved easily in DBA's API" issues ... Let me suggest you create a Wiki (wiki.services.openoffice.org) page called DBA API issues, and describe your scenario in detail. We could add other DBA-API-insufficencies over time there ... Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
