Get Varible Class 1

[ariswan2007]

Anyone can help me...

I have code below :

@ 01,02 CLASS Textbox NAME abc1
@ 02,02 CLASS Textbox NAME abc2
@ 03,02 CLASS Textbox NAME abc3
read

How to retrieve or view values that are filled in from the textbox class for names abc1, abc2 and abc3

thank's

 

[TamarGranor]

You shouldn't be using @CLASS. It's there for some sort of backward compatibility of something. If you're working on Visual FoxPro (which you obviously are, because @CLASS didn't exist in FoxPro), use the Form Designer to create forms.

That said, if you insist on doing it this way, try ThisForm.abc1.Value, etc.

Tamar

 

[Mike Lewis]

Of course, I agree with Tamar - and I'm sure everyone else here will as well.

But if you must use those old @ commands, you would do better to use[tt] @ ... GET <variable>[/tt]. That way, the variable will contain the required value after the READ.

[tt]@ ... CLASS[/tt] only makes sense when used in the context of a form. You could try this:

oForm = CREATEOBJECT("Form")
oForm.Show()
@ 01,02 CLASS Textbox NAME abc1
@ 02,02 CLASS Textbox NAME abc2
@ 03,02 CLASS Textbox NAME abc3
READ

But even that is not much help, as you still have no way of referencing the objects.

Bite the bullet and learn how to use the form designer.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

I also found this code in Hackers Guide to VFP 6. It seems to work, but I don't know if it will help.

ON KEY LABEL F11 CLEAR READ
oForm = CREATEOBJECT("Form")
oForm.Show()
@ 10,10 CLASS "TextBox" NAME txtMyTextBox
oForm.PageFrame1.Page1.txtMyTextBox.Value = "Ta-da!"
oForm.PageFrame1.Page1.txtMyTextBox.BackColor = 255
READ  && press F11 to get out of this weird READ

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

I do sometimes still use @ get, but only for what I would call 'widgets' - quick and dirty programs to do maintenance things on large systems.

They were revolutionary back in the day, but now - use the form designer.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[ariswan2007]

Thank you for the response given, let me try to explain in the previous question in more detail:

OLD-FOXPRO CODE
===============
**STORE VARIABLE**
store space 50 to abc1,abc2,abc3

**GET VARIABLE**
@ 01,02 GET abc1
@ 02,02 GET abc2
@ 03,02 GET abc3
read

**GET/READ VARIABLE**
I fill/put in the variable as follows : abc1 with JHON, abc2 with MIKE and abc3 with ERICK
And then I get a new variable from the @get... above like this :
name1=abc1
name2=abc2
name3=abc3

? name1 -> result JOHN
? name2 -> result MIKE
? name3 -> result ERICK

Please your advise, how to convert "Old Foxpro Code" in "Visual Foxpro Code" by using the class textbox below :

VISUAL FOXPRO CODE
==================
@ 01,02 CLASS Textbox NAME abc1
@ 02,02 CLASS Textbox NAME abc2
@ 03,02 CLASS Textbox NAME abc2
read

.....
.....
.....

Thank's again for any help

 

[Olaf Doschke]

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

https://www.doschke.name

 

[Mike Lewis]

There is absolutely no point in converting [tt]@ ... GET[/tt] to [tt]@ ... CLASS[/tt].

Instead, do one of the following:

1. Keep your old code (with[tt] @ ... GET[/tt]). It will work perfectly well under any version of VFP. No hassle. No work for you.

2. Abandon your old code and fully embrace the full object-oriented features of VFP, in particular the form designer. This will mean a lot of work, and a lot of learning, but will give you the most robust and flexible system, and will improve your programming skills into the bargain.

Using [tt]@ ... CLASS[/tt] is the worst option. I falls half-way between the above two. It has the disadvantages of both, but with no benefit. My adivice would be to wipe it out of your repertoire.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Just to showcase you won't get forward with this:

Clear

