VF9 textbox editing issue

[mstrwayne]

Im trying to display the value of a field in a textbox and allow the user to edit it, then I have a save button that will update the table. I do not want to bind the field to the textbox. I want strict control over the data being modified by the user.

I declare public variable aa
aa =pwacct01.addr1
thisform.text4.controlsource= "m.aa"
also tried
thisform.text4.controlsource= m.aa

at run time the correct value is displayed in the text box, when textbox is clicked in user only can change the first character right arrow key will not move the cursor past the 1st character. I have the maxlength=0
I have spent hours searching this out and from everything I have read the above should work but it does not. No binding the field to the control is not an option. I ne4ed to bind the memory variable to the control.

 

[GriffMG]

Not sure what you mean, but I would tend to do something like this, assuming there is a grid, which is bound to table:

in the grid's afterrowcolchange event

thisform.text4.value = pwacct01.addr1
thisform.text4.setfocus

and then in the LostFocus event for the text box

select pwacct01
replace addr1 with thisform.text4.value

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 not good for you. ​

 

[Mike Lewis]

Welcome to the forum.

I strongly recommend that you learn about buffering. It will allow you to do exactly what you want, that is, to have "strict control over the data being modified by the user". Buffering is the normal way of solving this type of problem.

When your data is buffered, you can validate it in any way you like, including rejecting it entirely. You can also modify it. Nothing is written to the underlying table until you explicitly tell it to do so (using TABLEUPDATE()).

There's a lot of information about buffering in the Help file. I suggest you read that, then come back if you have any specific questions.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Hi

I do not want to bind the field to the textbox. I want strict control over the data being modified by the user.

Would you be able to specify why this is requested by you?
The binding of a field to the rextbox (controlsource) has little to do with your ability to have control over the data being modified.
Like Mike stipulated, you have full control what is / what should not be in your data.
Regards,
Jockey(2)

 

[TamarGranor]

I'm with the others. Turn table buffering on, set the ControlSource and you'll have all the control you need.

Even if, for some reason, you choose not to use buffering, get away from public variables. They're incredibly dangerous. If you want something that's visible throughout a form, add custom properties to the form.

I just shared this article here yesterday, but it seems relevant again:

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

A few things there are out of date, but the basic ideas are still solid.

Tamar

 

[GriffMG]

Global variables are not 'incredibly dangerous' - they might be many things, but they aren't dangerous in and of themselves.

Sure if every index you use is a public i, you will almost certainly have issues. If you use a naming convention for your global
variables so they are clear and your risks are no worse than anything else. All applications have some kind of global stuff, constants
_screen, _cliptext, and other stuff. The trick is not using the same NAMED variable, property, function, procedure for more than one thing.

Most of us use i or x or y for an index from time to time, and it's fine so long as it is private, or local, and has limited scope, but we
all have an application name, a current path, a data location, a version number which is 'nearly global' if not in fact so.

Potentially dangerous, not 'incredibly dangerous'.

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 not good for you. ​

 

[Dan Freeman]

Sure if every index you use is a public i, you will almost certainly have issues. If you use a naming convention for your global
variables so they are clear and your risks are no worse than anything else. All applications have some kind of global stuff, constants
_screen, _cliptext, and other stuff. The trick is not using the same NAMED variable, property, function, procedure for more than one thing.

Most of us use i or x or y for an index from time to time, and it's fine so long as it is private, or local, and has limited scope, but we
all have an application name, a current path, a data location, a version number which is 'nearly global' if not in fact so.

You have simultaneously given an example of why not to use them and exactly the same reason to use them. This is justification for sloppy programming.

When I write code, I can't remember a time when I've used a variable named x or i. AT THE VERY LEAST it will have a naming convention that clarifies scope and data type, and as soon as I see how silly lnX looks as a variable name I give it a more meaningful name. It's just not worth the hassle several years (or hours) later trying to figure out what the original programmer meant. (And simple counter or index variables need to be LOCAL anyway, so there is no relation to PUBLICs.)

Do it the right way the first time.

As far as public variables go we used to use them because we had no other choice and many adopted programming practices that relied on them. Unfortunately when much better ways to work presented themselves some people stuck with the old habits that can now wreak havoc.

Public variables should be avoided. (The exception, since I never say never, is maintenance work on old code.)

 

[GriffMG]

Probably right

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 not good for you. ​

 

[dbMark]

And have you tried searching for X, Y or Z? For example, for smaller LOOPs without calls elsewhere you might get away with ii or jj or some doubled up name, but single letters introduce too many problems. For example A-> to M-> are valid usages, you don't want needless confusion or accidental miscoding. Also, if scope isn't declared then it will be PRIVATE and visible/editable in called functions and procedures.

 

[Dan Freeman]

For example A-> to M-> are valid usages

More specifically, a-j and m are valid aliases.

You can actually use them for variable names if you religiously always use the memory variable alias. People used to think this was a bug:

a = Createobject('form')
a.Show()

It throws an error because it's looking for a "show" field in workarea a. The workarea always takes precedence over the variable.

Properly scope that memory variable, though, and it works just fine:

m.a.show()

It is technically correct.

<pedant/>

What are the odds you'll *forget* that m. just once and it will blow up in 5 years in ways that make you chase your own tail to debug?