Shedding Some Light

At the recent German DevCon I presented my “Get Productive with Visual FoxPro” session. This session is always different each time I give it. Mostly because the people attending the session often participate by throwing in their own productivity tips (which I encourage in all my sessions). I always start the session off with productivity tips with the Class Browser tool which ships with VFP (and has since VFP 3). It rarely fails that a developer will contact me after the session to let me know how much they appreciate the various tips on the Class Browser.

So in case you have not seen the session, here are some of the tips:

Set the default file to be opened when Class Browser is started

First open up the Class Browser and open up the class library you want to be the default class library opened when the Class Browser starts. In the Command Window:
_oBrowser.SetDefaultFile()

If you want to clear the default class library execute the following statement:
_oBrowser.ResetDefaultFile()

This works great if you are constantly editing classes from the same class library for an extended period of time.

You can open the Class Browser with multiple class libraries

The first parameter accepted by the Class Browser is the file name of the VCX, or more accurately a comma-delimited list of VCX file names.

DO (_browser) WITH “examples\CPhkBase2, examples\demo”

Most Recently Used List

Have you ever right-clicked on the open button of the Class Browser? If not, give it a try and see a long list of previously opened class libraries. This has been in the tool for years, but I still show developers this little trick which saves me hours of drilling through directory structures.

Project Manager Can Start Class Browser

Double-clicking in the Project Manager on a Visual Class Library will open the class library in the Class Browser in VFP 9. Previous to VFP 9 nothing happened when you double-clicked on a class library. You can stop this from happening via a projecthook QueryModifyFile event. You can also intercept this in a projecthook via the QueryModifyFile event and run your own class library tool, or you favorite hacking tool like HackCX Professional (code to do this is posted here for HackCX Pro users).

Class Browser can open/maintain PRG based classes

The Class Browser has always been able to open VCX files, but many developers prefer to code their classes in program code (PRG). One of the disadvantages to taking the PRG route was the inability to use the Class Browser to maintain the classes and get a visual representation of the class hierarchy. Visual FoxPro 9 removes this limitation.

Renaming methods and properties without opening the class

You can rename methods and properties by right-clicking on the property or method and selecting Rename… on the shortcut menu. A dialog is presented which allows you to rename the property or method. Please remember that renaming a method or property does not magically rename the references in the method code. You will need to manually search and replace any references that are changed.

Copying and Moving Classes Between Class Libraries

You can open two instances of the Class Browser and use the mouse with the Ctrl key pressed to drag the icon in the upper left corner to the other instance of the Class Browser. This will copy the class to the other class library. This will maintain the same parent class relationship. If you do not hold down the Ctrl key you will move the class to the other class library.

It is not uncommon when I show this to developers to hear how they are surprised you could run multiple instances of the Class Browser. To me, this is one of the more powerful features of this important tool.

I posted the last one yesterday on FoxForum.com and a friend of mine popped me an email today noting this was cool and I should post this on my blog (prompting this entire post). Heck, how could I just pay it forward with one tip when I have so many others? So thanks Mary, it is all your fault this knowledge gets spread further into the Fox Community {g}.

Enjoy!

I have been working on an application over the last couple of days for a client. I needed to add 20 or so fields to the OrderMaster table of this application. Simple thing to do, right? Not for me.

I use xCase to model data (both for VFP and for SQL Server). I love xCase for many reasons, but it is way better than using the native SQL Server and VFP Database and Table Designers. I added a bunch of fields yesterday and needed to add a couple I missed today. xCase has this wonderful feature which updates the table structures automatically. Today I get an error during the update:

The fields in table ‘OrderMaster’ did not match the entries in the database (Error 1984)

Argh! The “big brother is watching you error” – reference to George Orwell’s famous book titled 1984. Sorry, I digress.

I believe this is the worst possible error you can get when working with VFP data. The solution recommended by the Help file is to use the VALIDATE DATABASE command or to remove and re-add the table to the database. Both of these options should include a disclaimer that says something to the effect of “both these solutions will hose the database worse and cause your hair to turn grey and fall out.”

The better solution is to get out my trusty backups. Unfortunately, this morning I took my 250GB USB drive and the latest copy of the backups burned on DVD to the safety deposit box at the bank. This is my offsite backup scheme. I rotate the USB drive and permanently leave the DVDs in the box. No problem I’ll just go back and bring them home. Too late – banks close at the worst possible times when it comes to being a developer. So now I get to wait until the morning to get the backups and finish up this project.

This would never be happening to me if I was working with SQL Server {s}.

I have emailed the client to let him know I am a victim of Murphy’s Law, and there will be a short delay in getting him a new release. I just hate having to send emails with bad news.

Guess I have some time to push out another ViewEditor v3.6 Release Candidate this evening…..

Interesting statistic I realized this morning looking at the virus scan statistics: my drives have more than a half-million files scanned when it performs a full system scan. 507, 230 to be exact. That is a lot of files.

Just in case you are not on the Southwest Fox distribution list or have not seen postings on a forum, Bob Kocher dropped me a nice pre-Thanksgiving gift by announcing the dates for next year’s Southwest Fox conference. From Bob:

