You already have the answers you need. Going from GET to CLASS is not going from OLD (legacy) Foxpro to Visual Foxpro Code.
If you take the Visual of Visual Foxpro serious, then use the form designer.
If you have a form with textboxes, you can't just get their value after a READ finishes, but at any time with their .value property. Furthermore, you can bind a textbox to data, so you could even spare the variables holding these values. In the best sense of 3-tier architecture programming, you'd bind to an updatable view or cursoradapter or passthrough query cursor, use buffering and more, it's a steep learning curve to get there.
So I assume you still would want to go for legacy code. Using CLASS vs GET won't get you forward, though. You instead take a step backward, because you then have textboxes not storing their value to a variable, the only thing that advances is using a certain control class. That won't make any difference, though, if you just use the base class Textbox, GET uses that too. So overall and again said you're taking a step backward with this. Just because you use CLASS you don't enter the OOP development paradigm.
To explain a little: The way CLASS seems to work - I never used it, I was entering VFP6 and used WinForms controls and the visual designers ever since - is naming your controls, not a variable. So you don't have your textbox value in abc1, abc2, and abc3. You only have it in the textboxes named abc1, abc2, and abc3, and that is addressed as you already were answered by [tt]formobject.textboxname.value[/tt].
You have to know what formobject the @CLASS command adds the textbox to. If you don't specify something it will be the active form, I guess. Anyway, you don't get anywhere better changing what you had with GET to CLASS. What's even worse is READ. You don't have and need READS in Visual Foxpro applications, you only have a READ EVENTS as the single place for processing the overall event loop if nothing actually runs and the application os waiting for any event, timer, mouse moves, clicks, anything. Most of the time a Visual Foxpro application will wait for user input in the state of the program pointer being on that code line READ EVENTS.
You get your workflow by designing forms with controls in logical display positions and tab order, maybe also forcing a certain sequence of using them by disabling them (control.enabled=.f.) until some previous control has got its value. I don't think your question is about that, though.
The TLDR answer is: Stay with GET if you want that to work the way it does. If you want to use modern Visual aspect of the Foxpro language, then do so, use the form designer, create SCX (in the project manager under Documents/Forms) or classes of VCX (in the project manager under Classes. Forms are easier to comprehend and test, when you don't introduce any prerequisites like a goApp application object you can start a form from the designer using the ! toolbar button of the standard toolbar and have the form running. The form has all visual design of what you want to achive, you act on the controls, you can open up data tables within the forms data environment you can easily drag single fields or whole tables from the data environment to the form canvas to get bound controls, etc. That's not the ideal way in concordance with OOP and 3-tier architectures, but its rapid development, for sure, and good enough, much better than any old program screen logic can ever be.
Bye, Olaf.
Olaf Doschke Software Engineering
