When you call the Show() method of a form passing 1 as a parameter, you expect the form to show modally. There are some cases, when this is not the case, though. For instance, when the form is already visible, you receive a "Cannot change modality of a visible form" error message. Or, if the form is top-level form it cannot be modal.

One such difference is what constitutes an expression that can be optimized. The help file states that such expressions have one of the following forms:

New computers come with Windows Vista preinstalled. Here's my summary of replacing a desktop computer with a new machine:

FoxPro has a great history of remaining backward compatible. Yet, sometimes the behaviour changes without that the documentation reflects this. SYS(2027) is still available in VFP 9, although it's not documented anymore. The syntax for SYS(2027) is:

cPathOut = SYS(2027,cPathIn)

Back when Visual FoxPro was really a cross platform development tool, you would use SYS(2027) to convert the internally used DOS path into a platform specific path. On FPM this functions returns a Mac-compatible path, on FPU a SCO Unix compatible path.

After working in a language like Visual FoxPro for so many years, there are some things that seem so natural that you might not even recognize them as a potential problem. The following code is perfectly useless, but working Visual FoxPro code:

As a Visual FoxPro developer you discover many familiarities when you read (or write) .NET code. After all, you have been working in an object oriented environment for over a decade whereas the poor VB guys had to jump right from infancy into adulthood, right?

In the past year I've received an increasing amount of incorrect invoices. I'm not talking about fake invoices, virus attachments or subscription reminders. The invoices I'm talking about were real invoices, except that the amount of VAT was off by one cent, sometimes up, sometimes down. What does this have to do with VFP or .NET?