Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How To Get Rid Of Error 1
- Thread starter alisaif
- Start date
Mike Lewis
Programmer
You need to give a lot more information. How on earth are we supposed to guess what the error is, or where it occurs?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
- Thread starter
- #3
Koen Piller
Programmer
Hi,
Solution for this error is simple: instantiate the variable.
Koen
Solution for this error is simple: instantiate the variable.
Koen
Mike Lewis
Programmer
"Variable Not Found" means just what it says: You are referring to a variable that does not exist. That could be because you misspelt the name of the variable, or that it has gone out of scope, or that you have not yet given it a value.
Note that simply declaring a variable does not cause it to exist. You have to give it a value.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Note that simply declaring a variable does not cause it to exist. You have to give it a value.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
- Thread starter
- #6
Olaf Doschke
Programmer
Still very vague information. What variables are missing? Something you bind controls to?
Are the errors appearing somewhat "mysterious" to you, as you don't know what variables the error is talking about?
Perhaps you just need to learn variable scoping once more and to a point, you really begin understanding it.
Your code must ensure every variable you need is existing, as you see for yourself, the user can't simply use the command window to create variables.
You're responsible for your code to work, not the user. You're like a car mechanic saying you fix a car while driving, while users can't. Well, you should provide a wholesome and working car.
I also know the error happens, when no variable is meant, but simply a controlsource is set to an expression. Up to VFP7, this worked and in 8 (could also be 9) this causes this error, often, when you don't put your controlsource expressions into outer brackets. So eg instead of setting some textbox.controlsource to field1+field2 you set it to (field1+field2).
But that would not occur just at runtime and not within your IDE. So most likely you address something not available at runtime, something a framework you might use creates during your development. Many frameworks have some base installations of managers when you start up VFP or when you open a project via a project hook. If it's that, you should refer to a manual of the framework you use about its initialization within the IDE and at runtime.
But if you fix any problems occurring while you test your code while it runs in the command window, creating variables, correcting values, then that will of course not stop erroring at the end user side. You have to put your manual corrections into your code.
Bye, Olaf.
Are the errors appearing somewhat "mysterious" to you, as you don't know what variables the error is talking about?
Perhaps you just need to learn variable scoping once more and to a point, you really begin understanding it.
Your code must ensure every variable you need is existing, as you see for yourself, the user can't simply use the command window to create variables.
You're responsible for your code to work, not the user. You're like a car mechanic saying you fix a car while driving, while users can't. Well, you should provide a wholesome and working car.
I also know the error happens, when no variable is meant, but simply a controlsource is set to an expression. Up to VFP7, this worked and in 8 (could also be 9) this causes this error, often, when you don't put your controlsource expressions into outer brackets. So eg instead of setting some textbox.controlsource to field1+field2 you set it to (field1+field2).
But that would not occur just at runtime and not within your IDE. So most likely you address something not available at runtime, something a framework you might use creates during your development. Many frameworks have some base installations of managers when you start up VFP or when you open a project via a project hook. If it's that, you should refer to a manual of the framework you use about its initialization within the IDE and at runtime.
But if you fix any problems occurring while you test your code while it runs in the command window, creating variables, correcting values, then that will of course not stop erroring at the end user side. You have to put your manual corrections into your code.
Bye, Olaf.
-
1
- #8
Mike Lewis
Programmer
There are two issues here.
First, you say "As and when I face this problem I instantiate the variable". I'm not sure what you mean by that. But if you mean that you instantiate it each time you see the error (from the command window?), that makes no sense at all. You should do the instantiation within your program, so that it happens automatically every time.
And, by the way, instantiation isn't the same as declaration. It's not enough simply to declare the variable, for example with PRIVATE or LOCAL. You've actually got to give it a value.
The other point is about the user using the task manager. Your user should never have to do this. Your program should have an error-handler in place that traps the error and then closes the application gracefully. That's such a fundamental point that you really need to do something about that even before you start debugging particular errors.
Final point: PLEASE whenever you post a question in this forum, don't waste out time by making us guess what the problem is, or by us having to repeatedly ask you to give basic information about the problem. We are not sitting behind you watching your screen. It's up to you to give us the information we need.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
First, you say "As and when I face this problem I instantiate the variable". I'm not sure what you mean by that. But if you mean that you instantiate it each time you see the error (from the command window?), that makes no sense at all. You should do the instantiation within your program, so that it happens automatically every time.
And, by the way, instantiation isn't the same as declaration. It's not enough simply to declare the variable, for example with PRIVATE or LOCAL. You've actually got to give it a value.
The other point is about the user using the task manager. Your user should never have to do this. Your program should have an error-handler in place that traps the error and then closes the application gracefully. That's such a fundamental point that you really need to do something about that even before you start debugging particular errors.
Final point: PLEASE whenever you post a question in this forum, don't waste out time by making us guess what the problem is, or by us having to repeatedly ask you to give basic information about the problem. We are not sitting behind you watching your screen. It's up to you to give us the information we need.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
- Thread starter
- #9
I think there is an anomaly here Mike
If you declare a local variable and do not assign a value to it - the variable exists and is Boolean, value .f.
If you declare a private variable and do not assign a value to it - the variable does not exist
If you declare a public variable and do not assign a value to it - the variable exists and is Boolean, value .f.
Regards
Griff
Keep [Smile]ing
If you declare a local variable and do not assign a value to it - the variable exists and is Boolean, value .f.
If you declare a private variable and do not assign a value to it - the variable does not exist
If you declare a public variable and do not assign a value to it - the variable exists and is Boolean, value .f.
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.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
Mike Lewis
Programmer
You're right, Griff. But I wouldn't call it an anomoly. The behaviour is well-documented and well-understood. I admit I over-simplified my explanation, but I don't think that detracted from my main point.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
It didn't you are quite right, maybe a curiosity rather than an anomaly.
B-)
Regards
Griff
Keep [Smile]ing
B-)
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.
I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
Olaf Doschke
Programmer
That's because you don't declare private variables with PRIVATE, you only hide already existing private variables with PRIVATE (quote help: "Hides specified variables or arrays that were defined in a calling program from the current program.")
Look into the options of his command, you can do PRIVATE ALL or PRIVATE ALL LIKE or PRIVATE ALL EXCEPT... that has a totally different nature than a declaration.
Bye, Olaf.
Look into the options of his command, you can do PRIVATE ALL or PRIVATE ALL LIKE or PRIVATE ALL EXCEPT... that has a totally different nature than a declaration.
Bye, Olaf.
Olaf Doschke
Programmer
Just a more general observation about private variable usage: If I am informed correctly in legacy Foxpro it was the norm to bind to variables you scattered and those most often were private variables. By nature of @GET paired with READ commands you were keeping the code stack and therefore all private variables alive and in scope. This is not the case with forms. Whatever you do in Init() or Load() only is on the call stack as long as the form initializes, once all the initialization events happened, and for sure after the call stack returns from the activate event of the form, all private variables generated in Load or Init or Activate are gone again.
If you want something with the same scope as the form, I already gave a lengthy explanation here in another thread this should either be a cursor within the form datasession or a form property. Those two things have the same scope and lifetime as the form, even if the datasession is not private to the form, that just means it lives longer than the form, the form then starts and uses an already existing current datasession, which it leaves open when finishing and releasing itself. So you don't need and you don't use private variables in VFP, they are completely unnecessary.
The way I sometime (perhaps) use them is when AUSED, AFIELDS, or any such array generating function generates an array as private variable, when I didn't previously declared a LOCAL ARRAY variable. There is no way to change that to producing local array variables by default, but the same goes about any variable you forget to declare LOCAL anyway.
To use the good old scatter, VFP9 offers using the NAME clause, you can scatter a dbf record to a form property you first create with Thisform.AddProperty("oRecord", CREATEOBJECT("empty")) and then populate with SCATTER NAME THISFORM.oRecord ADDITIVE which means you finally have THISFORM.oRecord.field1, THISFORM.oRecord.field2, etc. or you create all fields of a table as direct form properties by SCATTER NAME THISFORM ADDITIVE, creating THISFORM.field1, THISFORM.field2, etc., which I consider less clean, as you risk a namespace overlap of field names with any native or also user defined form properties already existing before the SCATTER.
With buffering you don't need to scatter at all, though, so the major way to bind forms to data is by making use of datasession workareas, no matter if cursor, DBF, updatable view, anything else I forgot. As long as it's not READONLY, this is a two way binding of controls. Scatter is handy, if you really want some such record object to be able to pass it from form to form even across several datasessions and such objects (based on "empty") can also be passed to COM OLEClasses to languages not aware of VFPs workarea concept at all. So the legacy "revival" of scatter allows to use modern concepts like linq with collections of objects. Develop a collection class maintaining a "dataset" as a collection of "table" objects each being a collection of such a record objects and you imitate a .NET dataset, if you want. This is an optional way of going in a direction you obviously want to avoid stepping into, but you can't avoid the nature of VFP differing from legacy FoxPro in regard of callstack behavior of forms vs screens. This change of the event model behind windows forms you inherit in VFP from the Windows OS is one of the least seen changes when converting your mindset from legacy screens to forms.
I see it as a big advantage to only need the single central READ EVENTS command to read all events. Events are delegated to whatever object they are related to by windows norms of windows messagees and events and thus make it much easier than needing to take that responsibility of when and where to go into a READ state. Your reaction to a value edit is within control.Interactivechange(), for example, or the final control.Valid() event when before the user changes to another control so you don't program your code reacting to input somewhere after a READ command, you have your dedicated events for that reactions.
Bye, Olaf.
If you want something with the same scope as the form, I already gave a lengthy explanation here in another thread this should either be a cursor within the form datasession or a form property. Those two things have the same scope and lifetime as the form, even if the datasession is not private to the form, that just means it lives longer than the form, the form then starts and uses an already existing current datasession, which it leaves open when finishing and releasing itself. So you don't need and you don't use private variables in VFP, they are completely unnecessary.
The way I sometime (perhaps) use them is when AUSED, AFIELDS, or any such array generating function generates an array as private variable, when I didn't previously declared a LOCAL ARRAY variable. There is no way to change that to producing local array variables by default, but the same goes about any variable you forget to declare LOCAL anyway.
To use the good old scatter, VFP9 offers using the NAME clause, you can scatter a dbf record to a form property you first create with Thisform.AddProperty("oRecord", CREATEOBJECT("empty")) and then populate with SCATTER NAME THISFORM.oRecord ADDITIVE which means you finally have THISFORM.oRecord.field1, THISFORM.oRecord.field2, etc. or you create all fields of a table as direct form properties by SCATTER NAME THISFORM ADDITIVE, creating THISFORM.field1, THISFORM.field2, etc., which I consider less clean, as you risk a namespace overlap of field names with any native or also user defined form properties already existing before the SCATTER.
With buffering you don't need to scatter at all, though, so the major way to bind forms to data is by making use of datasession workareas, no matter if cursor, DBF, updatable view, anything else I forgot. As long as it's not READONLY, this is a two way binding of controls. Scatter is handy, if you really want some such record object to be able to pass it from form to form even across several datasessions and such objects (based on "empty") can also be passed to COM OLEClasses to languages not aware of VFPs workarea concept at all. So the legacy "revival" of scatter allows to use modern concepts like linq with collections of objects. Develop a collection class maintaining a "dataset" as a collection of "table" objects each being a collection of such a record objects and you imitate a .NET dataset, if you want. This is an optional way of going in a direction you obviously want to avoid stepping into, but you can't avoid the nature of VFP differing from legacy FoxPro in regard of callstack behavior of forms vs screens. This change of the event model behind windows forms you inherit in VFP from the Windows OS is one of the least seen changes when converting your mindset from legacy screens to forms.
I see it as a big advantage to only need the single central READ EVENTS command to read all events. Events are delegated to whatever object they are related to by windows norms of windows messagees and events and thus make it much easier than needing to take that responsibility of when and where to go into a READ state. Your reaction to a value edit is within control.Interactivechange(), for example, or the final control.Valid() event when before the user changes to another control so you don't program your code reacting to input somewhere after a READ command, you have your dedicated events for that reactions.
Bye, Olaf.
- Status
