Visual FoxPro 9.0 SP2 or not... Post 2

Something I didn't emphasize in my previous post, but Craig Boyd reminded me in his comments, is that many of the issues people faced with SP2 could be traced back to a problem with the installation. Not with the actual SP2 release itself.

To ensure a clean install of SP2, you MUST start from scratch. This includes uninstalling and reinstalling VFP9 RTM. You don’t have to install SP1 before SP2, but if you want to go back to SP1 or have SP1 available for testing, I highly recommend you get Rick Schummer’s white paper with instructions on installing both versions on the same machine.

Ok, so working with the SP2 Bug List from the Visual FoxPro Wiki, I’ll start from the top down:

Issue: Toolbar in Report Preview not working with VFP SP2
Submitted By: Bernard Bout and Peter de Valenca
New to SP2: No. However it was reportedly fixed in SP1 and now it’s back.
Impact for SP2: Low to Medium
Feedback ID: 306390
Solution Available: No
Workaround Available: Yes
Bug Location: VFP9 Core

This is one of the bugs that gets blamed on the new VFP9 reporting features. However, this is NOT a bug with the new reporting. It is however exposed by the new reporting. It occurs when you have a modal form, inside of a top level form along with a toolbar. The toolbar becomes unavailable. Why was it fixed in SP1 and now its back? I’m guessing that the change made to SP1 to address the issue may have broken something else and they had to roll it back.

Some background information; I was fortunate enough to make it to the February Detroit FoxPro User Group Meeting, in which Christof Wollenhaupt gave a marathon, 3 hour session on “The Dark Side of Visual FoxPro”. One of the things he covered was a solution for the VFP bug when using ActiveX controls with modal windows. He has some information available in a blog entry. I never realized this but “modal windows do not exist in the Windows API”. According to Christof, Windows creates a modal state by disabling the parent window. This explains why you cannot have a “top level” form in VFP that is also “modal” (.ShowWindow = 2). If it is a top level form, you don't have a parent to disable.

This also explains what is probably happening when you put a modal form, inside of a top level form along with a toolbar. Either the toolbar is getting disabled or VFP is just not responding to the toolbar’s events. This is really no different than issuing a MESSAGEBOX call and expecting to be able to click on the VFP toolbar. You can’t do it….by design.

So is this really a bug? Why would you want to put a modal window inside of a top level form and expect the toolbar to work? Well, because it’s a hack on a hack trying to emulate a popular technique used in VFP8 and earlier. If we wanted to preview a report, in a top level form, we could issue a “REPORT FORM PREVIEW IN WINDOW” command where the IN WINDOW clause specified a top level form. And if we left off the NOWAIT clause, this would display our report preview in a modal condition.

So what is different in VFP9 reporting? The main difference is now we have the ability to make our own custom report previewers using the ReportListener class along with real VFP forms and objects. The window we get with a VFP Form does not behave the same as the window we get when we issue “REPORT FORM PREVIEW” in VFP8. The old report preview window was handled internally by VFP. We had no control over how it was being managed or painted behind the scenes. We also have no control over how it handled its modal condition. But the biggest difference may be how it managed the toolbar. The toolbar seemed to belong to the preview window whereas in VFP9 reporting (and other VFP form uses) the toolbar belongs to the top level form.

Just to recap, this issue ONLY occurs when ALL of the following conditions are true:

1) You are using the new reporting features of VFP9 (SET REPORTBEHAVIOR 90)
2) You are displaying the report preview window in a top level form by using the WINDOW clause of the REPORT FORM PREVIEW command
3) You create a modal condition by not using the NOWAIT clause in your REPORT FORM PREVIEW command

Here is a snippet of the repro code that Peter de Valenca submitted to Microsoft

*    Peter de Valença

*    www.viafox.nl

*==============================================================\

create cursor c_effe ( f1 c(10) )

insert into c_effe values ( "aaaaa" )

insert into c_effe values ( "bbbb" )

insert into c_effe values ( "ccc" )

insert into c_effe values ( "ddddd" )

 

create report effe from c_effe

 

SET REPORTBEHAVIOR 90

 

LOCAL loReportWindow

 

loReportWindow = ReportWindow()    && creates an as-toplevel form

 

WITH loReportWindow

    .Caption     = "some title"

    .WindowState = 2    && maximize

    .Show()            && must be done to force the maximizing

ENDWITH

 

* make sure the report can load and run

REPORT FORM effe PREVIEW window ( loReportWindow.Name )

 

* Creates a window for the report.

