How to declare a variable in VFP? 3

[greathope123]

In Command3.Click
local userName
userName="abc"
?userName
Why it did not print out "abc"?

It printed something in database table1 because "username" is its field name?
My question would be how to tell VFP a variable is the field name in database table or is a variable I declared in "local"?

 

[wtotten]

it sounds like you have a variable named USERNAME and a field in a table with a field named USERNAME, and that table is the "seelcted" table (the table taht is open in the "area" your are working in). If that's the case, your "? username" command will display the value in the table.

To have it display the value of the memory varaible, you would use this:
username="abc"
? m.username

The "m." before the "username" tells FoxPro that you want it to look at for a memory variable named "username".

The "abc" would show on whatever is the active "form" and that can be a VFP form or the screen (_SCREEN).

I highly recommend you do not have variables with the same name as a file for exactly this type of problem. Try using mnemonic notation to help you to know (a) if the variable is "local" or not, and to (b) know what type the variable is (Date, Numeric, Character). For example, I will assume the field is named USERNAME and it is type CHARACTER. I would name the variable that I want to associate it with as cUsername. If I wanted to have the variable as a LOCAL one, after I declared the variable as LOCAL, I would name it lcUsername.
LOCAL lcUsername
lcUsername = 'abc'
or
lcUsername = username && This would store the value in the USERNAME field to the variable.

As for whether to make the variable LOCAL or not, read up on that.

 

[greathope123]

Thank you!

It means the field name in the table has priority over the local variable!
Can you also tell me how to assign a table to be current table and how to know which table is the current table?

 

[wtotten]

