Path: csiph.com!feeder.erje.net!2.eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!news-1.dfn.de!news.dfn.de!cache.uni-koblenz.de!not-for-mail From: Tassilo Horn Newsgroups: comp.lang.java.programmer Subject: Re: JavaFX: Bindings, StringConverters, and ChangeListeners Date: Thu, 23 Jun 2016 08:39:51 +0200 Organization: University Koblenz-Landau Campus Koblenz Lines: 44 Message-ID: <877fdgl87c.fsf@gnu.org> References: <87wplhbbvy.fsf@gnu.org> NNTP-Posting-Host: j289989.servers.jiffybox.net Mime-Version: 1.0 Content-Type: text/plain X-Trace: cache.uni-koblenz.de 1466663991 15634 134.119.24.195 (23 Jun 2016 06:39:51 GMT) X-Complaints-To: news@cache.uni-koblenz.de NNTP-Posting-Date: Thu, 23 Jun 2016 06:39:51 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:fjGVf0x3cC//uDurm9GDn83Akr4= Xref: csiph.com comp.lang.java.programmer:34693 Nigel Wade writes: Hi Nigel, > The first thing I'd suggest is to think about the problem from the > user's perspective rather than the programmer's. > > If I, as a user, enter a number into a text field and inadvertently > enter an invalid character, I'd be rather annoyed if the GUI element > wiped out what I'd entered and replaced it with something which I > didn't want. It would be better from my (user) perspective if the > text element warned me of my transgression (flash, highlight, red > background whatever) and left my text there for me to edit, rather > than make me enter it again with the likelihood of making a similar > mistake again. Oh, flashing is actually a nice idea and can be done pretty easily from my listener. > Imagine if the current contents were 002324561234, and I wanted to > change it to 002324560234 but instead changed it to 00232456O234. Your > current method would revert it back to 002324561234, and I may never > notice that my change had been overridden. Well, in the concrete case the number is the maximum number of matches to be looked for in a database, so the numbers aren't that hard to distinguish but I got your point. > What's wrong with parsing the entered text and, if there is an > exception, catch it and display some feedback, leaving the focus on > the text field? If you really, really want to set the text back to the > original value you could still do that in the catch block. I don't see > any benefit from using a ChangeListener. The problem is that I have no control over when and where the string in the text field is parsed and converted to a number. I just specified a declarative binding between the text field's text property and an integer property with a standart converter and thereby gave up exact control over these things. But bindings are such an integral part of FX that I guessed there must be some standart way to treat invalid input so that the binding's converter doesn't err. Bye, Tassilo