FUNCTION ReportWindow

    local loRepForm

    loRepForm = CREATEOBJECT( "reportwindow" )

    return loRepForm

 

define class reportwindow as form

    ShowWindow = 2    && as toplevel form

enddefine

*==============================================================/

So, what can we do about it? We have a couple of options:

A) Remove any one of the conditions above and it works fine. Of course you probably have your reasons to use the new reporting and reasons to use a top level form or we wouldn’t be here. But do you really need it to be modal? This was an issue in previous versions of VFP because the previewer only processed one page at a time. If you had an environment set up, let’s say open cursors with relationships and you wanted to clean all of that up after the REPORT FORM command was issued, you had to go modal. If you let the code continue by using the NOWAIT clause, your environment would be gone and the user would get an error as soon as they tried to navigate to the next page.

With VFP9 reporting, all pages are preprocessed before the preview window even comes up, so you don’t have to be modal and preserve your environment. Just let the code continue on and let your users multi-task. If you add a NOWAIT to the sample above, (and make the loReportWindow PUBLIC) you will see that it works fine:

PUBLIC loReportWindow

. . .

REPORT FORM effe PREVIEW WINDOW ( loReportWindow.Name ) NOWAIT

B) So that works, but there are a couple of annoyances. First, the preview window doesn’t look right. It is a window within a window. Peter makes mention of this in his bug report and provides a couple of screen shots comparing REPORTBEHAVIOR 80 to REPORTBEHAVIOR 90. You get the same affect whether you use the WINDOW or IN WINDOW clause. But again, this is a limitation of using VFP Forms for the report preview and placing a window within a window. The other annoyance is that we had to declare our parent form as PUBLIC. This is because we need the form to stick around after the REPORT FORM command has finished. But this should be nothing new to developers who use top level forms.

There is an easier way around both of these annoyances and it actually requires the use of LESS code. With the VFP9 reporting, we can customize the preview container with a lot more options than we had before. One of the options is to force a top level form by setting the .TopForm property of the PreviewContainer object. This eliminates a lot of goofy code that we had to do in the past. You will also notice in the sample below that our variables are declared LOCAL. We can do this because the preview container is managing our form reference for us. Here is the new code:

*==============================================================\

CREATE CURSOR c_effe ( f1 c(10) )

INSERT INTO c_effe VALUES ( "aaaaa" )

INSERT INTO c_effe VALUES ( "bbbb" )

INSERT INTO c_effe VALUES ( "ccc" )

INSERT INTO c_effe VALUES ( "ddddd" )

 

CREATE REPORT effe FROM c_effe

 

LOCAL pc, ri

DO (_REPORTPREVIEW) WITH pc

pc.TopForm = .t.

ri = NEWOBJECT("ReportListener")

ri.ListenerType = 1           && preview

ri.PreviewContainer = m.pc

REPORT FORM effe OBJECT ri

*==============================================================/

Here is what the new improved form looks like

There are other properties available to customize the report previewer, check the VFP9 help topic Leveraging the Default Preview Container for more information.

C) There may be another option, but I will have to come back to it later. Christof sent me some sample code today showing how he may have a way of switching up the parent window for the toolbar that seems to be a step in the right direction but there is an issue if you change the docking state of the toolbar. I’ll keep you posted if we make any breakthroughs.

In Closing

Should this stop you from upgrading to SP2? I don’t think so. If you are even trying to display reports in a top level form, I think you can take advantage of the new Reporting features and actually improve the user's experience and get rid of the modal window.

Honestly, I’m not sure if Microsoft should even try to address this issue. How can they modify the form behavior to allow toolbars to work for modal report windows, but not allow toolbars to work for other modal windows? I just think this would open up a can of worms. (Maybe it did in SP1 and that's why it's back) It may be best to code a workaraound in either the reporting APPs or use a known technique for simulating a modal condition when using top level forms, like a DOEVENTS loop.

I'm open to any comments related to this issue. I would also be interested in knowing how many people use this technique for previewing reports.

This one bug took a while to go through, but I felt it was an important one. The next few should be much shorter reading.

Tuesday, March 04, 2008 9:12:57 AM (Eastern Standard Time, UTC-05:00)      Comments [8]  SP2 | VFP Development

Visual FoxPro 9.0 SP2 or not... Post 1

There has been a lot of talk about the state of Visual FoxPro 9 SP2. It seems like many people are not willing to upgrade unless the issues introduced in SP2 get fixed. There also seems to be some confusion about what the SP2 issues encompass; VFP9, Sedna, VFPx, etc… I plan to go through these issues over the next few days to help dispell some of the confusion and offer what solutions I can to the known issues.

