Sunday, June 18, 2006

VFP Macro Substitution Techniques

A couple of weeks ago I wrote a builder that generically manipulates properties. I was trying to recall a technique with macro substitution I used a couple of years ago to do this very thing.

I opened up Code References started searching source code for "..&" (period, period, ampersand) because this is what I thought I needed. The search came up with no results. This surprised me. I could have sworn I needed two periods.

It turns out what I needed is simply ".&" (period, ampersand). You see, what I intended to do is concatenate a macro substituted property name to the end of a reference to an object in the live designer. The final code is pretty straightforward once you know what you need. In this case I have a combobox with a list of objects in the form or class designer. The combo has an array with the full containership path to the object from the outermost container. To get an object reference I executed the following code:

lnComboRowSelected = this.cboObjectsToPickFrom.ListIndex lcAddPath = this.cboObjectsToPickFrom.aItems[lnComboRowSelected, 2] loPickedControl = this.oControlList.oObject.&lcAddPath

The properties I am working with are in a multi-pick listbox. To get the value of the property on the control I use the following code:

lcProperty = ALLTRIM(this.lstCommonProperties.aItems[lnI, 1]) lcPropertyValue = loPickedControl.&lcProperty

In this particular builder (which will be discussed in a future issue of Advisor's Guide to Microsoft Visual FoxPro) I generically allow you to pick to controls, select the properties you want identical, and the builder will migrate the properties. This is using the BuilderControls framework also discussed in the article. I use the same technique twice in the same method that moves the property values between the controls.

It bothered me a bit that I could not figure out why I originally thought I needed two periods. Then last week Tracy Pearson made a post on ProFox that was the smack up the side of my head jogging the correct memory of what I was thinking about. This is the second technique of using macro substitution.

I often work with tables or cursors to store data and often know the structure using AFIELDS() or some other technique. I control the alias to the cursor programmatically and store it in a memory variable. If I want a specific value from a column and need to include the alias (something I always like to do to eliminate the ambiguity factor) in the reference to the column. If the code is a generic to the cursor I can use macro substitution to manipulate the data:

lcAlias = ALIAS()

ldInvoice = &lcAlias..dInvoice
lcCustomerName = &lcAlias..cCustName

As Tracy pointed out in his post: "One dot to end the macro substitution, one dot for the normal table.field"

It made me feel better that there was a two-period macro substitution technique, I just wish I would have saved a half hour not looking for it the wrong way {g}. Hopefully this post will either introduce you to the techniques, or serve as a reminder they exist and they are completely different.


Post a Comment

<< Home