First you have to open the table. If you want to open a table and not clsoe the table currently open in your "area", do this:
SELECT 0 && (that's zero) - this puts you in an area that has no table open
USE customers && opens the CUSTOMERS table

To determine what area FoxPro assigned when you issued the SELECT 0 command, you do this:
? SELECT()
This will show the number of the area, not the name of the table. In this case it would return something like 2.

If you want to know the name of the table currently open in the area you are in, do this:
? ALIAS()

Does that help?

Bill

 

[wtotten]

Something else:
If you try to open that is already open in another area, you have to use AGAIN and give it a different alias name. If CUSTOMERS is already open in area 2 and you do this:
SELECT 0
USE customers

You will get an error. Do this:
SELECT 0
USE customers AGAIN ALIAS customers2

To move between areas it is SELECT and then the area name or SELECT and the alias name. If CUSTOMERS is open in area 2, both of these will select that area for me:
SELECT 2
SELECT customers

Alias name; when you open a table FoxPro will give it an alias that is the same name as the table. For table CUSTOMERS, the alias will be customers. You can change it using the ALIAS statement as I illustrated above.

I recommend you find an article that explains the concept of AREA in FoxPro. It's a fundamental basic concept that you need to understand before you move forward.

Bill

 

[greathope123]

Thanks a lot for your helps!!

 

[Olaf Doschke]

Using naming conventions you'll not name variables the same as fields, roughly said.

Variables
primary prefixes
LOCAL: l
PUBLIC: g
PRIVATE: p

secondary prefixes
Logical: l
Character: c
Numeric: n
Date: d
Object: o
...

eg

LOCAL lcName
lcName = "Olaf Doschke"

As a field has no variable scope, the corresponding field name may be cName

So far, so good.

You'll find lengthy discussions at foxite about m. because of an overlap in this naming convention, eg you can construct names like lorange, which could be an object variable loRange, for a range object of eg an excel sheet, and it could be a logical flag field lOrange for a table field denoting a color is orange .t. or .f.

You can think of this, as you like, I avoided the problem by using camel case notation for variable names and underscores in field names. Furthermore, what is forbidden to me is SCATTER MEMVAR, I don't want the field names as variable names, we have SCATTER NAME loRecord and then have eg loRecord.iPerson_id. Now that could be a problem with a table named loRecord, but then my tables are called t_person, eg or s_config, with s_ prefix for system related tables.

This also avoids this problem, when you have the full control about your database naming conventions.

The other point of view is, you have a performance advantage when using m., but it's not really huge, I prefer better readable source code. Also the effect only happens, if there is a table/cursor/view selected and it has many fields. The number of records doesn't matter, it's the fields which are iterated, not records. You can simply SELECT 0 to have no effect. This is not always possible, as you will want to work on data in a workarea, but in many cases it is possible to SELECT 0 before doing a lot of code crunching numbers. Then again, for such non data related code, other programming languages are more efficient, eg C++.

Mdot is also only needed, if you read a field, so you would end up writing
lnCounter = m.lnCounter+1

Well, it doesn't hurt to write
m.lnCounter = m.lnCounter+1

But post this in a forum and you'll attract the typical smart a** telling you, you don't need the first m.

Do as you like, do as you choose to do, I opted against m., even though also the naming convention prefix makes variable names like lcName less readable than the pure Name, and m. doesn't ad much more unreadability. It rises questions of freelancers working for you, eg.

The reason the discussion on foxite went into a "flame war" is, this caused an error in a VFP tool working on tables, and as you don't have any control about what field names any developer will use in any of his tables, you have to code m. with your variable names, to avoid accessing a table field, when you want your variable. I put this in quotes, as - like always - the VFP community was very constructive and not getting personal.

The most political point about it is, you find very rare posts of code using m., even from those advocating it, and that makes it quite unbelievable it's widely used, because you don't save time in forums posting code without m., you save time, if you copy&paste own code unmodified with m. That's harsh critic, I know, I don't want to make this personal. You also often hear arguments code is posted without error handling, just because it doesn't add to the explanation. That's at least more believable in regard to writing a sample solution without getting verbose off topic.

I was at writing a tool to add m. automatically to source code before build with a project hook, but then VFP died. Then I used it a lot longer, up to now, but mdots has faded in it's importance anyway. I came across this problem once in a lifetime, compared to other errors I repeated a lot. Taking a look at the costs for customers in downtime, the most heavy bugs were table corruptions and syntax errors passing compilation, eg because you are not forced to declare variables, so code with a typo in a variable name typically compiles and wrong names only error at runtime with "variable is not found". So from this real life experience mdot also is very unimportant.

If you want failsafe code, you can introduce a bit of code reviews, personally, not programmatic. That's more effective than any tools. For performance, you mainly have to know rushmore, how it works, and how you index your dbfs. Avoiding macro substitution, where name expressions or eval could be used is another factor more important than mdot. Working with variables or memory is much more effective with pointers in C++, in comparison with that, m. is a turbo for a snail. The biggest advantage of Fox is rushmore, and only rushmore. Don't use VFP for non data centric apps.

My main advice in regard to mdot still is to avoid equal names of tables and fields. It's different, if you write tools generally working on any database. Then making sure you access your variable, when you ant your variable value has a bit of importance, but even then you can avoid situations. I admit it's the strongest argument for using m., but another solution is using variable renaming at compilation for reasons of obfuscation with quite random names, which you would never anticipate as real field names. And then the argument would be to generate two identical UUIDs.

Bye, Olaf.

 

[Dan Freeman]

m. is a scope identifier. It says "this is a memory variable I'm talking about".

Like all other areas of VFP, there is always a default scope and you can often rely on it. The default scope of the Replace command is NEXT 1. You'll seldom see someone write REPLACE NEXT 1. We'll just let VFP assume that's what we mean because we "know" it will work that way.

With memory variables, it's not ALWAYS as convenient to rely on default scope because as you've noticed a table in the current workarea will take precedence. That's the default scope in action again.

The workarea conflict extends to the letters a-j, which were default workarea names in earlier X-base versions. (Blame Wayne Ratliff!) This would cause an error:

a = createobject("form")
a.Show()

This will cause an error unless you have a file open in workarea a and it has a field named show, but it won't make the form you just created visible either way. The default scope of the workarea has taken over. You can still make it work by specifying the scope of the memory variable, though:

a = createobject("form")
m.a.Show()

As Olaf says, using a smart naming convention can limit the number of times you encounter problems relating to the memory variable scope, but there are times (like when using SCATTER MEMVAR) that you need to be specific.

So know about it, be aware of it, but don't obsess over it.

 

[wtotten]

One note on using the "m." to prefix any variables; Your code will run a faster if you use the "m.". In some cases it can make a significant difference. I'm not talking about when you assign a value to the variable, but when your code is being "evaluated" (for lack of a better term) by the FoxPro. For example, say I'm scanning through 100,000 records and I have to look at each record, get some values out of the table (assign them to memory variables), and then use those variables in code. For example:

USE mytable
SCAN
lcCustID = CustID (the table currently open in this area has a field name of CUSTID)
* Some code where you use the variables ... use the
SELECT * FROM saleslog WHERE custid = m.lcCustID INTO CURSOR ctemp1
* Note that the line above uses m.lcCustID instead on lcCustID.
* With the "m." you are telling FoxPro that it doesn't need to have the (tiny bit, but it's there) overhead where it first looks for a field name
*first look for a filed named LCCUSTID,
* ...
ENDSCAN

m.lcFname = mytable.fname
lcFname = mytable.fname

 

[wtotten]

I accidentally hit something that posted my last reply before I was done.
Bottom line is using the "m." prefix will make your programs run faster. I could explain it further, but I need to go. Good luck.

 

[Mike Lewis]

Bottom line is using the "m." prefix will make your programs run faster.

That's nearly always true - but don't rely on it. We had a big discussion on that point here in Tek Tips a few years ago. Several forum members ran some extensive tests, and concluded that any gain in performance depended on the number of fields in the current table, and the number of memory variables currently in scope. In the worst cases, using m. actually slowed things down.