Why do this? Mainly because I think many people are wrongfully swayed away from SP2, Sedna, VFPx and Visual FoxPro in general for the wrong reasons. The fix list for SP2 includes a long list of fixes that have been around for years. I think the VFP team did a great job of addressing as many issues as they could using what limited resources they had available. The unfortunate part is the limited testing this service pack received which led to a few new issues being introduced.

Right now there is a list of issues and solutions being tracked on the Visual FoxPro Wiki. Of the 20 issues that are posted (as of this writing) I would break down into the following categories:

New bugs in the VFP9 Core
New bugs in the VFP9 Xsource
New bugs in the VFP9 Help File

I would define the “Core” as the VFP9.EXE and the distributable runtimes (VFP9R.DLL, VFP9T.DLL, VFP9RENU.DLL etc…). To me, these are the most critical issues and really the only ones to be overly concerned about. Mainly because we do not have the ability nor the rights to make changes to this part of the application.

Issues with the Xsource are not as critical because we have all of the source code for these modules and they can be updated as needed. They are even posted on VFPx and can me managed and distributed from a central location with timely updates.

I would not consider the “Help File” issues as super critcal either, for a few reasons, the most significant being that Microsoft is in the process of fixing the Help file. Special thanks to Bernard Bout for reporting these issues and being available to test the updates that are being worked on. The other reasons go along with the XSource reasons. If worst came to worse, the help file can be decompiled and we can fix it and recompile it ourselves. But in the interim we can just use the Help file from SP1, or live with it, for now. ALL of the help topics are included with the help file, the issue is missing index entries.

The 20 reported issues break down as follows:

Core – 6 issues
Xsource – 2 issues
Help File – 1 issues
Other – 11 issues

Note that as I go through these, over the next few days, some of the categories may get moved around. But at first look, this is where the issues seem to fall. The “Other” category includes issues that were not introduced in SP2, but rather issues that have been around before SP2 or are unexpected behavior, not really a bug. I don’t mean to belittle these issues here. These “other” issues should be addressed, and I will go through them, but since this writting is about upgrading to SP2, I think they should be broken out and excluded as reasons to not upgrade to SP2.

Also note that most of these issues are related to reporting. Most, if not all of them are in the “core” product and have nothing to do with the Reporting APPs. As a matter of fact, many people are using the Reporting APPs from SP2 with VFP9 SP1 and are quite happy with them. There were MANY new features added to the SP2 reporting APPs that are worth taking a look at, even if you don’t upgrade to SP2.

I promise to go into more detail in my next post. But this will give you an idea of where I’m headed and what to look forward to.

I feel very strongly that everyone should upgrade to SP2 and then determine if YOU have a real business case for NOT upgrading your clients. Rick Schummer has published a white paper on how to have SP1 and SP2 installed on the same development machine. If everyone sits around and waits for an SP3, we are going to be in big trouble. We need a definitive list of SP2 bugs so we can either determine an appropriate workaround or encourage Microsoft to follow up with their promise of support through 2014.

If you have found an issue with VFP (and it is still broken in VFP9 SP2) please report it to Microsoft, especially if it is in the “core” product. Also, if it appears to be SP2 specific, please add it to the SP2 Bug list on the Visual FoxPro Wiki and someone in the community, including myself, will try to address it.

Sunday, March 02, 2008 11:46:06 PM (Eastern Standard Time, UTC-05:00)      Comments [2]  SP2 | VFP Development

Peek At VFPStudio Code Editor

Craig Boyd has posted a screen cast showing a sneak peek of the VFPStudio code editor. It demontrates some of the advanced editor functionality of Visual Studio...while editing a PRG file. Very Cool!

Craig promises more screen casts in the near future, so stay tuned!

Thursday, February 21, 2008 4:06:35 AM (Eastern Standard Time, UTC-05:00)      Comments [3]  VFP Development

Wrapped Text with GDIPlusX

I was recently asked if it was possible to do "Wrapped Text" with GDIPlusX. I wasn’t sure what they meant at first, but found out they wanted a text string to render in the form a circle, instead of a straight line. While there is nothing built into the library that can do this, I knew it was possible to write your own code to get this functionality.

I dug around and found an excellent article written by Sjaak Priester. He came up with a very interesting technique. By using the FlattenPath method of a GraphicsPath and some straight forward geometry, he was able to not only get a text string to render in a circle, but to get a text string to render in any shape by using a GraphicsPath as a guide. He developed a very nice little C++ class to handle this. I was impressed by the simple yet powerful technique he was using, I decided to try it using the GDIPlusX library.

