ComboBox 'Close' drop-down

I am on Mac V11.7.0 & XOJO 2023 R1.1
Close by definition “Closing a control permanently removes the control from memory, making it impossible to access.”
I have a problem with the CombBox and it has dropped down and the control is disasbled, the control doesn’t ‘close’ or remains dropped down.
I am not sure what to call this action, but close isn’t the right word. What do I call this and how do I do it?

Hmm… Interesting, even moving the focus to another control doesn’t close the popup. It’s not a control I’ve used. I use Popup menus instead, I know that doesn’t offer typing new entries.

Sounds like a bug that needs reporting.

FocusLost was ran, and if I put a breakpoint in it the control ‘closes’. Then if I remove the breakpoint, it doesn’t close.
This is probably one of my problems that happen because of size of code.

No, it is reproducible with a simple empty Combobox on a brand new project.

– Create a new project
– Add a combobox
– Add a button

Run it and open the combobox. Press tab and the Combobox stays expanded!

It’s a bug and you should report it.

So is the button set up to accept focus? Otherwise, Tab isn’t going to do anything.

Seems not happen on Windows.
What is sad is that it does not autocomplete known items from the current list of the options, it kind of “filter”. The behavior is very inconsistent. Changes if popup is open or closed.

Yeah, you have to build that yourself. I use a textfield, a disclosure button and a listbox that floats above the rest of the controls. It’s database aware and will display the closest match as you type, or give the matching items if you open the dropdown. The built-in combobox is just so limited.


So sad. I hope we get a palette of WinUI3 ready to drag and drop components needing just setting few properties, soon, in a WYSIWYG way, without dragging XAML squares and guessing configuration texts of a proper combobox and other controls.

I had a very shrunk recent example project with 600kb and not 3mb of code and it doesn’t happen.
It’s my nemesis: Too much code.

For me, yes. All controls are able to accept focus. Also buttons always are able to (at least by default).

No code, just empty controls, and the problem is certainly there.

Sonoma bug or new Sonoma behaviour? This is what I can get running an Xcode app on Sonoma (14.2):

Try what he said


Yes, I’m on Sonoma. No idea if it’s the same on prior versions. I don’t use the control.

@Rick_Araujo That’s exactly what I tried and exactly what you can see in the screenshot got from a native Xcode app running on Sonoma. :man_shrugging: Sorry in advance if I’m missing something in between

Just about to upgrade to macOS 14.1.1. I doubt it would make a difference but trying it anyway.

That’s it. I don’t know if this is, thus, an Apple bug or if they just decided that the Combobox should behave like this from now on :slight_smile: I’m more inclined to think that is a bug in the Apple side.

No difference, the screenshot is from Sonoma 14.2

Me too, specially if it allows a combobox with no contents and items open with an empty selection list shown and let it there for no reason. :rofl: It would be a stupid UI design decision our friend Jony Ivy would not let happen on his days at Apple.

That leads me to another question, can you do the same with a popup box? Open it and let a list “there” and move to another control?

Nope, that one works at expected on Xcode and, thus, on Xojo under Sonoma.

So it is a bug (should be) or a very weird behavior someone should need to explain in Apple docs.