Where do I declare variables in my form? 1

[dale3972]

Hello again. Long time 2.6 user and trying to convert my program to visual 9. Thanks to the generous help with my first thread, I have made this:
I create a form. I stretched a four tabbed page frame over it and labeled the tabs: Case, Defendant, Merchant, Payment. On each of these page frames I have copied the fields and buttons from my old program and modified them for VFP. When I compile all is looking good. Now I am adding data and need to know where to put my variables:

SELECT wc_case
SCATTER MEMVAR MEMO

* Declare and initialize merchant variables
private me_name, me_id, me_addr, me_city, me_state, ;
me_zip, me_phone, me_contact

m.me_name = merchant.me_name
m.me_id = merchant.me_id
m.me_addr = merchant.me_addr
m.me_city = merchant.me_city
m.me_state = merchant.me_state
m.me_zip = merchant.me_zip
m.me_contact = merchant.me_contact
m.me_phone = merchant.me_phone

* Declare and initialize defendant variables
private name, id, address, address2, city, state, zip,;
race, sex, dob, height_ft, height_in, ssn, hair,;
eyes, license, telephone, employer, emp_phone,;
weight, HISTORY
m.name=wc_writer.name
m.id=wc_writer.id
m.address=wc_writer.address
m.address2=wc_writer.address2
m.city=wc_writer.city
m.state=wc_writer.state
m.zip=wc_writer.zip
m.race=wc_writer.race
m.sex=wc_writer.sex
m.dob=wc_writer.dob
m.height_ft=wc_writer.height_ft
m.height_in=wc_writer.height_in
m.ssn=wc_writer.ssn
m.hair=wc_writer.hair
m.eyes=wc_writer.eyes
m.license=wc_writer.license
m.telephone=wc_writer.telephone
m.employer=wc_writer.employer
m.emp_phone=wc_writer.emp_phone
m.weight=wc_writer.weight
m.history=wc_writer.history
thisform.refresh


There looks to be so many places to put them. Do I put them in the Main form init event and refresh event. Or do I put them in the Frame section init event, etc. I have got errors on nesting too deep or too many variables. When I leave them just in one place, (the init event of the main screen), I get no errors but nothing changes when I run the program. The actual case data will change when I scroll next but the defendant and merchant data stays the same. I run the program that relates the id's to all the databases in the startup program. My main question is, because there are so many places to put the variables, Where do I put them?

Thanks again!

 

[Olaf Doschke]

You don't use variables, you use the controls CONTROLSOURCE property, you specify tablename.fieldname for textboxes, for example. Then that field is displayed there and whatever you change is stored back to the field, without any further code, no SCATTE, no GATHER anymore.

Bye, Olaf.

 

[Mike Lewis]

What do you mean by "where do I put the variables?". In what sense do you want to "put" them?

And what specific variables are you referring to?

In general, you declare a variables (as LOCAL, PRIVATE, etc.) in your method code. The normal declaration is LOCAL. That means that the variable is only in scope in the method in which it is declared. To make it available to other variables, you pass it as a parameter. Does that help at all?

If you want a value to be available to many methods in a form, you should make it a property of the form. You do that in the Form Designer. Go to the Form menu, and then select New Property. Type a name for the property. To reference the property in your code, prefix it by the THISFORM and a dot. You can do the same at class level, but you do so in the Class Designer, and you reference it as the classname plus the dot.

I could give you a lot more advice about dealing with variables, but it's a waste of time unless you can clarify exactly what you want to know.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dale3972]

Thanks for the replies. In old 2.6 I used the genscreen tab system. I had four databases and four tabs: Case, Defendant, Merchant, Payment.
The master database was Case. When the user clicked on the Defendant tab, he or she would be taken to that unique defendant as it related to that case(a seperate database). I had to declare all the variables for the fields in the Defendant Tab and Merchant tab in the code on the first screen- case.

So when they clicked on the merchant tab and see the merhcant information, it would actually be the information that I made variables. Merchant.name was m.name and merchant.me_id was related to case.id.

This visual foxpro, I must say, is a total complete different beast, then the old 2.6 I was used to and should have evolved it years ago.

Its a worthless check system used by District Attorneys. Walmart ( a merchant ) could have several cases as well as several defendants.

So that is the way I had to do it in GenscreenX tab system. When I opened the program in 2.6 the first form I ran had this in the the - layout - setup code :

*:ALL3D
*:SCREENSET SCN2b
*:SCREENSET SCN3a
*:SCREENSET SCN4d

*:TABTITLE Worthless Check File
*:TABLABEL Main Case
*:TABMESSAGE 'Main Case Screen'
*:TABMARGIN 0.25
*:TABSCXMARGIN 0.25
*:TABHEADER 0.25
*:TABSCXHEADER 0.25
*:TABFOOTER 0.25
*:TABSCXFOOTER 0.25
*:TABZOOM
*:TABNOCENTER
*:TABNOCLOSE

PRIVATE warrloc, how_paid, visit_btn;
m.visit_btn = 2
m.how_paid = 1
m.warrloc = wc_case.warr_loc

SELECT wc_case
SCATTER MEMVAR MEMO

* Declare and initialize merchant variables
PRIVATE me_name, me_id, me_addr, me_city, me_state, ;
me_zip, me_phone, me_contact

