Shedding Some Light

Last week I saw Jim Nelson present his two Southwest Fox sessions, and one of Jody Meyer’s sessions in Grand Rapids and Detroit. Yesterday I had the pleasure to listen to Cathy Pountney and Jody Meyer rehearse both of their sessions at Chicago Fox User/Developer Group (CFUDG). The two groups were also kind enough to listen to the real rough beginnings of my sessions too. I thought the three meetings were terrific and the hosts did a magnificent job.

Special thanks to Jody Meyer and Cathy Pountney for putting on the special August meeting in Grand Rapids last weekend and thanks to Bill Drew and Jeff Simon and the CFUDG gang for putting on the special meeting yesterday! And thanks to everyone who came out to listen.

These sessions are invaluable to speakers as they figure out what works and what does not work in front of a live audience. At least for me, I know I present differently in front of developers interested in learning than when I sit down in front of the dog in the office and run through my sessions.

Cathy finished her second session of the morning making it obvious to me she is serious about defending her #1 speaker status as she is already in top conference form. It was at that time someone made the comment (and I am paraphrasing here): “There is no need to waste your money on expensive conference fees and outrageous hotel costs when you see this quality of session during rehearsals.”

Now I am sort of being kind on the paraphrasing, because what I really heard is: there is no need to support Southwest Fox or other conferences when speakers do the session rehearsals for almost free at user groups. Mind you the group who showed up made a generous donation for the food and covered some travel costs for the speakers, so the event was not free. Yet, the comment really rubbed me the wrong way. As an organizer who commits to 200-300 hours of volunteer time to put on Southwest Fox each year, and another 80-130 hours preparing sessions for the conference, I don’t appreciate the sentiment that was expressed. It simply hurts.

There is something I believe is too important to be overlooked. It is something I have known for a long time and probably have not expressed out loud enough. Southwest Fox depends heavily on FoxPro user groups. We depend on them for marketing and we depend on them to provide venues for the speakers to rehearse their sessions. It is something the organizers of Southwest Fox have recognized from the very beginning. Two of the three organizers started and run local user groups and the third organizer presents at them regularly. We all understand how important these groups are for the community to share and learn together. One of the first things we figured out for Southwest Fox was the user group discount we offer and giving money back to the community to support the groups.

But this is not a one way dependency. FoxPro user groups depend on Southwest Fox and other FoxPro conferences. You see, the Chicago group has been blessed more than most groups because they draw lots of conference speakers to present to their group. CFUDG invites speakers to come and share. They proactively call speakers to visit. They are a terrific group to present to and are open to learning all kinds of new things. The Detroit Area Fox User Group, Grand Rapids Area Fox User Group, and LA Fox User Groups also have been blessed with regular meetings being filled with conference-level sessions. I know there are other Fox user groups around, but these groups really fill their schedules packed with presentation rehearsals.

So what exactly is the real dependency? Conferences need well prepared speakers to draw people to the conference, speakers need to rehearse, and user groups need speakers to draw people to meetings. So if the presenters are not rehearsing the conference suffers and people are not as likely to return next time. If there is no conference, speakers are not likely to spend 40-80 to prepare one session. User groups won’t have conference-level sessions at their meetings and as a user group leader I know the “big name, conference level sessions” draw more than the core regulars to a meeting. It would be a downward spiral. I prefer the upward spiral where conferences exists and draw the best speakers and attendees, where user groups get more rehearsals, and the perpetual motion goes in the right direction. For conferences to exist, people must come. So now you understand why the comment felt like a dagger in my chest.

I know some people are unable to come to Southwest Fox because it conflicts with personal events, or live to far to travel at a reasonable cost, that the economy has affected some, or they have some project deadlines to meet. But to not come because you can see some of the sessions before the conference really doing yourself a disservice. You are missing most of the session you can benefit from seeing, not to mention the networking, the comradery, and talking to vendors who have some terrific products to demonstrate for you in person. Getting outside of the office and talking with other developers of like mind is an experience you will find extremely beneficial.

At the same time lots of people have asked me about 2010. Will there be a Southwest Fox 2010? I can only say maybe. We have not signed a contract at this time for a venue, and have not set any date. It all depends on how the community supports the conference.

So support your favorite conference (I hope Southwest Fox is high on your list) and support the speakers who are hard at work preparing to help you learn some really cool and useful stuff. There are upcoming rehearsals in Chicago, Atlanta, Detroit, Lansing, LA, and Philly. I personally will see almost half the sessions before we arrive in Mesa and hope to see more at Southwest Fox and German DevCon.

This past week I saw six of the sessions and I already learned enough stuff where it is entirely worth the effort I put in to make Southwest Fox happen. I think you will find out the same thing when you attend our conference.

