Thanks. At least it now gets to Jonathan whose address for some reason
didn't make it to my previous email.
Pavel
On 31.5.2013 12:28, Werner Lehmann wrote:
I created a tweak ticket for this:
https://javafx-jira.kenai.com/browse/RT-30839
On 28.05.2013 19:15, Pavel Safrata wrote:
Hi Werner,
I d
I created a tweak ticket for this:
https://javafx-jira.kenai.com/browse/RT-30839
On 28.05.2013 19:15, Pavel Safrata wrote:
Hi Werner,
I didn't realize you are writing an API as opposed to an application
where you'd have control over your controls :-)
In this case I indeed don't see any straight
Hi Werner,
I didn't realize you are writing an API as opposed to an application
where you'd have control over your controls :-)
In this case I indeed don't see any straightforward solution right now.
Perhaps it might make sense for us to mark the "skin/control-internal"
nodes somehow. It may
Hi Pavel,
I like marking those controls with a property. UserData I would leave
for external usage. I think it is a property anyway.
The main problem here is that this is a container for arbitrary nodes,
including other containers. I can watch for changes in my list of
immediate children but
Hi Werner,
so you need to distinguish "your" controls from "system" controls. Can
you mark your controls somehow? For instance by node property or style
or perhaps even userData or id?
Regards,
Pavel
On 27.5.2013 15:52, Werner Lehmann wrote:
That statement might have been too soon. Consider t
That statement might have been too soon. Consider this FXML:
SceneGraph looks like this:
ScrollPane
- ScrollPaneSkin
- StackPane
- StackPane
- Label
- LabelSkin
- LabeledText
A drag or mouse event with target "Label" (or belo
Thanks, Pavel. At least now I know that I am not reinventing a wheel and
actually have to check the parent chain of the drag target.
On 24.05.2013 13:32, Pavel Safrata wrote:
Hi Werner,
if you don't want to register handlers on the vbox children then yes,
this looks like the best thing to do -
Hi Werner,
if you don't want to register handlers on the vbox children then yes,
this looks like the best thing to do - the system cannot tell which node
in the target's parent chain is your desired target, you need to decide
that manually.
Alternatively, you can have a single handler using t
Hi,
I am handling mouse and drag-detected events on a vbox to get a common
processing of the vbox children. Therefore event.source is always the
vbox (that is ok) but event.target is quite often some part of a skin, e.g.
com.sun.javafx.scene.control.skin.LabeledText
To get to the actual labe
