Hiding combobox arrows

[SueBK]

Is it possible to hide the drop down arrow on a combo box on a form?

I have a number of combo-box fields on my form that are locked against editing. I don't want to confuse people by having them look like they can change the contents. Currently I put little rectangles over the arrow, but sometimes these seem to move (screen resolution?).

I tried changing the field to a text box, but this then just gives me the bound ID field (which is a number) instead of the related field (which is descriptive).

I wondered if there's a tidier way to do this?

 

[Isskint]

The Cover Up method is the most popular way. The combobox does not have an assigned property for the appearance of the drop down arrow.

The fact that as textbox it returns the bound ID field (which is a number) suggests you have a lookup in the table itself, which is one of the BIG NoNo's in table design.

However, there are a couple of alternatives.
If users will NEVER need to change or enter values in this combo make it a textbox and make the rowsource =Dlookup("RELATEDFIELD","TABLENAME","FIELDNAME=" & Me.FIELDNAME)

You could make it a Listbox with a single row display. You could add some VBA to make it act like a combobox if this ability is needed (expand the size to show more rows, display a textbox OVER the listbox to act as the type and search feature - Look up Search as i type on this forum for tips on this)

 

[John Big Booty]

I'm not aware of any method to hide the drop down arrow on a combo. The best I could suggest is hide the Combo when it locked and show an unbound text box that you populate using the DLookup() function.

 

[SueBK]

"The fact that as textbox it returns the bound ID field (which is a number) suggests you have a lookup in the table itself, which is one of the BIG NoNo's in table design."

I have picked this up from the forum; however, it's how I was taught, and I don't know how to design without it.

If using lookups in table design is a big NoNo, why is it available? (That's probably a silly question; it is Microsoft, after all)

 

[Isskint]

, why is it available? (That's probably a silly question; it is Microsoft, after all)

yep

As to how to design without using lookups in table, use the lookups on the forms in Comboboxes. If you "hard wire" the values (List Values) in your table lookup, simply create another table with the values and use that as the Combobox rowsource. This way the option list can be changed if need be with a simple pop up form rather than redesigning the DB.

 

[Galaxiom]

The Cover Up method is the most popular way.

Yes. Just place a rectangle with a Normal BackStyle over the drop down button and Position it to the front.

The fact that as textbox it returns the bound ID field (which is a number) suggests you have a lookup in the table itself, which is one of the BIG NoNo's in table design.

No it doesn't. A combo can have a rowsource based on a lookup table without there being a lookup in the main table itself. Either way the data itself is still the bound column which is what will be displayed if the combo is converted to a textbox.

When a table field has a lookup the Form Wizard builds exactly the same structure with the combo. Indeed if the combo will be used in several forms I will impliment a table lookup for this very reason then delete it from the table after the forms are done. It saves work.

The other alternative to form level lookups is to join the lookup table into the RecordSource query. However this means more work for the engine and generally more network traffic since the displayed field data is usually bigger than the bound column data. Moreover it only allows a single piece of data to be held in the combo row.

However it can be a reasonable alternative for display-only controls where the data in the other columns is not required.

However, there are a couple of alternatives.
If users will NEVER need to change or enter values in this combo make it a textbox and make the rowsource =Dlookup("RELATEDFIELD","TABLENAME","FIELDNAME=" & Me.FIELDNAME)

That is not an efficient alternative because the lookup table has to be queried every time the current record changes. It would be better to use a join to the the lookup in the RecordSource query as I mentioned above.

(I have always assumed that the rowsource of a combo is loaded into memory when the form is loaded so it doesn't have to hit the table every time the current record changes. I would be intersted if anyone can confirm or refute that assumption.)

BTW Textboxes don't have a RowSource, just a ControlSource.