>The problem was we had an array whos elements were used in scatter gather. But, the lights came on and I wrote a quick little scanner that goes through all the objects in the form and puts their controlsorce in an array. Then we programattically replace the calls to objnum with calls to a function that looks up the object based on its controlsorce and returns the object for use in setfocus. That works.
>
>The ohter dodad is a cuteobj.value which can be used in place of _curobj in an assign. This wakes up when the value changes and uses the array of values with the array index returned to it from our function and does the setfocus.
>
>So we can replace code like
>store objnum(array[payfield]) to _curobj with
>store getobjnum("array[payfield]") to cuteobj.value and get a setfocus.
>
>Makes the program to go through all the code easy to write!
>
>Unfortunately, it will drive any new programmer insane. But, you have to be insane to work on this 2.6 to 6.0 sp3 project anyway. That is why I work so well on it!
>
>Thanks for the help.

Anytime. Actually, what concerned me was a reference that I believe you made in the other thread to "Q&D". It's my experience that while such things are almost always very "Dirty", their implementation and especially maintenance are seldom "Quick". Several years ago, I had folks coming to me for these sort of solutions, and I simply said, "No! I don't do that." The problem usually ends up being that, while we intend to get back and re-engineer (as should be done with any move from FPW to VFP), too often the "Q&D" solution remains in production, and causes far more headaches than it should. The end result invariably is that you spend far more total time with the "Q&D" than you would if it had been re-engineered in the first place.