Combo Box Length Limit? (1 Viewer)
- Thread starter Frothingslosh
- Start date
Understood thanks. Thought it was rather sad there was no solution given. Maybe it'll help someone as the character limit persists and can be a latent issue. Just came up on a app that I developed 20 years ago. Ha. Take care.
- Local time
- Today, 00:14
- Joined
- Oct 29, 2018
- Messages
- 21,467
No worries. I agree. Thanks for sharing.
- Local time
- Today, 02:14
- Joined
- Feb 28, 2001
- Messages
- 27,156
Since this popped up and reminded me of the problem, I think I understand something better now. The combo has a limit because the text fields have to be Short Text. Because of indexing considerations, you can't have a Long Text there, and that is the source of the 255 character limit. Maybe.
I think it's more about the control itself is coded with a reasonable limit. Much like, as you point out the ShortText datatype has limits around indexing and such - but not specifically because of those limits per-se. They have to draw the line somewhere and consider the perf vs. resources etc etc.
Thankfully the combobox control can have many columns(probably 255 - not sure), each with up to a 255 char limit.
Thankfully the combobox control can have many columns(probably 255 - not sure), each with up to a 255 char limit.
- Local time
- Today, 02:14
- Joined
- Feb 28, 2001
- Messages
- 27,156
You are correct about the field limit because a comobox has a query as its .RowSource and queries are limited to 255 fields.
- Local time
- Today, 08:14
- Joined
- Sep 12, 2006
- Messages
- 15,648
Does this small app help?
There's a table with a few random strings included. A single form is linked to a query based on the strings in the table. I made the query select distinct values, as I thought in your circumstance you would have duplicates.
The form shows those strings in a continuous form. and lets you assemble them into a larger text string, by selecting the sub strings you want to build up the new string. It's easier than using a combo box I think, as you have more space to work with.
The hardest part was understanding how the string manipulates the selstart and sellength properties, and I learned a bit in the process!
Note that there is one catch. If you edit the new string directly, the selstart property gets reset to 0, and the new text box loses the active cursor setting. Try editing the text, then inserting a substring - the insert now gets placed at the start. You can fix this by clicking out of the text box, then back in again which resets the selstart cursor, and then click out again (without editing it manually again)
I had included some code to track changes to the selstart value to see what was happening, but have commented it out.
This behaviour is explained in this link - but I don't quite follow the code, (very comprehensive answer posted by C Perkins) so rather then spend more time on it, I just noted the click out and back in fix above.
stackoverflow.com
I found another reference to this issue here on AWF from 2012 but I don't believe it did actually fully explain the behaviour. Here's a link to the thread.
Using SelLength and SelStart | Access World Forums (access-programmers.co.uk)
There's a table with a few random strings included. A single form is linked to a query based on the strings in the table. I made the query select distinct values, as I thought in your circumstance you would have duplicates.
The form shows those strings in a continuous form. and lets you assemble them into a larger text string, by selecting the sub strings you want to build up the new string. It's easier than using a combo box I think, as you have more space to work with.
The hardest part was understanding how the string manipulates the selstart and sellength properties, and I learned a bit in the process!
Note that there is one catch. If you edit the new string directly, the selstart property gets reset to 0, and the new text box loses the active cursor setting. Try editing the text, then inserting a substring - the insert now gets placed at the start. You can fix this by clicking out of the text box, then back in again which resets the selstart cursor, and then click out again (without editing it manually again)
I had included some code to track changes to the selstart value to see what was happening, but have commented it out.
This behaviour is explained in this link - but I don't quite follow the code, (very comprehensive answer posted by C Perkins) so rather then spend more time on it, I just noted the click out and back in fix above.
TextBox.SelStart gives different value for mouse and keyboard
I have a TextBox on a Form. I take the cursor position using .SelStart property in that TextBox. It works as required when I click within TextBox. I then use that position to insert certain symbols...
stackoverflow.com
I found another reference to this issue here on AWF from 2012 but I don't believe it did actually fully explain the behaviour. Here's a link to the thread.
Using SelLength and SelStart | Access World Forums (access-programmers.co.uk)
Last edited:
Mike Krailo
Well-known member
- Local time
- Today, 03:14
- Joined
- Mar 28, 2020
- Messages
- 1,043
Very interesting thread and I'm glad @Jbooker dug it out of the past. I had the same thought about pulling the data directly from the table but using multiple columns in the combo seems like a very good solution and probably the one that the OP could have used effectively without changing the interface hardly at all.
