Thanks, John. It would be helpful if you could create an issue in jira to track
this.
On Jan 8, 2014, at 4:18 PM, John Hendrikx wrote:
> On 8/01/2014 14:28, David Grieve wrote:
>> The reason things are as they are is because most properties in the core
>> classes are lazily created and I didn
Noticed a slight bug in the code.
The line:
cssMetaDataByName.put(cssName, cssMetaData);
...needs to be added in the if block where the CssMetaData is created.
--John
On 8/01/2014 14:28, David Grieve wrote:
The reason things are as they are is because most properties in the core
classes are lazily created and I didn't want cause the property to be created
just to see if it was bound. But that is a particular concern for the core
classes and not so much for
The reason things are as they are is because most properties in the core
classes are lazily created and I didn't want cause the property to be created
just to see if it was bound. But that is a particular concern for the core
classes and not so much for controls.
I'm not sure if you are aware
+1. I ended up creating such property subclasses myself, too. And I don't
provide the static getClassCssMetaData() either.
Tomas
On Wed, Jan 8, 2014 at 7:05 AM, Tom Eugelink wrote:
>
> Yes, I had similar considerations. I was thinking about providing exactly
> such extended Property classes in
Yes, I had similar considerations. I was thinking about providing exactly such
extended Property classes in JFXtras to remove as much of the boilerplate.
Tom
On 2014-1-8 3:34, John Hendrikx wrote:
Hi List,
I'm in the process of adding CSS metadata to a new control, and I noticed there
is a
