bug in Imagebox.RequestedImageSize?

   
When setting the RequestedImageSize of a dicom print imagebox, then you have to pass a double to this property.
If the Decimal Separator is setted to ',' (komma) in the local country settings, then leadtools convert this value to a decimal string with a ',' in it in stead of a '.' (point) which is the dicom standard. Therefore the size is not accepted by dicom printers.

Can this be altered and if so where can i do this without changing the country settings.

Unfortunately, there is nothing LEADTOOLS can do in regards to this problem.  This is because the RequestedImageSize returns a System.Double which is Microsoft's object.  When converting this Double to a string, Microsoft is doing this, not LEADTOOLS.  Therefore you are going to have to change the regional settings either permanently for the user of the computer or temporarily within your code.  Here's a couple links that might be useful:

http://www.thescripts.com/forum/thread567436.html
http://msdn2.microsoft.com/en-us/library/system.globalization.cultureinfo(VS.80).aspx
http://msdn2.microsoft.com/en-us/library/system.globalization.numberformatinfo(VS.80).aspx

I believe the actual property you'll need to change is the NumberFormatInto.NumberDecimalSeparator

Can't you parse the string after the conversion to replace the local decimal separator to a '.' ?
Now you pass the double to the microsoft object and you are getting back a string with an invalid separator (according to dicom standard).

Is it not desired that this works on every system locale?
Changing the global separator gave problems in other programs that are only designed to work with a specific decimal separator.

Yes, you can parse the string as well and raplace the ',' with '.' if that is your preferred method.  Unfortunately, there just isn't anything in LEADTOOLS that will make sure that your string representation of the RequestedImageSize always has the '.' because it's a Microsoft object.

Of course we would like it to work at every locale, which is exactly what we are doing.  If the globalization settings say that the double should use a ',' rather than a '.' then I would say it is working properly.  If anything is not working globally it's the dicom printers you are using since they will only accept a '.' for the decimal separator.  I apologize for the inconvenience, but parsing the string or changing the globalization settings are the only way I know of that you'd be able to guarantee that the string representation of your double will work with the printer you are using.