There's another trick you can use, if you want to display the difference betweeen two datetimes in the form of a time hh:mm:ss, you can simply take any datetime at midnight and add the seconds to it. As long as the time is below 24 hours, the time portion then is simply what you'd display.
So in short and as summary of both things:
Code:
Local lnMinutes && number of minutes
Local lcTimeDisplay && string in format hh:mm:ss up to 23:59:59
lnMinutes = (thisform.text2.Value - thisform.text1.Value)/60
lcTimedisplay = Right(Ttoc(DtoT(Date())+(thisform.text2.Value - thisform.text1.Value),3),8)
By the way, it makes sense to rename controls from the automatic names they get. Every code becomes more readable and understandable if you do so. For example Text1 could be called txtDateTime1 or txtStartTime - you better know what this textbox is displaying. Likewise Text2. There is a chapter in the VFP help about naming conventions
stating it's not required to use them. But:
help said:
...as part of good programming habits and to help remind you of the type of data you are working with
It really would also help me/us here to know what is the intention of Text1 and Text2. I think you're just tinkering with VFP to learn about it. Then that's a good entry point about the topic of writing code for sharing. If everyone uses these conventions it's simpler to understand code and talk about it.
I can also say that it is not all that helpful to do everything as recommended by this chapter. For example, you need a bit to get used to the variable name convention with two prefix letters. And I also don't use them in all code. If you dig into it, the convention VFP proposes also won't specify the data types of the values of textboxes, which contradicts this quote. The data type is only a prefix of variables and fields of tables, not of controls. So that also points out this proposed convention is not perfectly thought to the end.
On the other side, you should know that single-letter names can really lead to problems. A and B (for backward compatibility) are also always the names of workarea number 1 and 2. So indeed your usage of A and B has more danger than sticking to Text1 and Text2 control names. It'll not lead to problems immediately, you're allowed to use single letter variable names and using them works, you won't get the idea that a.fieldname then can address a table in workarea 1, because you don't set a to an object, but you see how that can lead to problems when a.x could mean property x of object a or field x of the dbf open in workarea 1.
The overall simplest advice I recommend is to be verbose about the names you give things, with exceptions where long names are just not making things easier to read. For example, it is still okay to name a counter just lnI for local numerical variable I. The single-letter names of the first few workareas ends at j, so actually i or I is still ambiguous. Say you would like to see which alias names are used by workareas, then doing a loop like this would fail:
Code:
For i = 1 to 20
Select i
? Alias()
EndFor
It won't error, but it would display the alias name of workarea i 20 times.
On the other hand, this will work:
Code:
For i = 1 to 20
? Alias(i)
EndFor
Here i is taken as the counter value.
So you're not bound to fail with this, nor get errors, but unexpected behaviour hard to fuigure out. So get into good habits from the getgo and avoid even to use letters k-z.
There are enough gotachas in the way VFP works, you can avoid contributing to them by getting used to better naming.
Chriss