VFP9 Reporting APPs on VFPx

I apologize for not posting this sooner. It has been a little busy lately...

I have graciously agreed to take on the role of project manager for the VFP9 reporting APPs and _ReportListener FFC libraries on VFPx. This responsibility will include releasing code updates and coordinating any enhancement requests going forward. I think Lisa Slater Nicholls and Colin Nicholls did a fantastic job with the new reporting features in VFP 9 and the additions made in SP2 are a nice plus. I am honored to be chosen to help carry the project forward.

See Lisa's comments here

Lisa has been very helpful to me and my product since the reporting features were in beta and she has agreed to be available during the transition, if needed. She has also stated that she and Colin will continue the work on the TMM documentation as their busy schedule permits.

I am in the process of dissecting all of the known bugs related to SP2. I am especially sensitive to any Reporting related issues. So far, most all of the issues appear to be in the core product, but if I find an opportunity to address it with an XSource solution, I will try to make that workaround available on VFPx until we can get a core fix from Microsoft.

If you find an issue that needs to be addressed, or you have an enhancement request that you think would be benefecial to the community, or you have a really cool feature you would like to share, you are welcome to post a discussion onto the VFPx web site to be considered for a future release.

Thursday, March 06, 2008 6:17:48 AM (Eastern Standard Time, UTC-05:00)      Comments [0]  

Visual FoxPro 9.0 SP2 or not... Post 3

Here are 5 more SP2 bugs evaluated. These were all reported by Bernard Bout. Even though I am kind of downplaying the severity of some of these issues, I really do appreciate him posting his finds on the SP2 Bug List and on the Microsoft Feedback site. Part of the reson I am doing this series is to encourage other people to get SP2 installed and evaluated. If you find an issue, please let us know and most importantly, report it to Microsoft. If we all sit back and let other people like Bernard and Cathy Poutney find all the issues, what percentage of the issues are we going to actually find? We can't just sit back and talk about Microsoft as a 3rd party and say that they owe us a better product, but never tell them what's wrong. I believe Microsoft is willing to address critical issues in the core, if we let them know about them.

Microsoft may be willing to address issues in the XSource, but that really doesn't concern me because we can take care of those issues ourselves. All of the XSource is now on VFPX, waiting for issues to be reported and/or developers to fix them....

Issue: Help file missing items off the index tab
Submitted By: Bernard Bout
New to SP2: Yes
Impact for SP2: Low
Feedback ID: 306332
Solution Available: No
Workaround Available: Yes
Bug Location: VFP9 Help

I can’t imagine how this happened, but it did. But just to clarify, all of the help items are in the SP2 help file; the issue is that over 100 help items do not appear in the “Index” tab. This not only affects the index tab, but also highlighting a keyword in code and hitting F1.

The good news is that Bernard has confirmed that Microsoft is already working on this problem and we should have a fixed help file soon. Until then you can use the “Search” tab to locate the help topic you are looking for. You can also just use the help file from SP1. Just make a backup of dv_foxhelp.chm file from VFP9 or SP1 before upgrading and either use Tools -> Options -> File locations to set the old help file or just copy it into the HOME(1) folder of VFP9 after installing SP2 to overwrite the SP2 help file.

Should this stop you from upgrading to SP2? No. It’s an easy workaround, a fix is on its way and it shouldn’t affect your applications in anyway.

 

Issue: VFP SP2 ToolTipText not displaying for Grid.Column.Header and Grid.Column
Submitted By: Bernard Bout
New to SP2: Yes , but I should mention that this was broken in VFP9 RTM, fixed is SP1 and broken again in SP2.
Impact for SP2: Medium
Feedback ID: 311817
Solution Available: No
Workaround Available: Yes, but probably not satisfactory for developers that use this functionality.
Bug Location: VFP9 Core

I can only speculate that this was broken when the 5 or more issues related to grids or tool tips were addressed in SP2. I can see where this would be very annoying to developers that use this functionality to deliver well polished applications. And especially to see it come and go (new to VFP8, broken in VFP9, fixed in VFP9 SP1, broken again in VFP9 SP2).

(update 03/05 9:37pm - Correction: this bug did not exist in VFP9 RTM. It was introduced in VFP9 SP2)

There is a workaround using a technique shown on the Feedback page and also published in 1001 Things You Wanted to Know About Visual FoxPro by Marcia Akins, Andy Kramek and Rick Schummer. This technique was used back before we had a ToolTipText property for Headers (which was introduced in VFP8). It basically works by using the MouseEnter and MouseLeave events to toggle the Grid’s ToolTipText.

This works ok, but because of the way the tool tips are updated and the way the grid responds to mouse events, it doesn’t always update a smooth as you would like; especially not as smooth as it worked in VFP8 or in VFP9 SP1. And if you are even using these tips you are probably a developer who likes to deliver well polished apps and you are probably not going to like the annoyance that comes with this workaraound.

