The ReportPreview.app is a pretty good general preview application for Visual FoxPro 9. The look of it mimics the report preview screen we had prior to Visual FoxPro 9 and it provides much of the same functionality as well as some new features available in Visual FoxPro 9 thrown in for good measure. However, some Visual FoxPro developers are having problems with certain aspects of it.

Running ReportPreview.app as a modal preview (report form command) in a TopLevel form application will cause the print preview toolbar to stop responding. That's because the ReportPreview.app brings the preview form up in a modal state and toolbars are not accessible when a modal form is active. For the most part, this is as it should be and is in-line with Microsoft Windows conventions. The answer is to include the NOWAIT clause in the report form command or you can modify the ReportPreview.pjx to force it into a modeless state when this situation occurs. Easy enough right? Well, the problem with this approach is it usually defeats the very thing that the developer is attempting to do... mainly, bring up a modal preview window in a TopLevel application (I want the preview window to come up, then I want to wait until the user has released the preview window before continuing with my code execution).

If you haven't run into the aforementioned problem you can reproduce it by opening up the Taskpane in Visual FoxPro and go to the Solutions Samples area. Then expand the "New in Visual FoxPro 9.0" node and look for the "The typical multiple detail band report" sample. Over on the right-hand side of the sample there is a little report and magnifying glass button that says "Click here to view the code" in its tooltip, click that button. Next modify the ShowWindow property of the form that pops up (ShowWindow = 2 - As Top-Level Form). Close the form and save your changes, then run the sample. You'll notice that the toolbar does not respond to user events. To close the sample you'll have to close the report from the "X" in the top right corner of the preview window.

Another thing about the ReportPreview.app is that it looks a little antiquated to me. I may be the only one that feels this way, but I suspect not. Now, before the flames start... I'm not saying that I don't think the MS Fox Team didn't do a good job. I'm all for having them just give us access and allow us, as seasoned Visual FoxPro developers, develop the rest. I don't want them wasting time mocking up Visual FoxPro forms and applications that I can create myself. I feel like we are all well served by them opening the guts of Visual FoxPro up to us as developers, give a basic example of the new feature's use, and then let us do the rest.

So, last night I decided to rip into the ReportPreview.pjx and see what I could do. I made an exact copy of the entire Report Preview project folder from XSource and then began modifying it. Basically keeping the stuff I liked, deleting the stuff I didn't, and modifying the rest. The result was a ReportPreviewEx.app that can be used in lieu of the ReportPreview.app. To use it you'll need to set the _reportpreview system variable to the new application:

_reportpreview = "reportpreviewex.app"

This will cause Visual FoxPro to use the new print preview application. To try it out run one of the report samples in the Solutions Samples area of the Taskpane underneath the "New in Visual FoxPro 9.0" node. The names of the samples are "A multiple detail band report used for calculations" and "The typical multiple detail band report".

This new application doesn't suffer from some of the drawbacks the ReportPreview.app does. For instance, instead of toolbar, I placed the buttons and such directly on the frxpreviewform class. This fixes the problem with modal previews in a TopLevel application and is more in-line with print preview windows such as the one in Internet Explorer.

I ran into more than a few issues while creating this, but almost all of them have been resolved successfully. However, one issue that is still plaguing me is the way the MS Fox Team failed to implement double-buffering correctly when rendering emf content in an image control. Emf file format is perfect for reports because meta-files scale better than anything else on the planet. But, when you are running the print preview you are going to see a slight flicker. Regrettably the MS Fox Team has not opened up the internal painting routines to us, so I am unable to insert the proper code that should be used when Visual FoxPro is repainting the image controls. That having been said, I added a property to the frxpreviewform form class of the frxpreview.vcx that allows you to try out all the other formats and their results. The property is "outputimagetype" and has the following possible values: tiff, bmp, png, jpeg, gif, emf. If you want to try another format that doesn't have the flicker and still has perhaps acceptable quality, change the property to "png". The drawback to this format is that it looks blurry at large zoom levels and Visual FoxPro turns into a bit of a performance hog with its internal painting routines.

I posted a comment on Calvin Hsia's blog recently asking him to pull the curtain back further on the internal painting routines for Visual FoxPro, and I've asked other members of the Fox Team in the past to please give us a little insight into this so we can address issues such as this effectively and help Microsoft out a little at the same time. Regrettably, they have ignored me so far. I wish that their new goal of transparency extended towards the Visual FoxPro core as well. I understand that they have trade secrets/intellectual property rights to consider, but I think they could use some help in this particular area.

Now some of you are no doubt thinking, why didn't Craig just use the outputpage method of the Report Listener class to render to a canvas object (shape or container control). The reason is that Visual FoxPro will paint right over the top of anything that gets in the way of the canvas object. So, if you have a bunch of canvas objects inside a container and you are allowing the canvas objects to be slid around inside the container so that portions of them are outside the dimensions of the visible container (left = -150 or top = -200 or whatever), the Report Listener doesn't respect the container's borders, so it starts rendering the report right over the top of other form elements. So, the answer is to use an image control and temporary off-screen bitmaps assigned to their picture property. Why not a container (it has a picture property)? Well with the image control I pick up a little more overhead, but it gives me some really good additional functionality for free (such as the stretch property that makes zooming in and out on print preview a breeze from a coding standpoint). There's more to this whole sorted saga, but I think you get the general idea.

So, here's a screen capture of the new print preveiw, a link to download the ReportPreviewEx.app, and an additional link to download the entire source -- IMPORTANT NOTE: I've just looked through the redist.txt that comes with Visual FoxPro and I cannot find anywhere that certain elements of the ReportPreview.pjx are on the allowable list - I will email Microsoft for clarification - until I hear back from them, I have removed the source code link.

Download ReportPreviewEx Application (approx. 47 KB)