Lou Hamers

If you want to try using that jar, try looking into configuring Maven to use local jar files. You can drop the jar somewhere in your project and should be able to get Maven to use it as a local dependency.

You found the link that I was about to send up. That's the best setup resource these days since it was pulled out of the normal JDK. (I wish it could be pulled more out. It still basically just as inaccessible and hard to contribute to as the JDK. I can't use email lists!)

It wasn't hauled off to Apache though - if anyone, it seems to be Gluon that contributes the most to OpenJFX. (Seems like a cool company too - no I'm not affiliated with them or anything.)

I still prefer to not mess around with the "normal" extra steps, and use SDKMAN to install one of Azul's fx-java JDK builds (or Gluon has one too) which has OpenJFX built in. Turns the process into about 2-3 CLI commands and that's it other than pointing your IDE to it. But you kinda need to be using Linux for it to be that easy.

Looks like Carey beat me to a response, but that's showing the kind of thing I had in mind about a different approach.

Oh, Paul's guess was more correct.

Well, you also have the option of using synchronized on a method instead of using a block.
https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html

But be careful, you may still end up with issues if you only synchronize for a short period inside a loop like that, since you have dedicated threads for add/remove. If one thread adds or removes something on that same set object while the other thread is in the process of looping through the set, that would still seem to be a problem requiring some re-design. What if your remove thread is about to work on the last item, but then the add thread adds another item to the end of the Set? The remove thread wouldn't process the last thing just added and that behavior would be fairly random (but maybe that is okay). A thread could skip over things, or process them twice.

Seeing your simulated processing delay placeholder maybe a different approach would be better, but we'd need context to give useful feedback. The potential maximum size of the set would be a factor too.

As I was refreshing my own memory on Iterators, which apparently has gotten dusty, it occurred to me that maybe even that's not needed if you really just want to add and remove some objects known ahead of time. You could do all the add operations, and then all the remove operations afterwards (in the same method).

But I suspect you'll probably still want to use Iterator's remove(), which allows you to examine each item to determine if it should be removed. You could also create a "remove later list" and avoid using an Iterator entirely, but an Iterator is usually easier.

Paul Clapham wrote:The API documentation tells you how to create a synchronized version of a TreeSet. It's not complicated, check it out.

I'm not sure he was asking about that, although he may need to do that too. I guessed that he saw a ConcurrentModificationException and needs to get around that. Which is coincidentally also explained just below the thread safety solution in the API docs (which are always a good place to start when solving a problem): https://docs.oracle.com/javase/8/docs/api/java/util/TreeSet.html

Look into how to use a Java Iterator, which has a remove method you can call while going through the list, those are pretty simple to use.

Eclipse is strange, for some things. I only use it when forced to these days. You might prefer NetBeans or IntelliJ more, if you have a choice, especially the latter.

But it is also good to know how to use Eclipse, since it's so common that teams want to use it, for some reason.

Tim Holloway wrote:Plus, we supply the "why", where they mostly supply the "how".

That's a big difference, and why SO kind of offends me. "I got it working" without knowing why is just asking for trouble.

Tim Holloway wrote:Without Copy-and-paste from Stack Overflow, probably 90% of modern software development would grind to a halt.

I hope the number is a lot lower than that!

I can't remember the last time I intentionally visited that site. Partly because I kind of dislike the site and how people behave there. Not to mention it's easy to waste a ton of time browsing.

Unless it's some obscure thing or something urgent (then, anything goes), I try to start with the most authoritative sources (Javadoc, library author docs, etc.), and sometimes dependency source code. I realize that's atypical... Meaning the 90% guess could be accurate, but I don't like it.

Also:

It's a good idea to specify the generic type of the ComboBox. It helps the IDE's autocompletion in addition to adding compile time type safety. Yours might be ComboBox<String> but maybe ComboBox<Integer>.

And a nitpick, your naming convention is too snakey (horrible Python-ish underscores! haha):
tab_extract_info_cbo_Extract_Type
is normally lowerCamelCase in Java:
tabExtractInfoCboExtractType
(which I would try to also shorten if you can, ex. extractTypeCbx) (and don't forget to change the fx:id in the .fxml to match so your @FXML injection still works)

I don't think what you've provided has enough context to determine what's happening. Maybe something focus related you're doing elsewhere. Are you binding the value of the ComboBox to OC's extractType value or something (which changes on focus...)?

I wouldn't use a focus listener anyway. I would instead watch valueProperty. (Although there are other options too.)
       cbTest.valueProperty().addListener((observable, oldValue, newValue) -> {            //Do something with newValue which would be an Integer in this case        });                //This is the expanded non-lambda version which is more verbose but clearer        cbTest.valueProperty().addListener(new ChangeListener<Integer>() {            @Override            public void changed(ObservableValue<? extends Integer> observable, Integer oldValue, Integer newValue) {                //Do something with newValue            }        });
   //Just to show context    @FXML    ComboBox<Integer> cbTest;    cbTest.setItems(FXCollections.observableArrayList(1, 2, 3, 4));
If you're still stuck, what are you initializing the ComboBox with? I guess it's a list of Strings containing numbers? I used int (autoboxed to Integers) above but it's basically the same.

What was happening with the bind() line is the tags (InputFields) had their preferred height following the overall container itself. Which I'm pretty sure you don't want to do.

Not sure if this is exactly what you have in mind, but it does seem functional:

Try removing this line at 115:

inputTextField.prefHeightProperty().bind(this.heightProperty());

And line 67, go back to FlowPane:

public class AutocompleteMultiSelectionBox extends FlowPane {

Still testing but I was surprised to see that it looks like it's pretty close to reasonable behavior (I didn't think it would be that easy to get such a result).

No problem - it'll take a little bit to go through the code to figure out what it's doing.

A quick test in Scene Builder to see how a FlowPane reacts to TextInput children seems to indicate that it does do what you want "by default". The problems look like 1) styling (solvable for sure) and 2) automatic width sizing of the TextInput (this could be tricky with that component).



This code does make it act strange big time though. Every letter I type in a new tag makes the tag heights grow, but then they right-size again. And row 2+ TextInput heights kind of go crazy. So yeah, I'll take a closer look...

I'll have a look at it! I haven't actually used FlowPane before but I imagine that'd be your best container.

What's probably happening is just the automatic sizing of your containers isn't defaulting to decent values, so we probably just need to set some specific max/min/preferred sizes.

If you want to drop your css in here I'll use that to get a more similar look. But regardless I'll take a look at the code here...