The results are attached. A relatively straight forward, 300+ line class that takes a GraphicsPath guide, a String of text and a Font and fills a second GraphicsPath with the rendered string, following the specified path. Once you have this rendered path, you can do all kinds of cools stuff with it (check out some of the text effect samples with the GDIPlusX samples download).

Included in this download is the WrappedText class, a demo form as well as the 1.10 version of the GDIPlusX library (compiled into an app). To run the demo, issue a:

DO FORM WRAPPEDTEXTDEMO

WrappedTextDemo.zip (210.63 KB)

Friday, January 11, 2008 7:56:52 AM (Eastern Standard Time, UTC-05:00)      Comments [2]  

The GDIPlusX Library Has Been Updated...Into Production

The GDIPlusX library, part of the VFPX project, has been updated and moved into production status. Rumor has it that many people were using it in a production environment already (including myself) but now its official.

With this release we have added SYSTEM.APP. This APP includes the entire library in a single distributable. Rick Strahl made this recommendation at SWFox and we liked the idea. Of course, if you prefer to compile the library into your own application, you can do still do that also. All of the source is still downloadable from VFPX.

A few other features were packed into this release based on feedback that we have received in the past few months. We would like to thank Christof Wollenhaupt, Alan Stevens, Carlos Alloatti, several members of the Foxite message board and of course Craig Boyd for your valuable contributions. Special thanks to Cesar Chalom for all of his efforts in this last release. Most all of the new enhancements were added by Cesar as well as several cool new samples…if you haven’t downloaded it yet, you should really check it out as well as the other great projects on VFPX.

Friday, January 11, 2008 7:12:44 AM (Eastern Standard Time, UTC-05:00)      Comments [0]  

An updated version of the GDIPlusX library has been posted

It has taken a while, but the GDIPlusX library is finally converted to be PRG based and has been upgraded from Alpha to Beta status. The new 1.00b version can be downloaded from here. But you should always check the GDIPlusX home page for the latest version.

There were several advantages to converting the library as I described in a message on the VFPX discussion board. The library is faster, smaller and more stable than before.

Special thanks to Cesar Chalom. Most all of the bug fixes and new features were added by him over the past couple of months while I converted the library.

We will hopefully update the project again from Beta to Production status by next month. We welcome any feedback. If you have any issues with the library, make sure you post them in the Issue Tracker so they can be prioritized and voted on.

For my next Blog entry I will discuss a little project Craig Boyd and I started on that will allow any VFP object (with a Picture property) to become a canvas object and have an associated Graphics object. There is a small sample posted on VPFX that demos this new functionality.

 

Thursday, August 16, 2007 3:32:21 AM (Eastern Daylight Time, UTC-04:00)      Comments [3]  

Insert Images into an RTF control using GDIPlusX

The RichText control that ships with VFP is very useful for providing a formatted text edit box. While this control does support the displaying of images, there is nothing built in to the control that allows you to insert an image. I have included a function below that will allow you insert an image into the RichText control at the current cursor position.

Just specify the object reference to the RTF control and the fullpath of the image you want to insert. The image can be in any format supported by the GDIPlus library (BMP, JPEG, GIF, TIFF, EMF, PNG, etc...). You can also optionally specify the Width and Height you would like the image to be rendered.

This function requires the GDIPlusX library which can be downloaded from the VFPX project site: http://www.codeplex.com/VFPX/Wiki/View.aspx?title=GDIPlusX.

***********************************************************

* Function: InsertRTFImage

*

* Inserts an image into an RTF control at the current cusor position

*

* Parameters:

*   toRTF - specifies an object reference to the RTF control

*   tcImage - secifies the image to insert into the RTF

*   tnWidth - Optional - Specifies the width to use for the image

*   tnHeight - Optional - Specifies the height to use for the image

***********************************************************

