Dump unnecessary leading equals signs ("=")

You will often see a leading equals sign ("=") in older VFP code (especially in code ported over from FoxPro 2.x).  A leading equals sign is necessary only in a couple of instances in VFP:

  - when calling the SEEK() function  and not storing the return value, e.g.,

      USE (HOME(2) + 'Data\Customer') IN 0
      =SEEK('Great Lakes Food Market', 'Customer', 'Company')

  - when denoting an expression in a property in the Properties Sheet/Window; for example, when setting the .Caption property of _Screen:

      ='My Application (Version # ' + m.gcVersionNo + ')'

Side note, when setting the .Picture property for an Image control, include the equals sign as follows:

      ='MySplash.JPG'

If you specify MySplash.JPG without the equals sign and character delimiters, VFP will attempt to insert the path in front of the picture's file name; the problem is that that path may not (in fact, most likely will not) be on your customer's PC (when your application is production).

It is not too late...

With less than a month before it begins, the Southwest Fox 2008 conference is set to start October 16th. It is the premier conference for Visual FoxPro developers in the nation and with over (an estimated) 100,000 VFP developers world-wide, Visual FoxPro will be around for a long, long time. The conference is the PERFECT opportunity to hone your skills and pick up new techniques to enhance future developments. If you haven't registered, IT IS NOT TOO LATE to register. 

Having said that, it gives me the opportunity for some self-promotion. When you go to the conference website, look for the link to download the K.O.K.O.P.E.L.L.I. software written by moi. It will give you two hours of your life back. How? Well, instead of spending two hours trying to figure out the optimum schedule to ensure you see the sessions you are most interested in, the software prepares a "suggested" schedule based on your preferences in just a couple of minutes.  Give it a try. If you have any problems, let me know by leaving a comment and I promise I will get back to you.

Hope to see all of you in Mesa, AZ in October.

Character (string, text) delimiters

Here's my order of preference for character delimiters:

a) Apostrophe (') ... saves time since it is just one character and does not require you to press and hold down the <Shift> key ... easiest to read (least 'cluttered')

b) Square brackets ( [ and ] ) ... requires two (2) different characters but still does not require you to press and hold down the <Shift> key ... easy to read

c) Double quotes (") ... just one character but requires you to press and hold down the <Shift> key ... "busiest" in that it adds "white noise" to your code

I switch to square brackets if there's an apostrophe within the string.  If the string contains (i) an apostrophe as well as (ii) one or both of the square brackets, then I employ double quotes.

Examples:

* My ideal is to employ apostrophes for delimiting character strings
WITH ThisForm
  .icTableItemExpression = 'ALLTRIM(' + .icMainAlias + '.FPC_FacilityName)'
ENDWITH

* Here, I am forced to employ square brackets due to presence of embedded
* apostrophes
This.icDynamicFormCaption = ['Notes for '] + ;
  [DTOC(C_AdmitDischarge.AD_AdmittedOn) + '-'] + ;
  [DTOC(C_AdmitDischarge.AD_DischargedOn)]

* Here, I am forced to employ double quotes due to the presence of embedded
* square brackets as well as an embedded apostrophe
This.icDynamicFormCaption = "[Notes for McDonald's]"
* Alternatively, I could employ square brackets as the main character
* delimiter:
This.icDynamicFormCaption = ["Notes for McDonald's"]

(Regardless of what character delimiters you prefer to employ, I recommend that you be consistent!)

Best practices when macro substituting

When working with macro substitutions …

1) bring “closure” to them

  Get in the habit of always “closing” your macro substitution with a period (“.”); for example:

    &lcSQL.

  That way, when you employ macro substitution as part of an object hierarchy, VFP will properly parse the line; for example, if you have a form with a commandbutton whose .Name is ' cmdButton':

    The following code sets the .Caption of 'cmdButton' to 'Process':

      LOCAL lcCommandButton
      lcCommandButton = 'cmdButton'
      ThisForm.&lcCommandButton..Caption = 'Process' && Two (2) periods before .Caption

    whereas the following code triggers a “Property CMDBUTTONCAPTION is not found” error:

      LOCAL lcCommandButton
      lcCommandButton = 'cmdButton'
      ThisForm.&lcCommandButton.Caption = 'Process' && Only one (1) period before .Caption

2) don’t embed them

    lcControlName = 'cmdButton'

  Replace the cryptic, embedded macro substitution:

    ? 'oForm.&lcControlName.'

  with the following, easier-to-read (and, therefore, easier-to-maintain) code:

    ? 'oForm.' + m.lcControlName

  (The above should run faster, too, since it does not employ macro substitution.)