Months of preparation come to a climax today as we announce our speakers and sessions, and get rolling on the registration for Southwest Fox 2009. Even though this is our third year doing this, it is still exciting and still fun. We also added some new wrinkles into the event.

1. Sleep in a little more in the morning – 8:30 start times instead of 8:00.
2. “Green option” for registration to skip the conference binder, but still get materials in PDF before the conference.
3. New registration application to electronically send in the registration.
4. Super-saver, early-bird, and regular registration levels and times.
5. New “Technology” track looks at tools and technologies to make life as a developer easier or more productive, including such things as virtual machines and source control.

There still may be a few surprises to come too.

We also worked very hard with the budget to ensure people had the opportunity to register for the same price as last year. We are doing the best we can to continue to make Southwest Fox fit into your budget this year. The conference center hotel rooms are the same price as last year, and the conference fee is the same price as last year if you register before September 1st.

Topping the first five Southwest Fox Conferences is not an easy task. Coming up with new ideas while retaining the best of the past is a challenge each year. Still, I think we have put together the foundation to make this year the best ever.

One of the other new things is our first ever Ceil Silver Ambassador. Cesar Chalom is coming to represent the Fox Community from Brazil and South America. We made this announcement a couple of weeks ago. Since the announcement I have heard from a lot of people who are really excitied to meet Cesar in person. I know I am one of his fans and look forward to seeing him in Mesa.

Over the last six months or so we have been working very hard to encourage some new people to share their knowledge with the Fox Community. This has been a goal of the organizers since day one. Over the last couple of years we had a few speakers who have not spoken in a while return to the speaker circuit and have introduced a couple of new people, but not to the level we initially hoped for. This year is completely different though and I am really excited that we have what I am refering to as the fab five freshmen (Steve Ellenoff, Walt Krzystek, Jody L. Meyer, Paul C. Mrozowski, and Jim Nelson) speaking for the first time at Southwest Fox. Jim and Walt took part in the “Show Us Your Apps” session last year, Steve spoke at Fox Forward a couple of years ago, and Paul and Jody deliver regular presentations at their local Fox user groups so they are not really rookies. I think this is super important moving forward to grow the speaker community and this is a huge step in the right direction.

Naturally we are also bringing back some seasoned favorites too. Menachem Bazian, Rick Borup, Craig Boyd, Mike Feltman, Toni M. Feltman, Tamar E. Granor, Doug Hennig, Cathy Pountney, Rick Schummer, Alan Stevens, and Christof Wollenhaupt. A terrific line up.

Some of the great things you already expect from Southwest Fox:

1. Terrific selection of sessions from great presenters.
2. 28 regular conference topics, 4 simultaneous sessions, 4 pre-conference sessions, and a keynote will pack your days with learning opportunities and inspiration.
3. White papers from every session (mandated by the organizers) so you can read about sessions you can’t fit into your schedule, or review material you saw at the conference when you return home.
4. Lunch Thursday if you register for two pre-conference sessions
5. Lunch Friday and Saturday for all attendees
6. Dinner Friday night

I hope you take some time to review the sessions when you have a chance. I also hope you will consider joining us in Mesa this October.

All the details are posted on the Southwest Fox Web site. Watch for more news on our conference blog and follow us on Twitter too.

Microsoft moved all bug reporting for VFP to their Connect system years ago. The FoxPro Community followed the Microsoft direction with some kicking and screaming. One of the drawbacks of this was the VFP reports went through the Visual Studio group and we never got the feeling of being a first class citizen in the process.

Microsoft has fixed this. Well, sort of fixed this. {g}

About a month ago Gianni Turri posted a message on the ProFox list server noting a bug report he posted was rejected with the following message:

Thank you for submitting this Connect Issue. Visual FoxPro is no longer supported though Connect. Please use the Visual FoxPro Support Center (http://msdn.microsoft.com/en-us/vfoxpro/bb190294.aspx) or the Visual FoxPro Discussion Forum on MSDN (http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=60&SiteID;=1) for more information or suggestions. You can also contact Microsoft Help and Support (http://support.microsoft.com ) for further assistance. For additional information please visit the Community Resources page on Visual FoxPro MSDN site (http://msdn.microsoft.com/en-us/vfoxpro/bb190227.aspx) as well as the VFPX project on CodePlex (http://www.codeplex.com/VFPX). Thank you, Visual Studio Product Team.

[Editorial note: interesting plug for VFPX - yeah!]

I confirmed this with Milind Lele. He told me Microsoft Connect is great for products in continuous development and allows better management of the reports to flow into the next release. All Visual FoxPro bug reports need to go through Product Support Services.

To get to Product Support Services you go here: http://msdn.microsoft.com/en-us/vfoxpro/bb190294.aspx

Near the bottom of the page you will find “Get Help from Microsoft”. Click on Assisted Support. Scroll through the list of products to find Visual FoxPro 9.0 (or 8.0) and click on the link. Or you can go to this link:

http://support.microsoft.com/oas/default.aspx?Gprid=7992

You will see three options:

1. Email Support (24 hour response time, two free incidents, US$99 for support)
2. Online Request to be called (US$259 per incident, response time based on severity)
3. Request by phone (US$259 per incident during business hours, US$515 after hours)

Other options for contracts are available.

So I asked about “paying” to report a bug. You do initially have to pay if you are past your two free support emails. But if the support people determine it is a product bug (their definition of being out of spec, not your perception of what you might consider a bug), your payment will be credited. Exact words from Milind:

Actually for a valid bug, the charges get reverted. The quickest way to get a fix is to have a hotfix issued. And the fastest and surest way to do that is to create that request from support.

The good news: you will be routed to the folks that know VFP best and in my opinion, some of the sharpest folks supporting software anywhere. Plus the reports are going directly to them, not through a system that treated our favorite product as less than first class.

My recommendation: if you think you have run across some “buggy feeling feature” in Visual FoxPro, post the issue on one of the forums. Let the Fox Community help you flush out any issues to see if it is indeed a bug. Then report it though the Product Support Service channel.

One of the hallmarks of FoxPro and Visual FoxPro is the level of backwards compatibility the Fox Team was committed to during the decades it was created and enhanced. The compatibility was not just from FoxPro to FoxPro versions, but often was extended to other XBase flavors such as dBASE and Clipper. One of the side-effects of this decision by Fox Software and Microsoft is that developers can easily port code forward, even when there might be easier or better ways to accomplish the same thing.

Over the last week I have helped another developer migrate some Clipper DOS code to Visual FoxPro. The decision to do a direct port of the code was made way before I was asked to help. Because of the deep commitment of the Fox Team this port was working except for three areas where the developer requested my help. The one aspect that caused me the most grief was colors – requirements are to match the colors exactly as the old system.

I figured the color issue would be a snap because the color settings were done through procedures, not on individual @SAY,@GET lines. Each procedure had SET COLOR TO commands. What I did not realize was the color pairings in Clipper were done in numbers instead of letters (apparently Clipper supports both). Visual FoxPro seems to run the code, but the colors were not matching. Took me a while to figure this out,but VFP is more accurate with color pairings as letters. Once I understood this trap I was able to get the colors going in the right direction.

One issue with the colors though was the background color was not set correctly on many of the screens. The @SAY and @GET code displayed correctly. What I learned is that VFP is setting the screen backcolor to the backcolor of the first @SAY done after a CLEAR. Unfortunately that took me a long time to figure out. Once I understood how it works I developed some code that handles it. Oh, and don’t think you can just set _SCREEN.BackColor, it does not work well with @SAY or @GET code.

I guess the Fox Team did not sufficiently test scenarios with @SAY and @GET compatibility (tongue firmly planted in cheek).

Why am I posting this? Is it because I believe many people are running Clipper or FoxBase/FoxPro code in Visual FoxPro these days? No. Just as a reminder to those developers who are faced with the choice of migrating old code to Visual FoxPro and some of the headaches you might face if you select to go the route of running the “compatible” code in Visual FoxPro. The backwards compatibility with old style user interface elements might not be as compatible as you would like. I believe the developer I am working with made the right call for his customer’s situation, and the customer’s requirements and budget, but the cost is going to be many hair pulling moments. Unfortunately in my case I was working with a fixed price budget, and I blew the hours by three times the allotted amount of time. So much for my weekend being fun.

Another lesson re-learned at the school of hard knocks.

Earlier this week I finished writing the chapter on the Upsizing Wizard for the upcoming Sedna update book we are close to completing. In the chapter review Doug Hennig pointed out a possible third way to run it (the first two being from the VFP Command Window and from the Data Explorer). He suggested trying to rename the Sedna Upsizing Wizard to the name of the old Upsizing Wizard and copying it in the Wizards folder under the VFP root.

This got me thinking. All the Wizards are driven off a table called Wizards.DBF. What if I just added a record in this table and pointed it to the new Sedna version? It works. All part of the extensibility of the Visual FoxPro IDE.

First locate the Upsizing Wizard record in the Wizards table:

USE (HOME() + "WizardsWizard.DBF") ;   IN 0 SHARED ALIAS VFPWizard

SELECT VFPWizard

LOCATE FOR Name = "Microsoft SQL Server Upsizing Wizard" ;      AND Type = "Upsizing"

Change the Program memo field to:

c:program filesmicrosoft visual foxpro 9sednaupsizingwizardupsizingwizard.app

Or alter the path to your environment setup as needed.

If you want both the original and the Sedna version, just do a SCATTER and GATHER and make the change in the second one. I recommend also changing the Name column because each time you start up the Upsizing Wizard from the menu you will select between the two and the Name column is displayed for you to pick which one you want.

The downloads for the chapter will include a program you can run to correct the registration.

As you may know, the April 2008 version of the VFP 9 SP2 Help file is broken. Actually I would consider it a serious mess. Lots of cosmetic things broken, and hyperlinks broken on important things like properties, events, and methods. I blogged about many of the problems found. A real mess, literally unusable, and not much hope from Microsoft to get it fixed by the Help team because of resources.

Several people (who will remain nameless at this time) started working behind the scenes to fix the Help file by decompiling it, repairing the problems, and rebuilding it. Some of us allegedly got closer than others and there allegedly was lots of collaboration, but one person allegedly made a serious breakthrough with lots of time put into getting it corrected.

I contacted Alan Griver and asked if a Help file allegedly was fixed, would Microsoft post it for the Fox Community to use it. You see, there are lots of legal entanglements with copyrights and third-parties and no one wanted anyone to be thrown in jail. It took a while and I was starting to lose hope.

A couple of nights ago Alan emailed me with the news that we can post the changes on VFPX under the Creative Commons license. This means the Fox Community has the rights to improve the VFP 9 SP2 Help file! Some final tweaks are going to be made to the new file, and one additional fix has to be made, but soon a usable VFP 9 SP2 Help file will be posted.

Thanks to Alan Griver for spending time battling Microsoft Legal and going to bat again for the Fox Community. Proof again that even though there might not be an official Fox Team at Microsoft, we still have friends who are helping us out. And thanks to all allegedly involved in the battle to assemble the Help file without some key source files. You know who you allegedly are and you folks rock!

Those following along on Twitter know that I am working with Craig Boyd’s GridExtras class in one of my customer projects. This is an interesting tool that is making me look really proactive to my customers.

One of the features is the ability for users to double-click on the header and the RecordSource is sorted on the column in the grid. Jody Meyer enhanced this to toogle from ascending to descending to no order. The columns can also be filtered which is an awesome feature because Craig mimics the dialogs to work like column filtering in Microsoft Excel. Both of these features put images in the headers of the columns to give the users a visual clue of what is going on for the grid.

For some reason I was not getting the images in my grids. Obviously it is working for Craig because the sample app he ships has the images displayed. It is not a VFP 9 SP2 thing, because I could run his app in VFP 9 SP2 without any issue.

On a whim I moved the images from the gridextras folder I have under a different directory tree on the same drive, and put them into an images folder underneath the project. I then removed all the pointers in the project to the image files and added the images from the new folder into the project. Rebuilt the EXE and presto, the images show up in the grid header. Nice.

My question is why? All the images are compiled into the EXE either way as I did not exclude them in the Project Manager. VFP should be able to find the images in the EXE. Is there a logical answer, or is this one of the VFP quirks I have to remember to work around in the future?

Last night one of my clients was implementing their vertical market application half way around the world. The onsite support people were reporting an error when the app was started: “Invalid path or file name.”

Thanks to the new error handler we implemented in the app I tracked this problem down to a single line of code:

CD &lcDataPath;

Looking at the value of lcDataPath it became instantly apparent what the problem was, spaces in the folder name. The tech support person right away explained to me the standard for the install is no spaces in the folder names. This site deviated from the standard folder name recommended by my customer. Now she knows exactly why the original developers proclaimed this “requirement” years ago.

I have not been burned by spaces in code for a long time because I always use indirection in my code whenever I deal with file names or folders.

CD (lcDataPath)
USE (lcFileName) IN 0 SHARED AGAIN
DELETE FILE (lcFileName)

I posted this issue on Twitter earlier today and Andrew MacNeill noted this is probably a great rule to add to Code Analyst up on VFPX. I agree. I am now curious how many developers do not test their applications in folder structures with spaces in the name. I just checked my development machine and all my test folders are space free. But I do install my applications on a virtual machine in the Program Files folders and this tests out the space problem.

Yet one more reason why we have standards at White Light Computing and why the adoption of industry best practices gives us more solid deployments and apps in production. Fortunately the onsite tech people were okay with renaming the folder, otherwise my customer would have been hiring us to review the application for other macro expansion gotchas.