We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Decimal formatting / Culture- how to migrate existing templates

Hi, I am migrating from 9.1 to the current version. For decimal values (prices, wages etc) I have always used { MERGEFIELD price \# 0.00 \* MERGEFORMAT }. This results in 10,15 for example, my (mostly dutch) users need a komma as the decimal separator.

In the new version, this mergeformat does not work correctly, because (as I have learned from this forum) the current locale is now used, instead of the invariant locale. So the merge format should be "/# 0,00" i guess. (or can I leave it blank? This seems to work also now.) .

The problem is that there a many hundreds of documents at my clients which use the old code.

What would be the best way to deal with this:

a. loop through all documents and change the formatting from "0.00" to "0,00"

b. implement some FieldMergingCallback class to deal with the 'old' format.

What would you reccommend? And could you point me to some example code for your solution?

Thanks Ed

Hi Ed,

Thanks for your request. I checked on my side and your picture switch works fine on my side. So, could you please create a sample template and code that will allow me to reproduce the problem? I will check the issue and provide you more information.

Best regards,

Here is a sample. The file wrong_result.doc shows the differences I get on my machine (dutch).

In my main app the formatting is even different, there the values are shown as three numbers.

Hi

Thank you for reporting this problem to us. I managed to reproduce it on my side. Your request has been linked to the appropriate issue. You will be notified as soon as it is resolved.

Best regards,

Ok, thanks. It of course would be great if these formatting codes, that have been used since 2006, can stay the way they are.

If you happen to know a temp workaround, I would be interested as well, then I can proceed with the current version instead of going back to the old version.

Bye, Ed

Hi Ed,

Thanks for your inquiry. As a temporary workaround, you can try using the following code:

CultureInfo currentCulture = Thread.CurrentThread.CurrentCulture;

CultureInfo myCulture = (CultureInfo)CultureInfo.InvariantCulture.Clone();

myCulture.NumberFormat.NumberDecimalSeparator = ",";

Thread.CurrentThread.CurrentCulture = myCulture;

DataSet ds = new DataSet();

ds.ReadXml(@"Test001\ds.xml");

Document doc = new Document(@"Test001\layout.doc");

doc.MailMerge.Execute(ds.Tables[0]);

doc.Save(@"Test001\out.doc");

Thread.CurrentThread.CurrentCulture = currentCulture;

Hope this helps.

Best regards,

Hi, thanks very much, this solves it for now, also in the production apps.

Bye, Ed

Hi, I have to come back on this, since the behaviour seems to have changed in the latest versions.


The above solution worked fine before. But in the recent versions a dot is used as the decimal sign.
So I get 123.50 instead of the desired 123,50.

It looks like the abose setting of the separator in the invariant culture is ignored. I still need the workaround though. Would you know a fix, so I can keep using the recent version?

Thanks,

Ed
Hi,

Thanks for your inquiry.

Unfortunately, WORDSNET-4662 is not resolved yet. I have verified the status of this issue from our issue tracking system and regret to share with you that this issue has been postponed till a later date (no reliable ETA is available). We will be sure to inform you of any developments and let you know once it is resolved. We apologize for any inconvenience.

Best regards,

Hello,


Any news on this? I’m still on version 11.6 because of this.

Regards, Ed

Hi Ed,


Thanks for being patient. I am afraid, this issue is not resolved yet and there is no further news about this issue. We have asked the ETA of this issue from our development team. As soon as any information is shared by them, we will gladly share that with you. We apologize for your inconvenience.

Best regards,

The issues you have found earlier (filed as WORDSNET-4662) have been fixed in this .NET update and this Java update.


This message was posted using Notification2Forum from Downloads module by aspose.notifier.