Re: ObservableValue Stacktrace
JavaFX should not fail in these cases, but doesn't consider that a valid
state, so it always prints a warning on the stderr, for the developer to
see something went wrong.
Regards,
-Martin
On 5.6.2013 21:38, John Hendrikx wrote:
Hi List,
I'm getting some log messages sometimes (see at the end) about
properties being null (whereas I didn't get them before in JavaFX 2.2).
Is this intended as an informative message to the developer, something
I should report, or just debug code for the JavaFX team?
In this case, the binding is null, and that's fine -- it will be
populated later, but the binding is already in place -- I thought
JavaFX was designed to allow nulls in a chain of bindings and
fall back to reasonable defaults for things like Strings, numbers
etc? Am I doing something wrong?
Code:
{
private final ObjectPropertyMedia data = new
SimpleObjectProperty();
public ObjectPropertyMedia dataProperty() { return data; }
protected final ObjectBindingObservableListCasting castings =
Bindings.select(dataProperty(), castings);
}
Log:
Jun 05, 2013 9:15:55 PM
com.sun.javafx.binding.SelectBinding$SelectBindingHelper
getObservableValue
WARNING: Exception while evaluating select-binding [castings]
Jun 05, 2013 9:15:55 PM
com.sun.javafx.binding.SelectBinding$SelectBindingHelper
getObservableValue
WARNING: Property 'castings' in ObjectProperty [bound, value: null] is
null
java.lang.NullPointerException
at
com.sun.javafx.binding.SelectBinding$SelectBindingHelper.getObservableValue(SelectBinding.java:481)
at
com.sun.javafx.binding.SelectBinding$AsObject.computeValue(SelectBinding.java:92)
at javafx.beans.binding.ObjectBinding.get(ObjectBinding.java:152)
at
javafx.beans.binding.ObjectExpression.getValue(ObjectExpression.java:49)
at
com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:53)
at
javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:71)
at
javafx.beans.property.ObjectPropertyBase.bind(ObjectPropertyBase.java:170)
at
hs.mediasystem.TitledBlockSample.createCastingsRow(TitledBlockSample.java:114)
at hs.mediasystem.TitledBlockSample.start(TitledBlockSample.java:78)
at
com.sun.javafx.application.LauncherImpl$5.run(LauncherImpl.java:810)
at
com.sun.javafx.application.PlatformImpl$6.run(PlatformImpl.java:260)
at
com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:226)
at
com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:223)
at java.security.AccessController.doPrivileged(Native Method)
at
com.sun.javafx.application.PlatformImpl$5.run(PlatformImpl.java:223)
at
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at
com.sun.glass.ui.win.WinApplication.access$300(WinApplication.java:39)
at
com.sun.glass.ui.win.WinApplication$3$1.run(WinApplication.java:101)
at java.lang.Thread.run(Thread.java:724)
Regards,
--John
hg: openjfx/8/graphics/rt: RT-28963: Mac: DragEvent.getScreenY() returns incorrect value on drag drop
Changeset: 7fc4181950e2 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-06-06 11:34 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7fc4181950e2 RT-28963: Mac: DragEvent.getScreenY() returns incorrect value on drag drop Reviewed-by: anthony ! glass/glass-lib-macosx/src/GlassViewDelegate.m
Re: Preloaders
On Wed, Jun 5, 2013 at 9:47 PM, Daniel Zwolenski zon...@gmail.com wrote: To sum up my previous major suggestions for a better world: - web deploy code should be separate module from native, and jar separate again. Each native module (win, Linux, Mac) should be separate and I should be able to invoke any and all of them how and when I want, not just one generateDeployment method as the only entry point. I think JNLP and web generation should be a bundler on the same level as win/mac/lin. No special treatment, it is just hte same as the rest - java code of packager should be one library for all platforms so we have one jar for all, not a separate one for each OS. Native bits are referenced from this one jar as needed. I actually disagree with this. Perhaps the default bundlers come in one jar for hte JDK, but I would like the ability to add bundlers external to the tool that evolve at different speeds than the core JDK. Tha was the point of my service loader patch. Making the bundlers separate for the JDK is a good exercise in proving severability. - native should not have dumb stuff from web as a requirement if not used. Signing, special jfx meta-inf in jars, checking registry for jdk, etc, etc. Native is actually very simple and really should be able to work with a stock standard jar and not need a special jfx built one. Web should be quarrantined so that native isn't sullied by it. Sullied is a bit of a harsh word. Deployment modes are different For example, a Mac App, iOS app, and Android APK all still need to be signed, their deployment models for signing are different. - no magic config in the core libraries (higher wrappers can try and add it on top). Eg It shouldn't look for wix and use it just because it's installed. I should be able to specify I want wix or inno and tools should fail if they are not there. I still think there is a role for the all packaging type that would do all the ones it has access to and work. However I wouldn't want to see it fail unless specifically called out. i.e. the WIX bundler would fail if 'wix' was in the packaging types, but not if 'all' was the packaging type that called it. This is really a per-bundler decision. That's just looking at improvements to what's already there. As far as my picks for new features, these would be my top: - app store support (desktop at this stage) - auto updating support for native bundles - cross platform builds on the one machine (ie build for Mac from a windows machine, etc). Also build a 32bit distro on a 64bit jdk, etc. Or build RasPi debs on a linux vm. - compact jre's for smaller distro sizes. THIS --Danno
hg: openjfx/8/graphics/rt: 4 new changesets
Changeset: c228567fe494 Author:Alexander Kouznetsov Date: 2013-06-06 00:59 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c228567fe494 FXMLExport: Updated to the latest version of TriangleMesh API. Fixed children doubling. ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/exporters/fxml/FXMLExporter.java Changeset: 443a9ce81b2c Author:Alexander Kouznetsov Date: 2013-06-06 01:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/443a9ce81b2c MayaImporter: Removed unnecessary handler from Timeline KeyFrames. ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/MayaImporter.java Changeset: 83751683c863 Author:Alexander Kouznetsov Date: 2013-06-06 01:02 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/83751683c863 3DViewer optimizer: clean up repeating points and texCoords. ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Optimizer.java Changeset: e91e20387c16 Author:Alexander Kouznetsov Date: 2013-06-06 01:03 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e91e20387c16 3DViewer: Fixed NPE in Timeline Controller ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineController.java
JFX Packager (was Re: Preloaders)
On Thu, Jun 6, 2013 at 5:52 PM, Danno Ferrin danno.fer...@shemnon.comwrote: On Wed, Jun 5, 2013 at 9:47 PM, Daniel Zwolenski zon...@gmail.com wrote: To sum up my previous major suggestions for a better world: - web deploy code should be separate module from native, and jar separate again. Each native module (win, Linux, Mac) should be separate and I should be able to invoke any and all of them how and when I want, not just one generateDeployment method as the only entry point. I think JNLP and web generation should be a bundler on the same level as win/mac/lin. No special treatment, it is just hte same as the rest Agreed, they are all the same level, but modularised at a code level so we can call generateJnlpBundle or generateWinExeBundle, generateWinMsiBundle. Currently there's this uber bundle going on that you can sort-of-if-you're-lucky turn some bits off. It's this uber bundling I'd like to see change in the future. Give me finer hook in points for the Maven plugin anyway. - java code of packager should be one library for all platforms so we have one jar for all, not a separate one for each OS. Native bits are referenced from this one jar as needed. I actually disagree with this. Perhaps the default bundlers come in one jar for hte JDK, but I would like the ability to add bundlers external to the tool that evolve at different speeds than the core JDK. Tha was the point of my service loader patch. Making the bundlers separate for the JDK is a good exercise in proving severability. Agree to being to add your own customisations by the core tools having plugin points. Also would love to see the packager tools not tied into the JDK and be on their own release cycle - this would be a massive win (wasn't a popular suggestion when I made it a while back). My point about one jar was more to do with the fact that currently the ant-javafx.jar at the moment is different in the Mac distro of the JDK to the Window version of the JDK, which is different again to a 32bit version of the ant-javafx.jar on a 32 bit windows JDK. 95% of the code is the same in all of these however there are slight differences to the Java code (or so I was told - by Ivan I think) and the native bits (winlauncher.exe for example) are included in the JAR (from memory). So effectively the ant-javafx.jar is platform specific. Messy to get all those platform specific JARs and put them in Maven (or whatever). You need to reference the right JAR for the platform you are on, even for doing, say a web build, which doesn't actually care. Also the native inter-twining makes it hard to build for testing and contributing, since I need to do the native builds, whereas if these were separate assets I could just mess with the Java code and use the native bits out of the repo. So when I say one jar maybe translate that to not platform specific JARs of stuff that doesn't need to be. - native should not have dumb stuff from web as a requirement if not used. Signing, special jfx meta-inf in jars, checking registry for jdk, etc, etc. Native is actually very simple and really should be able to work with a stock standard jar and not need a special jfx built one. Web should be quarrantined so that native isn't sullied by it. Sullied is a bit of a harsh word. I'm afraid I've come to hate the web deployment stuff (partly disappointment because it held so much potential). The code in the packager is really messy and makes me angry when I try and work with it. Most of it is over engineering as far as I can tell. It also doesn't work reliably. And web deploy is the reason security problems are possible. And... I'll stop there. Unfortunately, native bundles were an after thought and just tacked on. The Native bundler code in the packager is tightly intertwined with this web code currently. I'd like to see that change. e.g. Why do we need version checks on JRE's etc, when we have a co-bundled JRE in our native app? Deployment modes are different For example, a Mac App, iOS app, and Android APK all still need to be signed, their deployment models for signing are different. Yep, agreed. My preference is that each one should be a separate module in the packager, so they can each do whatever is special for them. APK should not have complexities resulting from native, and native not from web, and web not from APK, etc. Each module should deal with the job of building a distro for that platform in the simplest and cleanest way. There would definitely be some re-used code (like signing) that is in a common spot but at the moment the native launcher depends on a JFX built JAR which includes stuff only needed for web, etc. And I agree, I should be able to build my own custom bundle builder that just slots into the framework alongside the others. I should be able to leverage the common code (like signing) from my custom module. - no magic config in the core libraries (higher wrappers can try and add it on
Re: Preloaders
On Jun 6, 2013, at 12:52 AM, Danno Ferrin danno.fer...@shemnon.com wrote: On Wed, Jun 5, 2013 at 9:47 PM, Daniel Zwolenski zon...@gmail.com wrote: To sum up my previous major suggestions for a better world: - web deploy code should be separate module from native, and jar separate again. Each native module (win, Linux, Mac) should be separate and I should be able to invoke any and all of them how and when I want, not just one generateDeployment method as the only entry point. I think JNLP and web generation should be a bundler on the same level as win/mac/lin. No special treatment, it is just hte same as the rest What I don't like is bundling feels like a soup, where u throw a bunch of component in together. Some overlap and some don't and it's not clear what is being generate by each piece. Sometime it's affecting jnlp and native, sometimes not. This creates a very confusing API. I would much rather do my jnlp separate from native. Maybe there is some other way to share declarations, like create a reusable declaration set. In other words they should be separate bundlers, jnlp should be independent of native (they still leverage the same libraries. This should also allow bundlers to be registered for features we haven't thought of yet. - java code of packager should be one library for all platforms so we have one jar for all, not a separate one for each OS. Native bits are referenced from this one jar as needed. I actually disagree with this. Perhaps the default bundlers come in one jar for hte JDK, but I would like the ability to add bundlers external to the tool that evolve at different speeds than the core JDK. Tha was the point of my service loader patch. Making the bundlers separate for the JDK is a good exercise in proving severability. I don't think it matters too much, as long as bundlers can be separate and hopefully dynamically loaded. - native should not have dumb stuff from web as a requirement if not used. Signing, special jfx meta-inf in jars, checking registry for jdk, etc, etc. Native is actually very simple and really should be able to work with a stock standard jar and not need a special jfx built one. Web should be quarrantined so that native isn't sullied by it. Sullied is a bit of a harsh word. Deployment modes are different For example, a Mac App, iOS app, and Android APK all still need to be signed, their deployment models for signing are different. They should be separated but should share API's to accomplish there own goals. there too much confusion here, said the joker to the thief, the ant api/functionality is all mixed together. - no magic config in the core libraries (higher wrappers can try and add it on top). Eg It shouldn't look for wix and use it just because it's installed. I should be able to specify I want wix or inno and tools should fail if they are not there. I still think there is a role for the all packaging type that would do all the ones it has access to and work. However I wouldn't want to see it fail unless specifically called out. i.e. the WIX bundler would fail if 'wix' was in the packaging types, but not if 'all' was the packaging type that called it. This is really a per-bundler decision. Explicit is good, Convention over configuration where it makes sense :) That's just looking at improvements to what's already there. As far as my picks for new features, these would be my top: - app store support (desktop at this stage) - auto updating support for native bundles - cross platform builds on the one machine (ie build for Mac from a windows machine, etc). Also build a 32bit distro on a 64bit jdk, etc. Or build RasPi debs on a linux vm. Separate installable bundlers - compact jre's for smaller distro sizes. All the above :) THIS --Danno
Re: ObservableValue Stacktrace
Hm, ok -- it is correct that it doesn't fail, the code runs without any
problem and everything works as expected.
But, what would be the way to avoid these messages in my log then?
Something like:
Bindings.select( Bindings.when(dataProperty().isNull()).then( ???
).otherwise(dataProperty()), castings) );
??
I'd prefer to just turn these warnings off unless there is a really good
reason to have them (ie, they indicate a logic error or other bug,
something I can resolve...)
In my case the dataProperty() is often bound to the selection of a
ListView -- if you have something valid selected, then a Detail Pane is
filled in with information about the selected item. When nothing is
selected (ie, it is null), then the Detail Pane should remain empty... I
donot want to have to remove/recreate these bindings every time some
property becomes null.
Also, it seems rather wierd that JavaFX will complain about nulls in the
first part of the Bindings.select(), but will happily traverse the graph
(with or without nulls) for the other parts.
Do I have to add an extra level of indirection to get rid off these
messages, ie something like:
private final ObjectPropertyMedia data = new SimpleObjectProperty();
public ObjectPropertyMedia dataProperty() { return data; }
private ObjectPropertyObjectPropertyMedia metaDataProperty = new
SimpleObjectProperty(dataProperty()); // extra indirection...
public ObjectPropertyObjectPropertyMedia metaDataProperty() {
return metaDataProperty ; }
So that I can then do a binding like:
Bindings.select(metaDataProperty(), data, castings);
That seems.. cumbersome :)
--John
On 6/06/2013 09:34, Martin Sladecek wrote:
JavaFX should not fail in these cases, but doesn't consider that a
valid state, so it always prints a warning on the stderr, for the
developer to see something went wrong.
Regards,
-Martin
On 5.6.2013 21:38, John Hendrikx wrote:
Hi List,
I'm getting some log messages sometimes (see at the end) about
properties being null (whereas I didn't get them before in JavaFX 2.2).
Is this intended as an informative message to the developer,
something I should report, or just debug code for the JavaFX team?
In this case, the binding is null, and that's fine -- it will be
populated later, but the binding is already in place -- I thought
JavaFX was designed to allow nulls in a chain of bindings and
fall back to reasonable defaults for things like Strings, numbers
etc? Am I doing something wrong?
Code:
{
private final ObjectPropertyMedia data = new
SimpleObjectProperty();
public ObjectPropertyMedia dataProperty() { return data; }
protected final ObjectBindingObservableListCasting castings =
Bindings.select(dataProperty(), castings);
}
Log:
Jun 05, 2013 9:15:55 PM
com.sun.javafx.binding.SelectBinding$SelectBindingHelper
getObservableValue
WARNING: Exception while evaluating select-binding [castings]
Jun 05, 2013 9:15:55 PM
com.sun.javafx.binding.SelectBinding$SelectBindingHelper
getObservableValue
WARNING: Property 'castings' in ObjectProperty [bound, value: null]
is null
java.lang.NullPointerException
at
com.sun.javafx.binding.SelectBinding$SelectBindingHelper.getObservableValue(SelectBinding.java:481)
at
com.sun.javafx.binding.SelectBinding$AsObject.computeValue(SelectBinding.java:92)
at javafx.beans.binding.ObjectBinding.get(ObjectBinding.java:152)
at
javafx.beans.binding.ObjectExpression.getValue(ObjectExpression.java:49)
at
com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:53)
at
javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:71)
at
javafx.beans.property.ObjectPropertyBase.bind(ObjectPropertyBase.java:170)
at
hs.mediasystem.TitledBlockSample.createCastingsRow(TitledBlockSample.java:114)
at hs.mediasystem.TitledBlockSample.start(TitledBlockSample.java:78)
at
com.sun.javafx.application.LauncherImpl$5.run(LauncherImpl.java:810)
at
com.sun.javafx.application.PlatformImpl$6.run(PlatformImpl.java:260)
at
com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:226)
at
com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:223)
at java.security.AccessController.doPrivileged(Native Method)
at
com.sun.javafx.application.PlatformImpl$5.run(PlatformImpl.java:223)
at
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at
com.sun.glass.ui.win.WinApplication.access$300(WinApplication.java:39)
at
com.sun.glass.ui.win.WinApplication$3$1.run(WinApplication.java:101)
at java.lang.Thread.run(Thread.java:724)
Regards,
--John
hg: openjfx/8/controls/rt: RT-30976: lazy load listener and add listener to backing set on first call to addListener. Reviewed by Martin
Changeset: 479da853570b Author:David Grievedavid.gri...@oracle.com Date: 2013-06-06 08:36 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/479da853570b RT-30976: lazy load listener and add listener to backing set on first call to addListener. Reviewed by Martin ! javafx-beans/src/javafx/collections/FXCollections.java
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 9975ebce5940 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-06-06 17:25 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9975ebce5940 Fix for RT-30947, RT-30915, RT-30936 ! javafx-ui-common/src/javafx/scene/Parent.java Changeset: 2c24c839cc30 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-06-06 17:26 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2c24c839cc30 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfxrt
hg: openjfx/8/graphics/rt: RT-30579: Still cannot rely on Thread.setDefaultUncaughtExceptionHandler() to work with JavaFX App Thread.
Changeset: 2095f12bf331 Author:Artem Ananiev artem.anan...@oracle.com Date: 2013-06-06 19:46 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/2095f12bf331 RT-30579: Still cannot rely on Thread.setDefaultUncaughtExceptionHandler() to work with JavaFX App Thread. Reviewed-by: Kevin Rushforth, Steve Northover ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java + tests/glass/ExceptionHandler/test/com/sun/glass/ui/DefaultExceptionHandlerTest.java ! tests/glass/build.xml
Re: ObservableValue Stacktrace
I don't think we ought to print to stdout or stderr in any case in the platform. A logger is a better idea. But really I think it is unlikely that this particular message will be that useful (it will be unhelpful in just as many cases). It is not uncommon for a chain to have a null in it at some point, and the presence of the message will just make people think something is wrong when in fact it isn't. Richard On Jun 6, 2013, at 9:31 AM, Kevin Rushforth kevin.rushfo...@oracle.com wrote: Perhaps using the logging system would be a better choice in the case than printing to stderr? -- Kevin Martin Sladecek wrote: On 06/06/2013 10:53 AM, John Hendrikx wrote: Hm, ok -- it is correct that it doesn't fail, the code runs without any problem and everything works as expected. But, what would be the way to avoid these messages in my log then? Something like: Bindings.select( Bindings.when(dataProperty().isNull()).then( ??? ).otherwise(dataProperty()), castings) ); ?? I'd prefer to just turn these warnings off unless there is a really good reason to have them (ie, they indicate a logic error or other bug, something I can resolve...) This might indicate a logic error in many cases, esp. when the property you bind is a primitive type. When the select fails in the middle of computation, the only it can do is to set the property to default value (which is 0). If the developer didn't expect this, it would be quite hard to find the actual cause of the zero. If you really expect nulls along the way, it's much cleaner to handle this explicitly as you do in the code above. In my case the dataProperty() is often bound to the selection of a ListView -- if you have something valid selected, then a Detail Pane is filled in with information about the selected item. When nothing is selected (ie, it is null), then the Detail Pane should remain empty... I donot want to have to remove/recreate these bindings every time some property becomes null. Also, it seems rather wierd that JavaFX will complain about nulls in the first part of the Bindings.select(), but will happily traverse the graph (with or without nulls) for the other parts. This is a bug then, it should print the warning in any part of the select expression. -Martin
hg: openjfx/8/controls/rt: Fix for RT-30947, RT-30915, RT-30936
Changeset: 9605455a5abe Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-06-06 17:25 +0200 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/9605455a5abe Fix for RT-30947, RT-30915, RT-30936 ! javafx-ui-common/src/javafx/scene/Parent.java
hg: openjfx/8/graphics/rt: MayaImport: Skipping frames with negative time.
Changeset: bb68d69e00ca Author:Alexander Kouznetsov Date: 2013-06-06 15:45 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bb68d69e00ca MayaImport: Skipping frames with negative time. ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/maya/Loader.java
hg: openjfx/8/graphics/rt: 3DViewer optimizer: refactoring, added KeyFrame, KeyValue analysis.
Changeset: 005e04319ded Author:Alexander Kouznetsov Date: 2013-06-06 15:55 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/005e04319ded 3DViewer optimizer: refactoring, added KeyFrame, KeyValue analysis. ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Optimizer.java
hg: openjfx/8/graphics/rt: 3DViewer optimizer: removes all bad faces from the mesh.
Changeset: bf02e9d55b85 Author:Alexander Kouznetsov Date: 2013-06-06 17:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bf02e9d55b85 3DViewer optimizer: removes all bad faces from the mesh. ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/importers/Optimizer.java
Re: TextField Document model
I've added to the issue a patch along with some sample API to show how it
works. I'm pretty pleased with the result, please try it out and poke holes
:-). I am not ready to check it into the mainline until some people have had a
chance to play with it and let me know of any problems in the API for doing
advanced use cases.
Thanks!
Richard
On Jun 3, 2013, at 10:06 AM, Richard Bair richard.b...@oracle.com wrote:
I've filed https://javafx-jira.kenai.com/browse/RT-30881 and hoping to get
this resolved for 8.
Richard
On Dec 4, 2012, at 8:23 AM, Richard Bair richard.b...@oracle.com wrote:
Hi Mark,
Sorry for being slow -- you will at least be glad to know you are in such
auspicious company as Jonathan Giles, who has to regularly bribe (or
threaten) me to get timely responses :-)
On first read, this seems very nice. The Filter interface is a
single-abstract-method interface, so it will play perfectly well with
Lambda's. It can be reused among multiple controls and types of text input
controls which seems ideal. It seems to plug into the pipeline quite
naturally.
One question is, should the filter start off as null and have an additional
filter (newlines and such) always applied, or should it start out as
non-null where the built in filter handles newlines (and such) and new
filters also will have to either wrap the existing filter or add support for
newlines (and such!) or not as necessary? The safest thing for an
implementor would be to delegate in case we change the built-in behavior.
The next step would be to create a diff and attach it to the JIRA issue (and
make sure you have signed the Oracle Contributor Agreement (OCA)). I think
we can then integrate the patch and start the discussion around formatted
text field. Jonathan, what do you think? Have you had a chance to review?
Thanks
Richard
On Nov 26, 2012, at 7:44 PM, Mark Claassen markclaass...@gmail.com wrote:
I sent a potential API change to Richard Bair a few weeks ago. He has not
responded to me, which makes me think it was too complicated at this point
and wasn't going to fly. I think for a good InputMaskField, the Content
and the eventual caret position and selection needs to be controlled by the
model. This makes the solution a bit complex.
However, for filtering, this is not the case. Doing both of these in one
shot is, perhaps, a mistake. Here is another idea which takes care of the
easy cases...easily. A more complex InputMask control I will save for
later.
So, here is the simplified idea: Add the ability to filter. And by
filter, I mean the ability to modify the input and only the input:
Add the following sub-interface to the Content interface. No methods are
added to the Content interface.
interface Filter {
String filter(int index, String text, String currentContent);
}
Add the following to TextFieldContent and TextAreaContent:
private Content.Filter filter;
public void setContentFilter(Content.Filter filter) {
this.filter = filter;
}
Change the insert method of TextFieldContent and TextAreaContent to start
with:
@Override public void insert(int index, String text, boolean
notifyListeners) {
text = TextInputControl.filterInput(text, [boolean], [boolean]);
if (filter != null)
text = filter.filter(index, text, get());
Add a method in TextField:
public void setContentFilter(Content.Filter filter) {
((TextFieldContent)getContent()).setContentFilter(filter);
}
Add a method in TextArea:
public void setContentFilter(Content.Filter filter) {
((TextAreaContent)getContent()).setContentFilter(filter);
}
This would do a few things:
1) Use the current TextInputControl.filterInput mechanisms of TextField
and TextArea (like to strip out special chars and newlines).
2) By specifying the Filter interface outside of TextField and TextArea, it
allows the same filter to be used for TextField and TextArea
3) Makes it simple to do things like translate all input to upper case or
limit the overall length
4) By not adding a method to Content directly, something like the
InputMaskContent would not be forced to deal with the Filter interface at
all.
This implementation would allow someone creating a filter to filter the
text to have illegal characters. I thought it was more validate this
first, so that the implementer would only have to deal with proper input.
However, TextInputControl.filterInput could be done both before and after
the Filter.filter() call.
text = TextInputControl.filterInput(text, [boolean], [boolean]);
if (filter != null) {
text = filter.filter(index, text, get());
text = TextInputControl.filterInput(text, [boolean],
[boolean]);
}
Another possible addition to this may be to allow the filter to return
null, signifying an error input and causing the system to beep.
Thanks for your consideration,
