>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