Why does Autoexpand in combo box not work with accented characters?

[David Anderson]

To quote the Access online help:
You can use the AutoExpand property to specify whether Microsoft Access
automatically fills the text box portion of a combo box with a value from
the combo box list that matches the characters you enter as you type in the
combo box. This lets you quickly enter an existing value in a combo box
without displaying the list box portion of the combo box.

This works fine when I use the normal English alphabet, but fails if I type
an accented character as the first character of a name in a foreign language
such as Hungarian. Is there any way to make AutoExpand work for all
characters in either Access 2000 or Access 2003?

David

 

[Linq Adams via AccessMonster.com]

How are you "typing" in these accented characters? If I have a value in a
combobox such as Çhua where the Ç was created by entering <Alt> + 128, and I
again enter Ç using <Alt> + 128 in the combobox, it does AutoExpand for me!

 

[David Anderson]

Hi Linq,
I have only just become aware of the need to accommodate accented characters
in my Access 2000 application, so I have not yet sorted out an easy method
for my users to 'type' such characters on a UK keyboard (finding a way to
use the Windows charmap.exe utility program might offer a solution). The
accented names that currently exist were originally created in Excel,
probably using the symbol insertion facility.

My initial test of AutoExpand was done by copying the required accented
character from the Windows Character Map and then pasting it into my combo
box. This didn't work, but your post implied that there might be a problem
with this method of data entry so I have just tried pasting in some
non-accented characters. That didn't work either, so clearly pasting was my
problem, not the character. Thanks for highlighting that issue.

Your solution of using an Alt-nnnn keystroke combination to enter an
accented character is fine if your required character can be generated in
this way. However, based on a random search through Character Map, many
characters have not been allocated an Alt-nnnn code (displayed at the bottom
right of the Character Map acreen). They only have a U-FFFF code, displayed
at the bottom left of the Character Map screen. I've no idea what you are
supposed to do with this U-FFFF code (where FFFF is a hexadecimal number),
and the Help doesn't help. Any suggestions?

BTW, your example of a capital C with a cedilla accent is Alt-0199 according
to Character Map. Where do you get Alt-128 from? Both codes work on my PC.

David

 

[jimatch4]

David,

I saw your post by randon accident and thought I would comment.

Don't know that this is directly relevant to your issue but,

Keep in mind that IF your ComboBox is populated in its DataSource
property by a SQL SELECT or SELECT DISTINCT statement, then unallowed
characters may break the SQL query that provides the source population
to the list box. The election for the version of ANSI SQL may also
affect this as there is differerent behavior in different ANSI SQLs in
Access. On just this see KB824189, depending upon Access version of
course. If you are not using a query "behind" or for the DataSource,
this is probably not a problem.

I had an experiece where users decided to put character that were in
not allowed by SQL language as it applies to MS Access (i.e., not
standard alpha-numeric and the few allowed symbols) and that started
breaking queries. It was a curve ball. It was ugly. I was able to
quickly discover that they were doing this, but it was a mystery at
first and could have caused a lot of frustrating troubleshooting time.
Many SQL queries brok in the app due to this in a key table. Not
practical in this instance to validate.

JIm

 

[David Anderson]

Hi Jim,
I don't have any current requirement to specify ANSI 92 SQL in my Access
2003 apps but I'm interested in your reference to 'unallowed' characters.
Where are such SQL restrictions documented?

David