So if you are using the ToolTipText for Columns or Headers, be aware that they do not work in VFP9 SP2. I would also HIGHLY recommend that you go to the Microsoft Feedback page and cast your vote on this bug. The more (constructive) feedback that Microsoft receives about this issue, the better our chances are of having it fixed.

Should this stop you from upgrading to SP2? Maybe, and only if you are using these tool tips. If you are not, then there is no reason not to upgrade.

 

Issue: Undocumented change in COM when passing DATETIME value to .NET
Submitted By: Bernard Bout
New to SP2: Yes
Impact for SP2: Low to None
Feedback ID: N/A
Bug Location: VFP9 Help

This is not a BUG, but actually a behavior change between SP1 and SP2. And according to Bernard Bout it is actually fixed in SP2. This was posted to the VFP9 SP2 Bug List because the behavior change was undocumented.

Should this stop you from upgrading to SP2? Absolutely not.

 

Issue: Web Services Registration - If field returns NULL then error registering Web Service
Submitted By: Bernard Bout
New to SP2: Yes
Impact for SP2: Low
Feedback ID: none
Solution Available: Yes
Bug Location: VFP9 XSource

I have not been able to reproduce this error, nor can I find any difference in code or libraries between SP1 and SP2 that would cause the behavior change. However, Bernard found it and posted a solution. This is an easy fix with an NVL( ). Since this change is in the XSource, I think we should fix it out on VFPx instead of involving Microsft.

(update 03/05 9:37pm - Tamar Granor supplied a valid repro for this issue: http://fox.wikis.com/wikiwebservice.wsdl. Registering this web service using the Intellisense Manager in SP1 works, but fails in SP2 with a "column does not support null values" error)

Should this stop you from upgrading to SP2? No. It’s an easy fix, It only happens in the VFP dev environment and only rarely.

 

Issue: Changes to the code in FFC\_reportlistener.vcx breaks SP1 reports
Submitted By: Bernard Bout
New to SP2: Yes
Impact for SP2: Low
Feedback ID: none
Solution Available: Yes
Bug Location: VFP9 XSource (though it is not really a bug)

As Colin Nicholls says in the VFP9 SP2 Bug List, this is not really a bug. However it is a behavior change between SP1 and SP2 that caused code not to work from an article, written by Doug Hennig, about including hyperlinking on reports. There are a couple lines of debate between Bernard and Colin about whether this should be considered a bug or not. Since my series of blog post are about dispelling unfair attitudes about SP2, I’m going to have to side with Colin on this one, and I will explain why. But since there is an easy solution, I think everybody will be happy in the end.

In Doug’s article he talks about “poking” through the HTMLListener class of _REPORTLISTENER.VCX and finding this code:

<xsl:when test="string-length(@href) &gt; 0">
  <A href="{@href}">
  <xsl:call-template name="replaceText"/>
  </A>
</xsl:when>

I’m sure this was the start of what we finally ended up with when we got hyperlink support in SP2. However this was undocumented and the final SP2 implementation looks like this:

<xsl:when test="string-length(@hlink) &gt; 0">
  <a href="{@hlink}">
  <xsl:call-template name="replaceText"/>
  </a>
</xsl:when>

Note the attribute change from “href” to “hlink”. So now the code from Doug’s article doesn’t work anymore. Bernard posted a solution from Sergey Berezniker onto the Solutions To VFP9 SP2 Bugs page. His solution was to just add the earlier code back to support both old and new options:

<!--------- Add this --------- -->
<xsl:when test="string-length(@href) &gt; 0">
  <A href=" {@href}">
  <xsl:call-template name="replaceText"/>
  </A>
</xsl:when>

<!-------------- Before this  ---------- -->
    <xsl:otherwise>
      <xsl:call-template name="replaceText"/>
    </xsl:otherwise>
    </xsl:choose>

Note that this code change would be in the getDefaultUserXsltAsString method of the HTMLListener class in _REPORTLISTERN.VCX, around line number 428.

Another solution and probably a better idea is to just modify Doug’s code to use “hlink=” instead of “href=” or just use the new hyperlinking features of SP2.

(update 03/06: I can confirm now, that changing Doug's code as follows, will fix the issue also)

Change this line:

   lcInfo = lcInfo + ' href="' + ;

To this:

   lcInfo = lcInfo + ' hlink="' + ;

And add:

   SELECT frx

Before:

     dimension .aRecords[reccount()]

Should this stop you from upgrading to SP2? No. The change is easy and it only affects projects that have implemented Doug’s hyperlinking code.

 

This is all for now. I will try to take on a few more tomorrow...

I hope this helps you make an informed desision about SP2. Again, my intent is not to downplay or shun the reported issues. I think they should all be addressed, but we should all make an informed decision about upgrading to SP2 before we completly dismiss it.

 

Wednesday, March 05, 2008 10:47:41 PM (Eastern Standard Time, UTC-05:00)      Comments [4]  SP2 | VFP Development

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