Blogging Code Walkthroughs

I am a huge proponent of code walkthroughs. There are many benefits:

1. Cross training team members on development language
2. Cross training team members on business the software serves
3. Lower bug counts per release
4. Enforcement of coding standards
5. Flushing out potential inefficiencies in the code
6. Communication of development techniques

A little over a week ago I blogged about VFP Macro Substitution Techniques and I received a couple of private emails offering suggestions for the code examples I posted. One in particular was very helpful from Sergey Berezniker (major VFP guru, VFP MVP, and UT posting bot {g}). He introduced me to the GETPEM() function. So instead of this code:

lcPropertyValue = loPickedControl.&lcProperty

I can use this code:

lcPropertyValue = GETPEM(loPickedControl, lcProperty)

As Sergey points out, the macro substitution code will be slower. Now I could argue the time savings will be immeasurable to the human mind, but the code is way more readable. This is what code walkthroughs are all about!

I have seen developers get very defensive on the constructive criticism side of the code walkthrough. I on the other hand welcome suggestions to make me a better developer. This morning I did a code walkthrough with my son who is subcontracting for me on a Web project. I know little-to-nothing about PHP, yet I was able to make some subtle suggestions to his code to make the application better.

It is important when doing code walkthroughs to not attack other developers. This is one of the simple golden rule things. Treat other developers with the same respect you want when you are the developer who is in the "hot seat." I regularly and informally walk through code for other developers, especially those I am mentoring. You would be amazed how much I have learned by doing this.

So thanks again Sergey, and others who were kind enough to nudge me with suggestions. I am a better developer today because you took the time to do so.

Southwest Fox 2006 - Speakers Finalized

I got an email from Bob Kocher this morning noting the finalization of the speaker list and he has pulled another one out of his hat with Nancy Folsom. Another fine selection. Nancy did a great session on Refactoring at GLGDW 2006, so her session Refactoring à la Carte is another one to add to your "must see" or "must read" list.

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.

Southwest Fox 2006 - More revelations

Just in case you have not seen this yet, Bob Kocher has more surprises for you at Southwest Fox 2006. I just read that he has added Rick Borup, Milind Lele, Rod Paddock, and Christof Wollenhaupt. Wow!

I think this will be Christof's first speaking engagement in the USA, but he has been a big time speaker at the German DevCon for years and someone I really respect. His knowledge of VFP and software development are tops in our community. I am really looking forward to his session 'The Security Cookbook."

Rick Borup is one of my personal favorite speakers at VFP conferences and is the co-author on Deploying Visual FoxPro Solutions. His session on "Automating the Build" is something I plan on attending.

Rod Paddock has hosted the often overlooked FoxForum.com site, which is where I hang out daily. Rod is an accomplished developer in both VFP and .NET so his session on "Understand the .NET Framework" should be a good one.

What a great set of additions to a power packed line up!

I also see Bob has announced each attendee will receive $150 in DBi Dollars. What a fantastic offer from the folks at DBi Tech. DBi Tech has been involved with the Fox Community for years, but have really stepped it up in the last 12 months with the Sedna components they are planning to release as part of the product and now this generous offer. Way to go DBi Tech and Bob!

Looks like Southwest Fox is heating up even more to be the best valued conference of the year here in the USA. I am sure there is not better bang for the buck in conferences around. You still have a couple of weeks to get the lowest price available. And knowing Bob, he probably still has a few tricks up his sleeve.

(updated 06/20/2006 to remove Milind's speaking as Bob has removed him from the list in latest post)

Lost in Trace

I have a situation here that has me perplexed. I build an APP file, the VFP Builder Manager (Builder.APP) to be specific. I do a Recompile All, and have checked on Debug Info and unchecked Encrypted in the Project Info dialog when I build.

I have added a SET STEP ON in the code to figure out a problem I have with a new builder I am writing. When the Trace Window opens there is no code displayed. None. It is as if the Debug Info was checked off.

I have checked the code for SYS(2030) and there are no instances of this called in the project. There is no SET DEBUG OFF anywhere in the project. The FXPs are not readonly and not getting replaced because the code stops on my SET STEP ON. I have checked this with PROGRAM() and LINENO() in the Watch window and they match my additions to the Builder.PRG. No projecthook to reset the Debug Info setting. I even added a SYS(2030,1) to make sure VFP was not stopping the debugging internally.

I know I am running the correct version of the APP file by checking _BUILDER and doing a ?FDATE(_BUILDER) to see if the file is the correct build date.

As you probably know, I don't have much more hair to pull out.

Has anyone seen this before? Can anyone point me to the corrective action? There could be prizes!

VFP Property Sheet: Edit Property/Method

Finally coming up for some air today after a marathon of activity here at White Light World Headquarters. I added about 10 blog entry ideas to my Wiki over the last couple of weeks and have not had time to address any of them.

VFP 9 has many enhancements to the Property Sheet, but one I was using a lot this last week include a shortcut to the Edit Property/Method dialog. I was refactoring some classes for a builder framework I am extending (which will be detailed in a future article in Advisors Guide to Visual FoxPro). I was adding properties and methods, renaming them, changing descriptions, and moving them to different classes. Fun work.

One of the frustrating things to make these changes is to to pull the Edit Property/Methods dialog off the Form or Class menu. Once displayed you have to scroll down the list to find the property/method you want to change. What I rediscovered this week is you can call the dialog from the Property Sheet shortcut menu and it will actually position you on the PEM (property/event/method) in the dialog. What a time saver.

Unfortunately this is only available for custom property and methods you add to the form or class. Right-clicking on intrinsic PEM does not display the menu option. Bummer.

Now the dialog should become a MenuHit project on SednaX (hint, hint, hint {g}). The dialog should be modeless like Doug Hennig's New Property/Method dialog. It should be resizable, remember its last size and position, and be dockable. It should be MemberData smart (making a change to the PEM in this dialog wipes out the MemberData details), the New Property and New Method buttons should call Doug's dialog. I am sure there are other ideas. What are your's?

There was a brief thread on this topic a long time ago on FoxForum.com ("Semi-hacking .SCX/.VCX PEMs for speed" thread in June of 2005). I offered to help, but unfortunately the thread and the discussion went no where. Hopefully someone will take the charge and come up with a replacement dialog.

SednaX Name Poll

Just in case you have not heard: the SednaX Admins are requesting your opinion on changing the name. Here is a snippet from Craig Boyd's news post on SednaX:

In the interests of providing SednaX members and project managers with more features and a powerful online environment for collaborative projects a move to Microsoft's CodePlex (http://www.codeplex.com) is being looked into. The CodePlex site is still in beta, but offers a number of features that SednaX members and projects could benefit from. The timeline in which SednaX would be moved to CodePlex is still a little difficult to estimate, but we hope to be able to make the move in a timely manner.

One of the other changes that is being considered as part of the move is renaming SednaX to better reflect the fact that it is related to Visual FoxPro. We have set up a thread, 'SednaX Name Change', in the discussion area for ideas about what SednaX should be officially named/branded for the long term.

Andrew MacNeill is taking this a step further with a poll. Cool.

So take part in this community effort and join in on the discussion in the SednaX forum, and vote on the poll. Both aspects will impact the final decision.