I'm sorry I can no longer find the disucssion in question, so I can't post a reference. I do remember that Geoff Franklin was the person who did the most extensive testing. Also, there's some figures on Fox Wiki (

http://fox.wikis.com/wc.dll?Wiki~EssentialMDot~WIN_COM_API)

which point in the same direction.

I vaguely remember reading that the speed benefits of using m. are greater in VFP 9.0 than in earlier versions, but again I can't point to any details.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

Can you also tell me how to assign a table to be current table and how to know which table is the current table?

Rather than having to 'know' which table is the current table, Determine which you want to be the current table.

An alternative to the following:

SELECT 0 && (that's zero) - this puts you in an area that has no table open
USE customers && opens the CUSTOMERS table

is:

USE Customers IN 0  && Opens table Customers in next available workspace
    or
USE MyCustomers IN 0 ALIAS MyCust  && Open table 'MyCustomers' and assign specific ALIAS (MyCust)

Then you can access anything in that table by using its ALIAS.

But to Ensure that the table you want is the currently 'active' one, use SELECT to define it prior to using it.

SELECT Customers  && [u]Ensure[/u] table is currently default table
?Customers.Username && output current record's Username value

Good Luck,
JRB-Bldr

 

[wtotten]

Geez, JRB-Bldr - there are of course multiple ways to open a file. What I explained is no slower than what you did if he wants to open a table in a new area and have that area being the current one. Why confuse they guy? He's BRAND NEW at this. You're just confusing him.

Heck I could have said
USE customers in 0 AGAIN ALIAS customers ORDER fname
But I'm trying make it simple for the guy. I'm not trying to show off like some people seem to be.

You made comment on a post the other day that a grid's Init() cannot be called after the form's Init() which is dead wrong. Check your ego at the door and just try and help people and make it simple for them to understand.

Bill
Bill

 

[JRB-Bldr]

Bill - There is no need to get into an argument here, but you are wrong.

You made comment on a post the other day that a grid's Init() cannot be called after the form's Init() which is dead wrong.

I never said anything like that at all.

You must have misunderstood what I was talking about.

greathope123 - Good Luck,
JRB-Bldr

 

[wtotten]

jrbbldr - my apologies if I confused you with someone else.
Be well.
Bill

 

[Olaf Doschke]

>My question would be how to tell VFP a variable is the field name in database table or is a variable I declared in "local"?
Let me answer that one more direct:

As you can access a field of a table by it's mere name, names can be field or variable names. Names can be file names or object names, too, but that's not the point here.
Since the language is designed that way, there has to be a priority, what a name is. Since VFP is data centric, it was decided to prioritize field names over variable names and add the m "object" for variables. In other languages or concepts like the ado.recordset, accessing fields is much more complicated, than in VFP, you have to address oRS.Fields("fieldname").Value instead of simply fieldname. In .net datatable.rows.item[2].item["fieldname"], admitted, this includes accessing a certain row number, while VFP and the ado.recordset have the concept of current row, sometimes an advantage, sometimes not. How verbose code is, also does not tell, how fast it is.

Well, and of course to distinguish between wanting a variable over the field name you can write m.

You can are not forced to m., as you may want to write code, which accesses the field or the variable depending on such a table selected or not. I never had use for such a case, but it's possible, of course.

Bye, Olaf.

 

[Olaf Doschke]

a grid's Init() cannot be called after the form's Init()

Hm, I don't know anybody saying so, must be your interpretation.

Not long ago I said form init runs after all control init did already run, which is dead right.

Also it's right you shouldn't call events. Events are there to occur and to react to events. If you have something you need to redo to reinit an object, you could also put it in a user defined method initilize() and call that from init(), too. It seldom has a bad side effect, if you call code, eg call programmaticchange from interactivechange, but the more elegant solution is to make a third method change() and call it from both events. the best example of how calling an event fails is, if you call valid() or lostfocus(), this execute code in there, but not the default event behaviour, eg calling valid does neither save value to the controlsource, nor moves focus.

Bye, Olaf.

 

[Dan Freeman]

You made comment on a post the other day that a grid's Init() cannot be called after the form's Init() which is dead wrong.

Technically, this is wrong as written. It is correct to say that VFP does not call a grid's init() after the form's init(), but the developer can call it at any time. They shouldn't, but they can.

 

[craigber]

@wtotten, @MikeLewis

One other caveat when using m.

Don't put it on the left side of the = in an assignment. It does, in fact, slow things down.

In other words, don't do

m.lcVariable = SomeOtherValue

Because you can't assign a value to a table column using the = sign, there will never be ambiguity.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Mike Lewis]

Don't put it on the left side of the = in an assignment. It does, in fact, slow things down.

Quite right. I would never do that, and not just because it slows things down, but also because it's just ... how should I put it? ... just wrong.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads