Shedding Some Light

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.

I just downloaded the latest update to the VFP 9 SP2 Hotfix this evening. This latest file includes the missing VFP9T.DLL (Multi-threaded runtime) file.

Same place, same bat channel…

http://code.msdn.microsoft.com/KB968409

I have been told the other hotfixes are no longer password protected too, but I have not had time to test because of a limited bandwidth while on vacation.

Earlier today in the comments section on my post about the release of the new VFP 9 SP2 hotfix, Sergey Berezniker and Emerson Santon Reed noted the VFP9T.DLL runtime file is not included in the post. It is something I noticed the day of the release but was tainted by the fact the Report Designer is not valid in the runtime. What I forgot is about the rollup of the previous hotfixes and how they should be included. The multi-threaded runtime is in the included Merge Module so you can get it by building an installer and installing the file. But it would be much simpler to get the file in the hotfix download.

The other issue is the previous two VFP 9 SP2 hotfixes (not the latest) just posted on Code Gallery still have the download files password protected. Annoying for sure, but not super critical because the new hotfix has these two rolled up. The business case for the old hotfix might be valid for some developers.

I contacted the Fox Team at Microsoft this morning and they jumped on the issue. This evening I got word that the fixes are in the final stages of getting prepared for release and should be ready in the next few days.

So the choice is yours. You can pull the hotfix and start testing the changes and how they impact your application. If you want the multi-threaded runtime and don’t want to build an install to get it, just hold still for a few more days. Things are getting fixed in all three downloads.

10, 9, 8, 7, 6 (main engine start), 5, 4, 3, 2, 1…. Liftoff!

I bet you think I am talking about a launch of NASA’s Space Shuttle. If you know me this is a good guess, but this time you are wrong. I have better news!

Microsoft has released a hotfix to the most serious Report Designer bug in VFP 9 SP2. This is the Data Group bug Cathy Pountney first blogged about here: Gotcha: Serious report bug with Data Groups introduced in VFP 9 SP2.

You can read about the fix in the Microsoft KnowledgeBase article #968409, titled “FIX: The group header of a data grouping is not printed at the top of each page as expected after you install Microsoft Visual FoxPro 9.0 Service Pack 2”

This fix is considered by many to be the most serious bug introduced in VFP 9 SP2, and has often been referred to as the main stumbling block to the adoption of VFP 9 SP2. I am hopeful with this news that you will consider downloading the new hotfix and giving it a try to see if it works well for your apps. Only you can make the determination on what is best for your customers. Yes, there are more bugs to squash, but a high percentage of them have decent workarounds where this particular bug did not.

Additionally, there is some terrific news on how you can get the hotfix. Previous to this release Microsoft only made Visual FoxPro hotfixes available by calling Microsoft Product Support Services (PSS), report the bug in the hotfix, and then Microsoft would make it available to you. Hotfixes are easier for the team to release because there is less overhead, but getting it to the Fox Community is a pain in the neck because of the PSS bottleneck. So the “Fox Team” came up with releasing this important hotfix through MSDN Code Gallery so any Visual FoxPro developer can download and apply the patch without calling PSS. I think this is a real positive move for the Fox Community.

The hotfix can be downloaded on the download page of Code Gallery for the KB article.

Both the other hotfixes released for VFP 9 SP2 are rolled up into this release so if you have patched SP2 for the following fixes they are included in the new build:

1. FIX: The toolbar on an SDI form is disabled in Visual FoxPro 9.0 Service Pack 2 (build 6303, 12-Apr-2008, KB 948528)
2. FIX: Records from another user session that violate the criteria for a parent table are displayed in the browse window for a child table in a Visual FoxPro 9.0 Service Pack 2 multiuser environment (build 6602, 03-Jun-2008, KB 952548)

Update: Milind Lele tells me the previous hotfixes for VFP 9 SP2 are also available on MSDN Code Gallery (just in case you are not interested in the Group Header fix. {g})

http://code.msdn.microsoft.com/kb948528
http://code.msdn.microsoft.com/KB952548

Just in case you have not heard, in addition to the core EXE and runtime hotfixes we have a new VFP 9 SP2 Help file available on VFPX.

I am very excited about this news. I want to thank the “Fox Team” for their hard work and personal efforts to make the hotfix happen. I also want to thank those in the Fox Community who have reported VFP 9 SP2 bugs, those who have documented the workarounds, those who researched when some of the alleged SP2 bugs really surfaced, and those who tested out the hotfix to ensure it is the best possible fix for the reports at this time.

Hopefully this is just the third in a string of hotfixes we will see from Microsoft as they support the product we all love. Today is a very good day. This is one small step for VFP, one giant leap for VFP developers. Please spread the word!

Update: Read more about this release on Cathy Pountney’s blog!

Today is the day the session proposals from potential speakers are due. If you sent topics in for consideration and did not get a response from Tamar, please resend them to speakers AT swfox DOT net. You can also copy to info AT swfox DOT net if you want to have a backup submission.

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!