David Garratt

Just found this which looks interesting

http://commons.apache.org/proper/commons-beanutils/apidocs/org/apache/commons/beanutils/locale/converters/BigDecimalLocaleConverter.html

From my tests it seems that the conversion back from a string / text field to a bigdecimal is assuming that the number is formatted in us/en even when it's not and hence the swapped comma and dot which is being used correctly on screen results in the value of my decimal being wrong.

My above fix it a temporary measure to help overcome a inconsistent data problem for now but will need more work.

Dave

What I have done for a quick global fix is to use Locale.setdefault to ensure that I have a consistent us/en format throughout the application - at least until I have a better solution.

To clarify using pseudo code

Decimal myval = 12345.678

Jtextfield mytextfield.settext(myval.toString)

On screen displayed as 12.345,678 due to regional settings

Decimal exitVal = new Decimal (mytextfield.gettext());

Actual value of exitVal is now 12.345

If I swap out text field for formatted text field are you suggesting that I set the display format to us format even if the users normally used to seeing Hungarian for example ?

Sorry for rough and ready pseudo code - been awake in hospital ward all night.

I'm not entirely sure but if I read the description correctly don't you have to specify the required display/edit format rather than just default to the regional settings. Then I'm not sure if I would be any better determining the value of it.

Sorry if I've misread it.

Dave

I have my application running on a site a different users have different regional settings for Windows so that when a value is calculated (mostly as a decimal) and then assigned to a jtextfield it respects the windows formatting format so I might see

4,567.000
Or
4.567,000

That's fine. However when convert the string (text) back from the field for storage in the database I get

4.567 instead of 4567.00 as the dot is being interpreted as a decimal place and not a thousand separator.

Sorry for lack of source code at this point as I'm in a hospital bed typing on my mobile.

Assuming I have a set and get method to get a decimal from a database and I want to both set and read the jtextfield.gettext() in a manner which can understand the context of comma and dot according to regional settings - how should I be doing this ?

I have a lot of swing code to update to fix this so if there was a way to use a replacement to jtextfield which could handle this it would be perfect - I realise that the jtextfield may not be at fault but if I could replace it with a class that would return a consistent formatted string that would always be represented as n,nnn.nnn it would make life just a little simpler.

Many thanks

Dave

That worked for me - many thanks.

Dave

I am reading a file line by line and splitting it up into multiple files. The output files are xml files but because I'm inadvertently including a BOM Byte Order Mark in my output files I'm getting an error in another application which is trying to load them.

I have found many many links to methods to remove the BOM from existing files or a workaround for reading them. However I'm trying to avoid the problem by finding an alternative way to create the output files in the first place.

I'm developing on a Mac and the program will eventually run on Windows machine. I've tried changing the character set in the code to UTF-8, UTF-16BE and even ASCII. Not sure if I should try writing bytes instead.

import java.io.BufferedReader; import java.io.File; import java.io.FileReader; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; import java.nio.file.StandardOpenOption; public class ExtractXml1 { public boolean splitXML(String inputFile,String outputPath) { File xmlFile = new File(inputFile); boolean writing = false; boolean result = false; Path path; String outputFilename = ""; if (xmlFile.exists()) { try (BufferedReader br = new BufferedReader(new FileReader(xmlFile))) { String line = ""; while ((line = br.readLine()) != null) { System.out.println(line); if (line.startsWith("<!--*START* filename ")) { outputFilename = line.substring(21, line.length() - 3); line="<?xml version=\"1.0\" encoding=\"UTF-8\"?>"; writing = true; } if (line.startsWith("<!--*END* filename")) { writing = false; } if (writing) { path = Paths.get(outputPath + outputFilename); Files.write(path, (line + "\n").getBytes("ASCII"),StandardOpenOption.CREATE,StandardOpenOption.APPEND); } } result=true; } catch (Exception ex) { result=false; } } return result; } public static void main(String[] args) { ExtractXml1 ex = new ExtractXml1(); ex.splitXML("./interface/input/Material_Output.xml", "./interface/output/"); ex.splitXML("./interface/input/Order_Output.xml", "./interface/output/"); System.exit(0); } }

AH - forget this question - I see now I made a silly mistake elsewhere in my code.

Forgot my example - this is the constructor for BBBB - appInit does the GUI layout.

public JInternalFramePalletAdmin(String keyField,String keyValue) { super(); app_Init(); clearFilter(); if (keyField.equals("MATERIAL")) { jTextFieldMaterial.setText(keyValue); } if (keyField.equals("PROCESS_ORDER")) { jTextFieldProcessOrder.setText(keyValue); }      EventQueue.invokeLater(new Runnable() {            @Override            public void run() {         buildSQL();         populateList();            }        }); }

Appologies in advance for not having some real code to look at but hopefully my pseudo code will be enough to illustrate what the problem is.

I  have a MDI application and in this particular scenario a JInternalFrame called AAAA creates an instance of another JInternalFrame called BBBB.

In the constructor for BBBB all the Swing layout and controls are drawn and only when the screen is complete does it execute a rather lengthy SQL SELECT to populate a JTable.

The problem I have is that because Swing is doing its screen painting in its own thread it does not have time to draw the BBBB frame before the SQL SELECT fires up and consumes all the spare CPU cycles.

This means that the BBBB frame simply does not appear at all until the query has completed.

I have tried inserting some delays / pauses at strategic points without luck.

Is there something I can put in the constructor of BBBB after the screen has been defined, but before the SQL is executed which will force Java to paint the screen..

Thanks in advance.

Dave

This answer may not exactly be what your expecting but I have done what you are trying to do using a different approach. The servlet put the name of the jasperreport and its paramaters in a table and thats all. A separate program running on a server polls the table and when it sees a request for a report it runs it. The table also holds the name of the print queue.

This has the advantage that the servlet is not burdened with the processing time it takes to generate a report and it's easier to debug the report on a foreground application

Forgot link http://www.commander4j.com

I'm sure the purist's will cringe but I've done all of this using WindowBuilder Pro and the absolute Layout. I found that using Metal look and feel eliminates most of the operating system specific quirks and saves me a lot of time. I don't really have a problem with the Java Layout managers as much as I do for the tendancy these days by the newer maven command line / xml driven frameworks to do everything from command line. For me the tweak/compile/test cycle would drive me nuts. (well - more so - at least.)

This is my project and the gallery page shows a few of the screens. it's all MDI

Dave