>Ed:
>
>Thanks for your response. It was indeed a pretty general question.
>
>Here's the actual situation:
>
>I derive a base_combobox class from the VFP combobox class. The base_combobox lass is pretty generic. It merely contains some code in its init() handler to set standard colors and identify a help key; some code in gotfocus() to change the background color of the object so that it is visually apparent that it is the control with focus; and some code in the lostfocus() handler to restore the background color.
>
>From the base_combobox I derive a combolist class in which the style is set to 2, and from this class all of the combobox-dropdown-list-type of controls I use
>on forms. The rowsource for these controls is almost always an array which is built into the object as a property (taRowSource[1,1]).
>
>This control works as expected. When it gets focus, the background changes color and the list drops with the selected item highlighted.
>
>The form is a fairly complex one containing a pageframe with five pages. On these pages are other pageframes having five or six pages. The total pages on the form at last count was 21. I'm not sure this relevant, but this is the background of the control I am having trouble with.
>
>The particular control is derived from the combolist class. It is a critical control since its value determines the values of a large number of dependent controls. In the interactivechange() event I have placed a fairly lengthy list of instructions to calculate the values of the dependent controls. The length of this code seems to be the problem.
>
>When the control receives focus, the list drops and closes again when a new
>selection is made. So far, normal behavior. But the new value does not display in the control's text field.
>
>This occurred right after I had added some new instructions to interactivechange(), so I figured I had a bug in the code. I could not find it
>though, so I merely commented out the new code, and the control worked fine.
>Puzzled, I uncommented the new code, and commented out another block of code.
>The control worked fine.
>
>Turns out tht all the code worked. There was just too much of it. I was, in fact able to identify the precise line of code at which the control stopped
>displaying its value. It was just one line too many.
>
>Please understand that the value does change and the new value is correct. It
>just does not display.
>
>About 18 months ago I had a similar experience with VFP3. In this case calls
>to an object outside of the form (the App object, in fact) in the combolist init() handler prevented the list from dropping. MS acknowleged that it was a bug and was able to replicate it. This one appears to have been fixed in VFP5.
>
>One obvious solution is to move the code from interactivechange() to lostfocus() and perform the extensive calculations only after the control has lost focus. There are a number of design reasons why I would prefer to have the calculations made while the control still has focus. I suppose I should add that the calculations are not actually performed in this control. The code in the interactivechange() handler calls methods in other controls which perform the calculations.
>
>The problem can be replicated. Even overloading the interactivechange() event of a control derived directly from the VFP base class shows the same effect.
>
>I have tried your suggestion to set .value = .value, but this does not work. I also tried .displayvalue = .value. This works most of the time, but not always. I confess that I am truly hornswaggled by this.
>
>Hence my request for any information on how the combobox interactivechange() event actually works. It appears to me that it is one some kind of time limit so that if the time expires the control's display does not update.
>
>Any enlightenment from anyone would be greatly appreciated.

You made really complex investigation and it's really difficult for me to make same valid proposals. The basic reason that I never use array as Rowsource. IMO, cursor is more reliable source just because you can always work directly with record pointer there, i.e. if you move pointer to another cursor record you firmly know what is Combo.Value(DisplayValue) now and, if something going wrong, you can confirm the value by This.Value=Cursor.Field1. So far, I've never encountered combo problems which wouldn't be resolvable and/or understandable. Sorry, that I could not provide much help on this topic.