Bill,

Thanks for the DETAILED explanation. I truly appreciate it.

I will file the message and, perhaps some day, look at the problem myself in detail. So far it qualifies as "wierd".

Cheers,
Jim N

>Hi Jim,
>
>Can't help you much here. I can only tell you the factors involved and what I observed.
>I started with the inGrid class (see files section if you don't know what it is).
>Brief description in case you don't know what it is. A txtBox class that when put into the columns of a grid
>allow incremental searches in each column of the grid. Each column supporting a different order.
>The GotFocus event would determine if the column had changed or was still doing a seek in the same column
>and change the order of the RecordSource if necessary.
>A KeySeek event would do the actual seek.
>
>All I wanted to do was to make it capable of handling 2 (or more) tables in a 1 to many relationship, and change
>orders to an index in the child table. Cetin worked on it before I did (I was hoping someone had already done
>it). I then adapted it to handle more that 2 tables.
>
>In the GotFocus event I changed the code to relase all the relations and set new ones with a different parent
>table. After I got the order changing tweeked, I moved on to the seek in the KeySeek event. I immediately
>noticed, that it would not seek. I would type a letter and nothing happened. I eventually tracked it down
>in the KeySeek event that the Recno() of the parent table was being CHANGED BACK to 1 at some point in the code.
>
>I discovered that if I removed the relationship(s) to the child table(s) that everything worked fine.
>
>During debugging, I had 2 wait statements showing me the Recno() of the parent table, they showed me 2 different
>#s. The first one had the correctly seeked record, the second one had the record that the cursor was on before
>doing the seek (#1). I moved the wait statements closer and closer together, until they were right next to each
>other. This was when I hollered for help.
>
>I continued working on it. My first solution was to just store the correct Recno() to a variable and Goto it
>after the Recno() changed. Unfortunately I discovered that that caused the GotFocus and LostFocus to trigger
>twice (I think that's what was happening). inGrid was dependant on them only triggering once, (it set a flag
>in the KeySeek event that was cleared in the GotFocus. If the flag was already cleared, it assumed the column
>had changed).
>So I removed everything and started adding them back in one at a time. I also started moving everything to
>a method at the grid level (I never liked using the txtBox.GotFocus to change the order).
>Everything was going fine.
>The last thing I put in was the code to replace the header caption, and that's when this problem reared it's
>ugly head again.
>
>I moved the Header.Caption replacement back to the txtBox.GotFocus event and everything seems to be hunky-dory.
>
>In conclusion, I don't think you can (1) do a seek on a 1 to many relationship and (2) change the caption of
>the header in the same method anywhere in the workings of a grid, either at a grid level method or a control
>level method.
>
>I haven't studied it any more. I'm way behind where I want to be because of this problem, so I moved on once
>I got it to work.
>
>Bill
>
>
>
>
>>Bill,
>>
>>I *thought* I was following along well, but I seem to have missed something along the way. Hopefully, you can clarify for me. . .
>>
>>You had two WAITs in a row with ABSOLUTELY *NO* intervening code, and one rreported the correct RECNO() while the second always reported "1".
>>You dissected/reassembled the class (or whatever) bit by bit and all was well *until* you added the bit to change the Header.Caption. It was at this point that the "problem" reared its ugly head.
>>
>>I have a 'disconnect' between
>>1) two consecutive lines of code, *both* of them WAITs;
>>2) the changing of Header.Caption.
>>
>>. . .WHEN does the Header.Caption execute in relation to the two WAITs???
>>
>>Finally, have you found the *CAUSE* yet? [ I know you've found a possible connection, but have you come up with any "rule" or 'standard' which supports the observed behaviour? ]
>>
>>Cheers,
>>Jim N
>>>>>I figured out what was triggering the error.
>>>>>1st, so as not to confuse those that didn't understand the problem. The Recno() that was being changed for no
>>>>>reason was in the PARENT file. I never even bothered looking at the Recno() in the Child(s) file. Everything
>>>>>worked fine as long as I had no relations set.
>>>>>
>>>>>I rebuilt the method a bit at a time, (moving it to the grid level instead of the control level also)
>>>>>The very last thing I put in was to change the Header.Caption of the column. As soon as I did that,
>>>>>the Recno() in the PARENT table kept getting pulled back to where it started in the procedure.
>>>>>I moved the caption change to the focus of the control and everything works fine (knock on wood).
>>>>>
>>>>>Thanks for all the input.
>>>>>
>>>>>Bill
>>>>Nice to see the solution so I can remove the message about inGrid problem (I read it hours ago and was a deadend).
>>>
>>>You mean you're not going to figure out why changing the header caption in the same method with the seek causes
>>>the Recno() to change?
>>>
>>>I'm joking.
>>>
>>>Bill