Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
The m. variable thing
Message
 
To
18/11/2004 09:18:19
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00962544
Message ID:
00962584
Views:
7
Just something to think about...

Selecting NO workarea is tricky by itself.
Just a few examples. As you know, SELECT command selects only between existing workareas, or you SELECT 0 for unused area. Select NO workarea can be done only by closing the table in the current area. If you have the grid in the form, the specifically selected workarea automatically switches to the grid workarea if the grid gets focus.

Following a good naming convention for the fields and variables minimizes the possibility of mixing them.


>You can significantly reduce the potential for surprises in the way VFP handles fields/memvars by running as much as possible with NO work area (alias) selected as current.
>
>A field name ALWAYS takes precedence - field names in the current 'active' work area that is.
>This can bite in untold ways. A parameter name, for instance, can suddenly change from being a memvar to a field **if** a new field is added to the table that is active that matches the parameter name.
>The same of course can happen for any memvar, not just a parameter name.
>
>By using the "m." explicitly when required (or even when not specifically required) you preclude sudden surprises caused by matching field names in tables.
>I recall the m. as a throw-back to the old dBASE days and, personally I never use it. Does anyone have an argument for its use? Can anyone put their finger on the article to which I referred?
Nick Neklioudov
Universal Thread Consultant
3 times Microsoft MVP - Visual FoxPro

"I have not failed. I've just found 10,000 ways that don't work." - Thomas Edison
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform