>>These are a pain to track down. The form refresh calls the refresh of the contained objects. Are these based on a subclass of the base classes? Could you put some line of code in the Refresh method of his base class. That might cause it to stop on that code for the control in question. Don't know, really, because I have not run into this much and haven't tried this, but it came to mind.
>>
>>>>I was asked by another developer who has a problem in their system and can't track it down. He is getting an error during a Thisform.Refresh().
>
>Hi all,
>
>I FOUND IT... And what a bugger it was... Here was the scenario for y'all
>There was a VIEW defined in the database... The VIEW was manually opened when the form loaded. As the results of another combobox control changed, it forced a requery of the VIEW, but the second level combobox didn't recognize it... ie: first combobox was a "Type" of transaction... the second combo was a "SUBTYPE" of the "TYPE" transaction. and obviously, each type could have its own subtypes.
>
>Anyhow, since the view was manually re-queried, and the second combobox was set to that alias as the row source, it (the combobox) got mentally out of synch with the view thinking it originally had 1 subtype from the first transaction, then when skipping to the next transaction, the type changed and had a list of 5 subtypes... now Record out of range.
>
>TO FIX IT...
>After the manual requery of the underlying view was refreshed, we issued a
>Thisform....combobox.Requery()
>
>The Requery basically "refreshed" its mental image of the cursor to the NEW cursor version, and proceeded hapily with the rest of the code...
>
>Happy bug hunting ...

Glad you found it :) And my first guess was right, that it was combobox related.

BTW, as usual, the similar problem is now discussed on a Russian site. I gave a link to this thread earlier on.