AutoExpand on ComboBox seems broken

Hi George
No mine is home use
Darn. I was hoping there was some sort of common thread. The reports are scattered and not too numerous, but there are now four that I've seen in various forums.
 
The Access team is aware of the problem and is pursuing a fix for it. I'll follow up when we learn more.
 
Hello,
Any news? We have a lot of users with this problem.
Do you know the exact windows update KB number that caused this problem? Maybe we can revert back?
Regards,

Dan
 
Hello,
Any news? We have a lot of users with this problem.
Do you know the exact windows update KB number that caused this problem? Maybe we can revert back?
Regards,

Dan
My apologies for not following up in this thread. Details here. We'll update the post as we hear more.
 
Thanks ! Note that we are still using Access 2000 or 2003 ! And this problem is there too
 
Thanks ! Note that we are still using Access 2000 or 2003 ! And this problem is there too
As it appears Access developers have to work around this WIndows 11 bug?, I doubt any fix is going to affect you? Your versions are well out of date. I use 2007, but fortunately, still on Win 10.
 
I hope they will correct their bug. As they have impacted all versions of msaccess with one modification, they can revert back and correct the bug and hopely attain all the versions of msaccess in one action
 
Well that would be for the windows team and not the access team.
 
I have had this issue and posted a while back, and have since been using the below code in the Got Focus of the combo box.

It is not ideal, but it does then allow the AutoFill to work. (where cboBoxName is your combo box name)

Code:
Private Sub cboBoxName_GotFocus()

    Me!cboBoxName.Dropdown
    
End Sub

I have changed the shown rows to 5 on mine, but change as required.

~Matt
 
Thanks
Not sure if this update was done by the windows update team or by the office update team, nor which KB number update is causing this, or which dll is the cause
 
Updated to a public function which also seems to work nicely.

Code:
Public Function funDropdown()
On Error GoTo ErrorHandler

    Screen.ActiveControl.Dropdown

ExitSub:
    Exit Function

ErrorHandler:
    MsgBox Error$
    Resume ExitSub
    
End Function
 
What does that save you?
For our use, we have some fields that have similar entries, but with lots of characters. This saves the single finger typists from having to put it all in. They can start and now it does start to filter by what they have typed so far.

Before it had nothing so you had to type the entire text in.

~Matt
 
For our use, we have some fields that have similar entries, but with lots of characters. This saves the single finger typists from having to put it all in. They can start and now it does start to filter by what they have typed so far.

Before it had nothing so you had to type the entire text in.

~Matt
No, I mean you could add the dropdown to each control event?
As it is you have to call that function in each event?

So I do not see what that actually saves you in coding?

You should search here for FAYT by @MajP.
That involves copying his module and one extra line of code per combo.

Then you can type in *any* part of the description in the combo.
 
OK, I've got the same issue with a combo box. based on a table with 2 columns and only 2 rows.
365 Enterprise 32 bit, accdb in Windows 11

I've even copied a known good combo box from another application and changed the rowsource.
Problem persists
Tried changing the setting for this application and anything that could possibly be relevant for this user
Tried in Windows 10.
Problem persists
tried adding a combo to a different form and used a different row source:
same result
Seen this happen in continuous forms but this one is single view.
The other app used linked Access tables, this one local tables. It's just a demo app.

got me stumped.
My demo app does reproduce this behaviour which is a good start
I'll get the brains trust on it tomorrow.
 
This issue will be fixed in Version 2312, which will be released to Current Channel soon.
 
I've just started trying to convert an old Access Database system (using Office 2013) from 32-bit to 64-bit and have been hitting a few unexpected problems along the way. As it happens, the 64-bit version I'm using is running on a Windows 11 machine while the 32-bit has (most recently, anyway) been running under Windows 10.

I'd assumed that the problems with the combos' AutoExpanding was something related to the 32/64 bit switch so, in one sense, I'm pleased to read that it isn't. On the other hand, even though this seems to have been caused by a specific Windows 11 change (given the number of different Access versions it affects) it seems from what I've read in the link above that it's being fixed by changes to Office / Access rather than Windows which leaves me up something of a gum tree.
 
This issue will be fixed in Version 2312, which will be released to Current Channel soon.
Is this issue related to ANSI 92 compatibility? and will changing this resolve the issue? It did seem to in the sample accdb I created and George sent to you when I updated to 2311.
Note to others: you won't find this setting in Options for Current Database, it's in the Object Designers tab
 
I did check that, and it's not set but the behaviour I'm seeing is pretty much exactly what's being complained about above - AutoExpand can work OK but only for the first 100 or so entries in the list and then it stops, though it works fine if you've dropped down the combo list. Some people have suggested that the problem's more prevalent on subforms rather than main forms, and I had that impression too, but I can't say I've exhaustively checked it. I thought there were some combos which weren't AutoExpanding at all, but I've realised that once I'd spotted the problem, I was just routinely typing in the initial characters 'a', 'b', 'c' and so on to see how far each combo got without thinking that some lists begin with entries that start with non-alphabetic characters.
 

Users who are viewing this thread

Back
Top Bottom