m.me_name = merchant.me_name
m.me_id = merchant.me_id
m.me_addr = merchant.me_addr
m.me_city = merchant.me_city
m.me_state = merchant.me_state
m.me_zip = merchant.me_zip
m.me_contact = merchant.me_contact
m.me_phone = merchant.me_phone

* Declare and initialize defendant variables
PRIVATE name, id, address, address2, city, state, zip,;
race, sex, dob, height_ft, height_in, ssn, hair,;
eyes, license, telephone, employer, emp_phone,;
weight, HISTORY
m.name=wc_writer.name
m.id=wc_writer.id
m.address=wc_writer.address
m.address2=wc_writer.address2
m.city=wc_writer.city
m.state=wc_writer.state
m.zip=wc_writer.zip
m.race=wc_writer.race
m.sex=wc_writer.sex
m.dob=wc_writer.dob
m.height_ft=wc_writer.height_ft
m.height_in=wc_writer.height_in
m.ssn=wc_writer.ssn
m.hair=wc_writer.hair
m.eyes=wc_writer.eyes
m.license=wc_writer.license
m.telephone=wc_writer.telephone
m.employer=wc_writer.employer
m.emp_phone=wc_writer.emp_phone
m.weight=wc_writer.weight
m.history=wc_writer.history
SHOW GETS

I hope I am making some sense. I am still troubleshooting though and will try those replies.

 

[TamarGranor]

The big answer here is that you don't use SCATTER/GATHER MEMVAR in VFP. Buffering makes them unnecessary and makes the handling much easier.

Try this article to get you started:

http://www.tomorrowssolutionsllc.com/Articles/Learning Visual FoxPro—The Top Ten List.PDF

Tamar

 

[Olaf Doschke]

In the first place this even hasn't got anything to do with buffering. That's a topic one sep ahead. First comprehend the controlsource concept of the new visual controls.

As already said you don't need variables anymore. No code, really just one setting per control.

Do the following, please:
1. Create a new form (SCX)
2. Choose DataEnvironment from the context menu of the form editor.
3. Choose Add from the context menu of the data environment.
4. Pick a table, no matter if 2.6, free, database table, any dbf
5. From the small window listing the field names of the table pick one char field and drag it to the form canvas.
6. On the form a label and a textbox is added. Select the textbox only
7. Look at the property window (if it's not open, ALT+W, then ALT+P will open it), especially in the data tab. The controlsource of the textbox is set to tablename.fieldname
8. Start the form with the ! in the standard toolbar

The value of the field is shown in the textbox, you can edit it and when you close the form and browse the table the change is saved.

So you don't need to pull data from the current record to variables with SCATTER, bind edit fields to the variables, GATHER the variables to the record to save it. Instead you do nothing (in the first place).

So, isn't that easier to do?

Now drag the whole table from the data environment to the form. Instead of a control for a single field a grid control is generated. Start the form again. Now you can pick a record and then edit the single field in the textbox.

Bye, Olaf.

 

[dale3972]

Much appreciate the replies! Thanks very much! I think I am trying to over analyze it. My goodness!, it can't be that easy?!

What I did after converting each screen to VFP was copy and paste the controls to each corresponding Page Frame. Now, from what I understand, all I need to do is go to each control and check its properties and make sure the control source points to what it is supposed to be (merchant.name).

If I run into problems, I will just start over and do from scratch per Olafs instructions.

And thanks for the link on the article. I will read that too.

Hmmm, I have been living in the past for so long. This is a huge step up from 2.6

Thanks so much again!

 

[Olaf Doschke]

There's more to it for comboboxes, for examples. Also in my example once you added the grid and use to pick the current record, you see picking the record does not cause the textbox to show this record's value. Only when you click into the textbox it's refreshed. That can be done with THISFORM.REFRESH() in advance. That would need to go into the grid object in its AfterRowColChange() event.

The topic buffering is important, if you used the variables as a buffer, if the user could save or cancel the change, if you only gathered the variables back when the user clicked a save button. With the new controlsource the edited values go right into the table. Table buffering is buffering those changes until a commit of them via TABLEUPDATE() function.

It's not necessary, but can be helpful in complex situations, eg when two fields need to comply to a rule. Famous example: A start date needs to be before an end date. In editing you might have a situation where that rule is broken, but it won't matter, typically that break is temporary only, since the user changes both dates anyway. So that's nothing, which should trigger such a table rule too early. With variables that's no problem, since you only store back the changes with a final GATHER. The buffer, which saves pending changes, but won't yet change the DBF, does allow you to do that without scatter/gather to/form variables.

Table rules are not the only reason you might want to start use buffering, you also lower the network traffic to the dbf files in multi user applications sharing data. With buffering you may have up to three different values for a certain field of a record: the CURVAL(), what is currently stored in the DBF file, the OLDVAL(), what was originally in the field, before the user began editing and the local current value, what is in the buffer, simply addressed by fieldname or tablename.fieldname.

Bye, Olaf.

 

[Dan Freeman]

I think I am trying to over analyze it. My goodness!, it can't be that easy?!

<chuckle>

A lot of us felt that way when we first encountered VFP.

Don't worry. There's other stuff that's difficult.

 

[dale3972]

Thanks Olaf and everyone else for all the help! I think I have enough to go on from here. I made the appropriate changes to one of my page frame screens and it appears to be working okay. Once I get it to a point where I think the new VFP application is usable, I will have my clients troubleshoot it on there system while being able to still fall back on the old 2.6 version, until it is fully bug free.

Thanks again.

Dale French