There are still some details to work out so specifics will have to wait a week or so. For now, I am extremely pleased to announce Southwest Fox will return to Tempe, AZ Thursday, October 19, 2006 through Sunday October 22, 2006. We have a great new location this year and we are working on a couple of new and exciting ideas.

I will be there whether I am a presenter or not. Good timing since companies are already planning budgets for 2006. Way to go Bob!

Today I answered the following question for what seems like the thousandth time: Why do objects on my 2.6 screen not show when I run the code in Visual FoxPro 9?

The answer is to shut off Windows XP Themes. You can do this using the form Themes property, or globally using _screen.Themes = .F. OR SYS(2700, 0) in the start up code for the application. This is an issue with the 2.6 READ compatibility mode. It is a known issue and one we do not expect to be corrected any time soon. It is also easy for a developer to fix.

The good news is I sense more and more FoxPro 2.6 developers are looking to move their application to Visual FoxPro. The bad news is this little problem causes developers more headaches. It also shows developers are trying to take advantage of VFP’s backwards compatibility. I just hope they are not expecting this to be a long term solution and they plan on rewriting the application using the full power of VFP OOP, a solid application framework, and best practices we have developed over the last 10 years of developing VFP applications.

As you may have read before, I use AOL IM (AIM) to keep in contact with my kids online. Yesterday AIM was kind enough to automatically add two new “buddies” to my list. It informed me of this by interrupting me with an instant message:

“AIM added a new AIM Bots group to your Buddy List. AOL System Message: Send IMs to moviefone and shoppingbuddy for great holiday flicks and gift ideas. (To remove ‘em, just right-click and delete! Learn More)”

So not only does it pollute my contact list, but it interrupts my day and my train of thought on some client work with a stupid message telling me it has polluted my contact list. Argh! Not only did I get interrupted once, but then I get another couple of support calls from friends and family asking me if these new bots are safe (after years telling them not to load this kind of stuff) and how to get rid of them. Double Argh! If Microsoft did something like this the media would be all over them asking them to remove things customers did not ask for, but AOL gets a pass on this. Unbelieveable.

Mike and Toni have started the F1 Tech Blog. This means two more very knowledgeable VFP people are sharing more with the community. Check it out. The first post discusses the recent AtoutFox conference in France. Welcome to the blogosphere guys!

Last week Mike Potjer reported a problem in HackCX Professional with the logic to decode the TimeStamp column of the VCX he was hacking while using VFP 9. The error reported is:

Error: (11) ‘Function argument value, type, or count is invalid.’ happened in frmhackmain.convert() on line 75

The line of code triggering the error has been working for a very long time. In fact, the code I use to decode the TimeStamp column has been around for more than 10 years with the only tweak being a change to comply with SET STRICTDATE TO 2 and a cleaner implementation to be Y2K compliant. The line of code triggering the error:

lcRetVal = lcRetVal + DTOC(DATE(lnYear, lnMonth, lnDay))

The TimeStamp should have been decoded properly as it was a valid TimeStamp. The values of lnYear, lnMonth, and lnDay were 2004.8074, 12.918774, and 29.0077209 respectively. In VFP 8 the value of lcRetVal was the character equivalent of {^2004/12/29} and in VFP 9 (both RTM and the SP1 Beta) the code errors.

Mike’s bug report was one of the best I have seen. He provided me the steps, the error log HackCX recorded, and a screen shot of the debugger with all the details surrounding the line of code. It literally took me five minutes to reproduce the problem, make the fix, and send Mike the updated version. He tested it with the Class Library he hacked and all is well.

I was initially thinking of reporting this issue to Microsoft as a bug. As I was creating the reproducible steps, noting the observed behavior and discussing the expected results I started thinking about this in more detail. Here is the test code I was going to send to the Fox Team:

?DATE(2005.3232, 12.2323, 19.3232) && fails
?DATE(2005.3232, 12, 19) && Works
?DATE(2005.3232, 12, 19.3232) && Works
?DATE(2005.3232, 12, 31.3232) && Fails
?DATE(2005.3232, 11.99989, 19.988976) && Works, uses integer of parameters

I struggled with the expected results part of the report. I initially wrote down that I wanted the INT() of the parameter passed in. But what if I really calculated a number like 31.9898 as the day of the month. Should it round to the next day? In the context of my TimeStamp converter I want the INT() and this is how I fixed the code. I am not sure how other FoxPro developers would want this to work and thus came to the conclusion that a valid parameter cannot be bigger than a real date. The decimal portion of the month and day could be larger than the valid values. Therefore the error message reported by VFP was dead on and the documentation in the Help file notes valid parameter values (it just does not say how it addresses the decimal part of the parameter so you have to interpret the parameters as literal maximums).

The DATE() behavior has changed and this little tweak in VFP to tighten down the correct behavior of a function could bite you like me, so I thought I would share the story in case you run across this in your development. Thanks again to Mike Potjer for the excellent bug report and making me think a little about how this function is working.

New version of HackCX Professional will be posted this afternoon for existing and future customers to download.