@carlw Thanks 🙂 problem was in caret position set before request focus in my case.. Now it much cleaner.

@mikehearn @carlw Not that I'm aware of. As far as I know, it's expected that the code that generates the nodes will apply any special classes/pseudo-classes to generated elements (like

:odd

and

:even

for lists and tables), so if you want to distinguish the first element, you'll need to do so in the cell factory.

Ah, I found the line that I believe covers it. In the CSS Ref under "Limitations", item 4:

The structural pseudo‑classes are not supported.

https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html#introlimitations

how to prevent

runAsync

running copies of processes?

@chickenfresh You'll have to provide some more information - what issue are you running into?

man, it's such a pity how much stuff was broken by java 9/10

graviton supports both and there are some nice improvements in 9/10 but every app breaks

i've never found a single app that wasn't broken by java 9. unreal.

even a very simple app like the FontawesomeFX glyphs browser broke

@edvin I’ll explain it in example: I have button, on press I’m asking server for data, let’s say it takes 5s to respond. Result should be shown in view, so I use this construction:

runAsync {
    ask_server
} ui {
    show_result
}

but if I press button more than once - it would send requests for each press, when I need only 1 and never more

you should be binding the disable property of the button to the running of TaskStatus

You mean deactivating it?

inject the globally available TaskStatus and do something like button("Run") { disableProperty().bind( status.running) }

I have same issue with scroll, I finished working on it, and when user’s fov reaches one of the edges - it asks for new rows until they come

that's a little different b/c the scroll is custom stuff

Yeah, but I’ve tried a lot of things, none worked perfectly

I was even thinking about checking for list size, as example If I had 10 and each time I’m asking for another 10 I’d set it to 20. Until

list.size(10) != expected_size(20)

we won’t ask for new, and then, when server’s responded I count rows if only 9 came. So i set

expected_size

to 19 and again

The original requirement that my scroll hack implemented was breaking up a large (20k) list of items. Eventually, you would get to the end. Make sure that you are backing up a little after a fetch instead of immediately showing the last one. In my case, I would fetch results and then back up a screenful. If the user still didn't see what they wanted, they would scroll down and bring the last retrieved into view. This would kick of another fetch.

I didn't envision the endless scroll at the time.

The whole problem with the JavaFX scrolling is the lack of a ScrollEvent. There are some handlers in the javadocs, but they don't work.

I still don’t realize why they’re ignoring such an important stuff, but we’ve almost finished hacking it and not much todo left

Even in C++’s Qt they have everything to work with it

With regards to Qt, I'll take the hack, From their FAQ

Haha, didn’t know they limit usage

Link to the above screenshot: https://www1.qt.io/faq/

JavaFX is going through some turmoil but may come out stronger in the end if the community lead by some established companies can take over.

Idk why it haven’t grow off yet

I’m running my app on every single platform with no problems and performance issues, enough to work with it

me too

(for years now)