>>Cetin -
>>
>>I did get Nick's code to work for me, but still intend to try yours (I really want to have a class for this). How does your situation differ from that of Nick's with respect to row source, control source, table buffering, etc. I still don't feel I have a good handle on the combobox in this situation (a rite of passage?) and want to try several variations in the hope it sinks in.
>>
>>Sylvia
>Sylvia,
>First revised (local language fix stripped) class code

**************************************************
>*-- Class:        mycombo_edit (c:\temp\test.vcx)
>*-- ParentClass:  combobox
>*-- BaseClass:    combobox
>*
>DEFINE CLASS mycombo_edit AS combobox
>	Height = 22
>	Width = 100
>	DisabledBackColor = RGB(255,255,255)
>	aliasname = "None"
>	fieldname = "None"
>	Name = "mycombo_edit"
>	PROCEDURE When
>		THIS.REQUERY
>	ENDPROC
>
>	PROCEDURE LostFocus
>		this.value = this.displayvalue
>	ENDPROC
>
>	PROCEDURE Init
>		WITH This
>			.rowsourcetype = 3
>			if lower(.fieldname)="none" or ;
>				lower(.aliasname)="none"
>				.fieldname = substr(.controlsource,rat(".",.controlsource)+1)
>				.aliasname = substr(.controlsource,1,;
>								rat(".",.controlsource)-1)
>			endif
>			.rowsource = [SELECT DISTINCT ]+THIS.fieldname +;
>				[ as dummy FROM ]+this.aliasname+[ where !empty(]+THIS.fieldname + ;
>				[) union ] +;
>				[SELECT this.displayvalue as dummy ] +;
>				[ FROM ]+this.aliasname + ;
>				[ INTO cursor qq order by 1 ]
>		ENDWITH
>	ENDPROC
>ENDDEFINE
>*
>*-- EndDefine: mycombo_edit
>**************************************************

It takes into account that buffering may be used.
>- Controlsource is as always your real table.field
>- Rowsourcetype is SQL, so doesn't play with rec pointer in any table
>- Rowsource is identifed by two custom properties "aliasname" and "fieldname"
>- If alias or fieldname left blank then they both default to controlsource's alias and fieldnames respectively. Advantage of this, you might not set a lookup table at all but index on that controlsource. Distinct values populate the combo (really I generally use own table and do not hold a lookup table). This way user itself build the list in time (ie: disease names fill up the list w/o need to have a ready classification table which would be thousands of records, each section enters only those they deal with).
>- Logic :
>If contained in list choose from there, if not add to list.
>- Since buffering or a lookup table wouldn't have a new value in list SQL unions current display value to existing ones. So requery really does its job.
>- This works good. Only one exception still. If buffering is set to table, !tableupdated new values other than current displayvalue would drop from list. If you want to prevent it then you should collect those new to add to SQL.
>Hope it's understandable and helps. BTW I use it perfectly in grid too.
>Cetin
Cetin-
You and Nick both bring up a point I am just now starting to think about using a combobox to add new values to a table - namely, is this the kind of situation where I should use table buffering? I'm asking because if I were adding fields in the normal way through some kind of file maintenance form, I would. But what I'm trying to do here is circumvent the normal rules by allowing a value to be added to the table on the fly. I'm not even taking into account that (e.g.) they add this city and oops they mispelled it or something. I just figured they could go into a form maintenance routine and do all that stuff. But I guess the biggest issue is that someone else is using the table. Anyway, I'd appreciate your thoughts on this (clearly you allow for this in your class).

Sylvia