FUNCTION InsertRTFImage(toRTF, tcImage, tnWidth, tnHeight)

   LOCAL lcRTF, lcPict, lqData

   LOCAL loImg AS xfcImage

   LOCAL loGfx AS xfcGraphics

   LOCAL loEMF AS xfcMetaFile

   LOCAL lhDC, lhEMF, lnWMFLen

  

   DECLARE Long GetDC IN WIN32API Long

   DECLARE Long ReleaseDC IN WIN32API Long, Long

   DECLARE Long DeleteEnhMetaFile IN WIN32API Long

   DECLARE Long GdipEmfToWmfBits IN GDIPLUS.DLL ;

         Long hemf, Long cbData16, String @pData16, ;

         Integer iMapMode, Integer eFlags

  

   ** Make sure we have initialized the GDIPlusX library

   ** http://www.codeplex.com/VFPX/Wiki/View.aspx?title=GDIPlusX

   IF VARTYPE(_SCREEN.System) <> "O"

      ADDPROPERTY(_SCREEN,"System",NEWOBJECT("xfcSystem",LOCFILE("system.vcx")))

   ENDIF

  

   lcPict = ""

   WITH _SCREEN.System.Drawing

      loImg = .Image.FromFile(tcImage)

      IF loImg.GetLastStatus() <> 0

         ERROR "Could not open file: "+tcImage

      ELSE

         ** If we didn't specify a width, use the image's width and height

         IF EMPTY(tnWidth)

            tnWidth = loImg.Width

            tnHeight = loImg.Height

         ENDIF

         ** Get the default screen HDC as a reference

         lhDC = GetDC(0)

         ** Create a new metafile

         loEMF = .Imaging.MetaFile.New(lhDC, ;

            .Rectangle.New(0,0,tnWidth,tnHeight), ;

            .Imaging.MetafileFrameUnit.Pixel, ;

            .Imaging.MetafileType.Emf)

         ** We are done with the HDC reference, release it

         ReleaseDC(lhDC, 0)

         ** Get a graphics context for the metafile so we can draw to it

         loGfx = .Graphics.FromImage(loEMF)

         loGFX.SmoothingMode = .Drawing2D.SmoothingMode.HighQuality

         loGFX.InterpolationMode = .Drawing2D.InterpolationMode.HighQualityBicubic

         ** Draw the image

         loGfx.DrawImage(loImg, 0, 0, tnWidth, tnHeight)

         loGfx = NULL

        

         ** Convert the Metafile to a "Windows Metafile".

         ** This is the best format for the RTF control.

         lhEMF = loEMF.GetHenhmetafile()

         lnWMFLen = GdipEmfToWmfBits(lhEMF, 0, NULL, 2, 0)

         lqData = REPLICATE(0h00,lnWMFLen)

         GdipEmfToWmfBits(lhEMF, lnWMFLen, @lqData, 2, 0)

         DeleteEnhMetaFile(lhemf)

         loImg = NULL

        

         ** This is the RTF tags for the image

         lcPict = [{\pict\wmetafile8]+;

                  [\picwgoal]+ALLTRIM(STR(tnWidth*15))+;

                  [\pichgoal]+ALLTRIM(STR(tnHeight*15))+;

                  CHR(13)+CHR(10)+;

                  STRCONV(lqData, 15)+;

                  CHR(13)+CHR(10)+[}]

      ENDIF

   ENDWITH

  

   ** Stuff the image into the RTF control

   toRTF.SelRTF = [{\rtf1\ansi\ansicpg1252\deff0\deflang1033\uc1 ]+lcPict+[}]

 

   RETURN

ENDFUNC

You can also download a sample program using this function here: RTFInsertImage.zip (2.19 KB)

Bo Durban

Keywords: RichText RTF FoxPro VFP GDIPlus GDIPlusX Image

Sunday, June 17, 2007 10:11:49 PM (Eastern Daylight Time, UTC-04:00)      Comments [2]  VFP Development

HTML Tables and Styles

Have you ever tried to add borders to individual cells in an HTML table using style sheets? Something similar to <table border="1"> only done with CSS.

I had a requirement to put a 1 pixel black border between all cells in an HTML table. I wanted to do this without having to put a style or class attribute into every cell in the table. I thought: "How hard can this be?". There has to be a way of doing this with a single style attribute.

But after a quick search on the web with too many non-relevant results, (I mean what can you search for that doesn't bring back over a million hits). I decided to come up with my own technique:

<style type="text/css">

  table.border tr td,
  table.border tr th {border:1px solid black;}

  table.border {border-collapse:collapse;}

</style>

 

<table class="border">

  <tr>

    <th>Header 1</th> 

    <th>Header 2</th> 

    <th>Header 3</th> 

    <th>Header 4</th> 

  </tr>

  <tr>

    <td>Data 1</td> 

    <td>Data 2</td> 

    <td>Data 3</td> 

    <td>Data 4</td> 

  </tr>

  <tr>

    <td>Data 1</td> 

    <td>Data 2</td> 

    <td>Data 3</td> 

    <td>Data 4</td> 

  </tr>