How to clear all data from a form? 1

[SitesMasstec]

Hello!

After executing a form it comes with previously typed content in some text boxes.

How to avoid this?

Thank you,
SitesMasstec

 

[Mike Lewis]

Ok, let me have a shot at interpreting that.

Do you mean that you run a form, type some text in the textboxes, close the form, and then run it again - and the text that you typed is still there?

If that's what you mean, then it must be because you saved the text somewhere. Either you explicitly saved it to the fields in a table (or, less likely, into public variables), or the textboxes were bound to fields or variables (via their control sources).

If that doesn't help, can you please try and explain your problem more clearly. It's very hard to understand what you have in mind, based on the vague information you have given us.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[SitesMasstec]

Hello Mike!

Yes! The fields were bound to public variables! Now I corrected it;

But is there a way to explicity clean the variables inside the FORM.Init event?

Thank you.

 

[Mike Lewis]

Yes, you can clear public variables from the form's Init. Just set them to zero or an empty sring, in the usual way. By why would you want to do that? I can't think of a situation where binding a form's controls to public variables makes sense. Given that you want the values only to be visible within the form, it would make more sense to bind the controls to form properties.

It's difficult to answer your question without knowing more about the design of your forms. But, in general, I would say that you probably need to review the way you are storing data within your application.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

For such cases you could also design a form with empty controlsources. Your values will then simply be in each control.value, the value properties become your "variables".

Form properties, as Mike suggests, are one way to bind to something. Even nicer is an object with all the properties a record would have, such as a record scattered to an object, for example use any of your tables, popsition on a record and do SCATTER NAME oRecord MEMO. The object oRecord then will have field names as properties.

This is quite oldschool, as SCATTER MEMVAR is very old, older than buffering. But in this case you don't pollute the nametable with names already given to fields, you create one object variable with all fields as properties. You can then INSERT INTO sometable FROM NAME oRecord, you can also (again oldschool) GATHER NAME oRecord.

Bye, Olaf.

 

[TamarGranor]

What I don't see anyone saying so far is that, for the vast majority of VFP forms, you should bind directly to fields and use buffering to provide you a way to decide whether to keep or throw out the changes.

Tamar

 

[Olaf Doschke]

There are forms without the need to bind to anything, for example a form for entering filter conditions.

In cases of editing data the usual way of binding to DBF/updatable view/cursor buffered is the way to go, yes.

Bye, Olaf.

 

[Dan Freeman]

What I also don't see anyone saying is that this is a very good reason NEVER to use public variables!