Re: [Microba-controls] commitEdit of a null Date value
Brought to you by:
michaelbaranov
Menu
▾
▴
Re: [Microba-controls] commitEdit of a null Date value
|
From: Chris M. <ch...@st...> - 2007-10-20 21:01:30
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <br> For the change to not be backed out as soon as you focus away from the JFormattedTextField, you need to not only set the value to null, but also commitEdit() on it. The unit test I was using is quite Strandz (<a class="moz-txt-link-abbreviated" href="http://www.strandz.org">www.strandz.org</a>) orientated. If I was going to write a simple unit test to prove this behaviour I would:<br> <br> 1./ set JFormattedTextField to a valid value<br> 2./ commitEdit that value<br> 3./ set to null as you have done below<br> 4./ focus on another field<br> 5./ notice that the JFormattedTextField's value has gone back to the value set at 1<br> <br> - Chris <br> <br> Michael Baranov wrote: <blockquote cite="mid:471...@gm..." type="cite"> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <tt>Chris,</tt><br> <br> I just have checked the behavior of DatePicker with a quick snippet and I am able to set null date to it programmatically just OK out of the box! Can you please double-check it and send me a quick snippet to illustrate the failure (I'm confused with your description right now)? Here is my snippet to start with:<br> <br> <br> import java.awt.FlowLayout;<br> import java.awt.event.ActionEvent;<br> import java.awt.event.ActionListener;<br> import java.beans.PropertyVetoException;<br> <br> import javax.swing.JButton;<br> import javax.swing.JFrame;<br> <br> import com.michaelbaranov.microba.calendar.DatePicker;<br> <br> public class Snippet {<br> <br> public static void main(String[] args) {<br> JFrame frame = new JFrame();<br> frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);<br> frame.setLayout(new FlowLayout());<br> <br> final DatePicker picker = new DatePicker();<br> picker.addActionListener(new ActionListener() {<br> public void actionPerformed(ActionEvent e) {<br> System.out.println(picker.getDate());<br> }<br> });<br> <br> JButton btn = new JButton("NULL");<br> btn.addActionListener(new ActionListener() {<br> public void actionPerformed(ActionEvent e) {<br> try {<br> picker.setDate(null);<br> } catch (PropertyVetoException e1) {<br> System.out.println("Could not set null date.");<br> e1.printStackTrace();<br> }<br> }<br> });<br> frame.add(picker);<br> frame.add(btn);<br> frame.setSize(640, 480);<br> frame.setVisible(true);<br> }<br> }<br> <br> <br> Cheers!<br> <br> Chris Murphy wrote: <blockquote cite="mid:471...@st..." type="cite"> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <br> Hi Michael,<br> <br> Michael Baranov wrote: <blockquote cite="mid:471...@gm..." type="cite"> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> Chris,<br> <br> Thanks for digging in! <br> One more question before we go on: DateFormat vs. DateFormatter. You're using DateFormatter and even suggest to update the API for it. But what's the purpose? What's the difference? Can't you do the same null/empty check with DateFormat? DateFormat is in the API already.<br> <br> </blockquote> Maybe you can! But then I would have thought Sun's workaround would be on DateFormat if that was the case. To tell you the truth I don't really want to become a DatePicker/JFormattedText/DateFormatter/DateFormat expert right now; I just want to use it.<br> <blockquote cite="mid:471...@gm..." type="cite">About the deep-buried UI: it was the initial idea to hide the implementation, the fact that DatePicker is really composed of a text edit and a button. Maybe it's a good idea to expose the parts from their UI delegates and make them accessible like this:<br> ( (DatePickerUI)picker.getUI() ).getButton()<br> // etc...<br> Is this what you mean?<br> </blockquote> Yes. You could do worse than take a look at the source of <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://web.ukonline.co.uk/mseries/">http://web.ukonline.co.uk/mseries/</a> and borrow some of the good ideas there from there - if there are any. I've never created a composite component with its own UI.<br> <blockquote cite="mid:471...@gm..." type="cite"><br> Chris, please get the latest sources from sourceforge. If you can't make a patch for me, plz send me back the modified sources.<br> </blockquote> I'm pretty sure I got the latest source. Am attaching the source file I'm using currently. <br> <br> I have it on my list of things to do to compare MDateEntryField with DatePicker a bit more. Things I will look at are focusing and validation and also how well they work when they are XMLEncoded. Will get back to you then ...<br> <br> - Chris<br> <blockquote cite="mid:471...@gm..." type="cite"><br> Cheers!<br> Michael.<br> <blockquote cite="mid:471...@st..." type="cite"> <pre wrap="">Hi Michael, Send me your latest source file for BasicDatePickerUI and I'll do a patch if you like (have never done such a thing before); however all that needs to be done is to use this new inner class NullCapableDateFormatter instead of DateFormatter as your code has it. I have since made the new inner class private and static as well - but haven't really tested it. Apart from that all the necessary code is as sent. Alternatively you could change the code so that API users can put in their own DateFormatter. One small problem with this I see is that your UIs seem to be hard to get to - there is no reference to them from the controller as I would expect. I have had to code this method: public static Component getDisplay( DatePicker dp) { Component result; Component components[] = dp.getComponents(); //Print.prArray( components, "Which one is a text field?"); //A: //value: null, class: com.michaelbaranov.microba.calendar.ui.basic.BasicDatePickerUI$MyJFormattedTextField //value: null, class: javax.swing.JButton result = components[0]; return result; } Is there a better way? I experienced the problem when programmatically setting the date to null. What would happen was that a null wouldn't get through the commitEdit() validation (which presumably happened at the time of a focus change), and the last successfully committed value would come back to being the actual value. This was a difficult thing to track down, and indeed also exists on MDateEntryField, and was the reason that I came to your Component - hoping it would allow null date values. - Chris Murphy (<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.strandz.org">www.strandz.org</a>) Michael Baranov wrote: </pre> <blockquote type="cite"> <pre wrap="">Chris, Thanks for the path! But can you describe the effect of the change from the point of view of a user? What was wrong (but now OK)? Can you please send me a regular machine-processable patch for BasicDatePicketUI against the latest sources (so I ca patch a local copy free of mistakes)? Thanks for using Microba and contributing! Chris Murphy wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi Michael, I found something for your consideration, which has required changing the microba source as configuration was not possible. The problem is that JFormattedTextField does not properly support the concept of a null date. A null date can't be committed (commitEdit()) to a JFormattedTextField. As you can see from the code Sun's bug database offers a workaround that I've implemented on your code. This code is from changes I've made to BasicDatePickerUI: private DefaultFormatterFactory createFormatterFactory() { return new DefaultFormatterFactory(new NullCapableDateFormatter(peer .getDateFormat())); } /** * To do this enhancement: * <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4745048">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4745048</a> */ public class NullCapableDateFormatter extends DateFormatter { public NullCapableDateFormatter(DateFormat dateFormat) { super( dateFormat); } public Object stringToValue(String string) throws ParseException { if(string == null || string.length() == 0) { return null; } return super.stringToValue(string); } } thanks - Chris ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://get.splunk.com/">http://get.splunk.com/</a> _______________________________________________ Microba-controls mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Mic...@li...">Mic...@li...</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/microba-controls">https://lists.sourceforge.net/lists/listinfo/microba-controls</a> </pre> </blockquote> </blockquote> <pre wrap=""><!----> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://get.splunk.com/">http://get.splunk.com/</a> _______________________________________________ Microba-controls mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Mic...@li...">Mic...@li...</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/microba-controls">https://lists.sourceforge.net/lists/listinfo/microba-controls</a> </pre> </blockquote> </blockquote> </blockquote> <br> <pre class="moz-signature" cols="42">-- Michael Baranov </pre> </blockquote> </body> </html> |
