PopupMenu build speed

I regularly use big listboxes which seem to populate really quickly, when populating big popupmenus (800 lines or so) I get long waits (2 seconds ish). I’ve tried keeping the calculations out of the build process, so it’s just iterating from a dictionary but still the same problem.

I’m looking at using a modal box or sheet instead but popupmenus are more in line with the app UI.

Any suggestions or guidance greatly appreciated.

I don’t think it’s very user friendly to have popupmenus with 800+ items in it …
I would do the user interface with something else ?
may be a combobox with autocomplete would be easier to work with ?

After a quick experiment:

Add 1 item, set the listindex=0

add the rest of the items

Set the listindex as desired.

In my tests it went from1.32 seconds down to .012 seconds

800 lines are not in line with ani GUI guideline. The custom window is a good idea, you can make it to be in line with your UI, and also, for big items, make it reusable, showing and hiding instead of building each time.

For data that are Names of people (cities, spare parts, etc.) or something (800+ !):

In a window, add a 1 Row (no header) Listbox,
Set it to 27 columns,
Add in each column a letter (UpperCase) from A to Z and #)
Add code to display the Names in each Cell (say all names that starts with a A in Column “A”, and so on)…
Then when the user select Abel or Adam, execute the code to display what you display with your PopupMenu…

Is this please you ?

PS: I use that in one of my software for Clients (Retrieved from a Data Base), I display first name family Name; you can add city Country (or State),…

The clicked Row (letter or #) is changed to green / Blue, whatever as User Input.

Nota: I took the TRAM yesterday to go in alt Strasbourg yesterday: the user interface to take a ticket was awful (and awful is a too good word to describe the user experience… some people MUST be trained in that domain)…
They do not know Round trip tickets, only one way tickets, so you have to set how many one way tickets you want in one screen, then how many set of one way ticket you want, then…
Strasbourg, France: I love you :frowning:

@jim mckay

Thank you, Jim. To me, this is the reply of the month.

Here’san empty screen shot that will display what I meant in my message above. This window is extracted from a software created for Caritas Alsace (ths their logo name and address).

The displayed data (when some exists) comes from a SQLite database file.

Prnom(s) stands for First Name
Nom for Name
ID: (Unique ID I suppose)

I do not used the software with more than some entries to be sure it works (debug mode)

Edit:
I forgot to mention that you can see TWO Listbox(es) in the window: one for the alphabetical letters, and the second to display the found people names. A click in a Row display the data for that person in another window.

[quote=422584:@Jean-Yves Pochez]I don’t think it’s very user friendly to have popupmenus with 800+ items in it …
[/quote]

800 Items may not be great UI, but it happens.

From Apple’s Docs for NSPopupButton addItem:withTitle: (AddItemWithTitle doesn’t seems to be the slow part though)

"Since this method searches for duplicate items, it should not be used if you are adding an item to an already populated menu with more than a few hundred items. "

The slow down doesn’t happen on Windows BTW.

I think what’s happening is macOS automagically sets the selection to the first menuitem. So the Xojo framework is setting it back to -1 on each AddRow call. That’s slow…

In XCode I ran these:
The first version, setting the index inside the loop is slow (over 1 second). The second version (setting it after the loop) is instantaneous.

int index; for (index=0; index<1000; index++) { [_popup addItemWithTitle:[NSString stringWithFormat: @"Item %d",index]]; [_popup selectItemAtIndex:-1]; }

int index; for (index=0; index<1000; index++) { [_popup addItemWithTitle:[NSString stringWithFormat: @"Item %d",index]]; } [_popup selectItemAtIndex:-1];

Unfortunately PopupMenu.AddRows seems to show the same behavior.

Ok, found a semi-bad side-effect…

Since the IDE renders the native control in the layout, I tried this…

Add 1000 items to a popup in the IDE.
Watch the spinning wheel.
Duplicate the control.
Watch the spinning wheel.
Drag the control.
Spinning wheel.

You might not need 1000 items in a Popup, but what if you have 20 popups with 50 items?

I tried a window with 40 popups with 50 items each and the window takes 3-4 seconds to appear after the app has launched.

Could this also be linked to some of the “Slow IDE” complaints that come up from time to time?

What if you populate in the open event instead, using your trick? Should avoid the lag …

[quote=422666:@Markus Winter]What if you populate in the open event instead, using your trick? Should avoid the lag …

[/quote]
If you set the ListIndex to 0 in the IDE and then set it back to -1 on open, that would also eliminate the lag.

Not quite sure what you are saying. Do you populate in the IDE and just set the ListIndex in the Open event?

[quote=422681:@Markus Winter]Not quite sure what you are saying. Do you populate in the IDE and just set the ListIndex in the Open event?

[/quote]
That’s what I was saying, but I checked and it doesn’t change the loading time.