Subheadings visible inside the combo but not selectable!

[Happy YN]

I have seen a combo made in delphi which looks like this when the dropdon arrow is selected
STATIONS
Waterloo
Euston
Liverpool St
AIRPORTS
Heathrow
Stansted
Gatwick

only the lowercase ones are selectable. If the user selects STATIONS he gets a messagebox telling him its only a heading and unselectable. The row source for this info (in delphi) is
STATIONS:Waterloo;Euston;Liverpool St;AIRPORTS:Heathrow;Stansted;Gatwick

i.e. a colon after each heading but a semicolon after each entry

This does't work as a row source in access but could I get this some other way?
Similarly how does one gert an unckliable greyed out option in the middle of a combo dropdown list?
Thanks

[WayneRyan]

Happy,

The ComboBoxes & ListBoxes in Access are pretty rudimentary.
They don't allow for presenting a heirarchical list and they
don't allow for "graying out" individual items. They don't
allow for any differentiation between rows;

You could however put your data example into a ListBox using
the ";" delimiter. It would display in your specified order.
Then you could use the OnClick event, and if the item was
selected AND was UpperCase, you could De-Select it.

Not really un-clickable, but the click doesn't really do
anything.

Wayne

[Oldsoftboss]

Perhaps you could use cascading combo boxes or a tree view control ?

Dave

[Happy YN]

Thanks for your replies! So is access just not as powerful as other programs? I was sure I could imitate it!

[WayneRyan]

Happy,

Access is VERY adept at allowing for the rapid development of
db applications. Its strong points are the ease with which
you can create/modify tables, develop forms/reports and interact
with other MicroSoft applications. The short amount of time
required to develop a small application can't be touched with
something like VB, C++ or even an integrated package like
ORACLE Forms.

For most apps, the standard combos and list boxes are fine.
There are third-party add-ins that support things like the
shading of individual rows or bolding/colors within text
fields.

Dave's point about the Tree View control might be worth looking
into.

Overall, Access will provide a foundation that is easy to work
with. When it doesn't meet a need such as this, either change
the specs or enlist some third-party software.

Wayne

[Pat Hartman]

So is access just not as powerful as other programs? I was sure I could imitate it!

- Access does a pretty good job of conforming to accepted theories of good relational database design. What you are asking for would violate that. You are asking for summary and detail information to be included in the same recordset. Relational databases don't support that type of data. Just because other development environments do, doesn't make them better. In fact, in my mind it makes them worse.

You can simulate this in code as has already been suggested. You can also do it with cascading combos which would be my choice. The first combo would list the types of transportation and the second would list the related set of departure/destination locations.

[Happy YN]

I am very careful with database rules. actually this list is populated with an external ini file but I respect what you say Pat
Thanks for your remarks!

[Pat Hartman]

If the list is populated from an external source, normalize it first so you can use cascading combos.

[Happy YN]

Its not an external table. Its one line of an ini which gets pasted straight into the combo control as values . Since its separated by semicolons, each part becomes a different row in the combo!

[Pat Hartman]

If the import is a one time event, how much trouble could it be to do it right? Surely your users are not copying and pasting the value list.

If you don't want to normalize the data, you're stuck with writing code in the BeforeUpdate event of the combo to prevent headings from being selected.

[Happy YN]

As the form opens it reads an ini to know how to populate those combos. Each line is a different combo. The program is generic. All thats different is the ini. What do you mean 'prevent headings from being selected'? and how do I display them?
Thanks

[Pat Hartman]

Either modify the source to include a semi-colon after the colon or insert it yourself after you read the ini file and before you populate the list. Your code can look for entries that end with ":" and not let the user select them.

Where do these ini files come from? Who maintains them? There are better ways to control the contents of combos than importing text lists each time a form is opened.

[Happy YN]

Such as? reading them off tables? Why must everything in access be governed by tables? (polite question)
The ini is maintained by the designer not the user

[Pat Hartman]

Such as? reading them off tables? Why must everything in access be governed by tables? (polite question)

- My suggestion would be the same if you were developing in C++, VB, or FoxPro. It has nothing to do with Access. It has to do with solid design. Why not take advantage of the relational database? If your code values are defined in tables, you can enforce referential integrity and prevent bad values from being stored. Your present method can easily be circumvented by simply opening the table or a query and entering anything. Relational databases allow the database engine, in this case Jet, to control data integrity.

I have a table and several forms/reports that I add to every application I build. The table contains all the code values my combos will use. I only need to create specialized code tables in very special circumstances.

The ini is maintained by the designer not the user

- The code table could be maintained by the User if you give him a proper interface as I do. What do you care which train stations are in the list? Why do you want to be responsible for maintaining it? Set it up properly as a table, enforce RI, and let the user do his own typing.