@ 01,02 CLASS Textbox NAME abc1
@ 05,02 SAY _screen.pageframe1.page1.objects(1).name
_screen.pageframe1.page1.abc1.value = "test"
@ 02,02 CLASS Textbox NAME abc2
@ 06,02 SAY _screen.pageframe1.page1.objects(2).name
@ 03,02 CLASS Textbox NAME abc3 
@ 07,02 SAY _screen.pageframe1.page1.objects(3).name

Read
@ 08,02 SAY _screen.controlcount

While the textboxes are created, @CLASS also creates a pageframe and page of that pageframe, after the read the controls are gone, so you don't get the values out after READ unless you bind them to variables. The construct of a pageframe also makes it something you couldn't easily mix into an existing form, you can only stay in the domain of legacy code this way.

If you have to maintain a legacy application as is, that's your only real chance, you won't make a transition this way and while I see you could address data binding to variables before the READ, the overall construct is still not leading you anywhere good, even if the real deal you have in mind is using specific textbox classes that do something for you visually or by filtering input, or doing whatever actions on events. I don't see this as a valid transition to VFP forms via using control classes, even if you go for more than base classes. When you want to start using control classes, then also use forms.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

If your real problem is @GET textboxes not appearing on screen, that's a well known buggy feature of how VFP addresses rendering forms with Windows themes, you can turn that off with _screen.Themes = .f.
Also see thread184-1789196

You can at least keep the visual appearance of a legacy app as good as it gets on Windows, no need to switch to Textbox or any other winform controls of VFP.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[ariswan2007]

Thank you for the response
It's true, that Visual Foxpro will be more effective when using OOP development using form, vcx, class, etc. I am still actively developing applications using the old-foxpro source code, and until now it still exists, it's easy to custom for businesses, even though it's a bit old-fashioned or taking a step backward with this.

I just want to find info on this expert forum, for a conversion solution between "old-foxpro code" and "visual foxpro OOP development code". It seems that my hopes have not been answered.

Okay, thanks again for any help.
Regards

 

[Mike Lewis]

I just want to find info on this expert forum, for a conversion solution between "old-foxpro code" and "visual foxpro OOP development code". It seems that my hopes have not been answered.

Excuse me, but that's not what you asked. You asked how to get [tt]@/CLASS[/tt] to work. That is in no way the same as asking how to convert an application to OOP.

I think you got a perfectly good answer to your question. To repeat: [tt]@/CLASS[/tt] basically doesn't do anything useful. There is no easy way of using it as an alternative to @/GET (which was what you were asking). It is not a first stage in the conversion to OOP.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, look back what I found out. @..CLASS generates a pageframe1 with a page1 and the control you specify. This is a textbox, so you can set its controlsource, for example, even if @..CLASS has no further parameters or options. You could know better than me.

As Mike and Tamar also already suggested using forms will be the better solution, you can take that for granted.

I haven't tried and looked up how you could specify a class of a VCX, so you could really also make every essential step in the init of a control class. It's still only giving very limited options of the whole possibilities of creating forms when you're able to use controls including all code of its methods and events. single controls don't give you all the options of a form class hierarchy, business logic objects, etc.

If you still think this is a good start, you already have your advice, the rest is simply as you like in control class code. You also already know after the READ the pageframe1 and its page1 and all its controls are gone, so all you do in the controls should immediately be stored by the control class binding (controlsource). I fear that'll fail for at least one of the controls as. for example, a control only stores its value back to its controlsource when the valid event returns true and that's only triggered by form focus change. You might get that because the READ only ends with an ENTER and also in normal forms you could SET CONFIRM ON so an ENTER actually triggers to store the value.

One last tip, that you might not need: VFPX on GitHub offers a help replacement including descriptions of the legacy commands:

https://github.com/VFPX/HelpFile

I'd not consider it a good idea to change from @..GET to @..CLASS, though. Bite the bullet and create forms, full forms.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name