Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
What's moving my Recno() ?
Message
From
05/01/1998 19:25:47
 
 
To
05/01/1998 15:31:16
General information
Forum:
Visual FoxPro
Category:
Troubleshooting
Miscellaneous
Thread ID:
00069341
Message ID:
00069688
Views:
54
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
Bill Morris
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform