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
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only