SP2 REPORT FORM command problem



    I just installed VFP9 SP2.  I have run into a problem with existing code.  If I call REPORT FORM... from a form, foxpro prints what appears to be debug information on the form and messes it up.  Not nice and it all worked fine with SP1.  Any one else seeing this?  Here is the exact code I use.  It is called from a class that is called from a form button.




    The "junk" or debug output that appears on the form is:








    End locate scope






    Saturday, October 20, 2007 10:37 PM


All replies

  • Further to the above post I have found that it is caused by the "TO PRINTER" option of the command.  In fact you can try this yourself.  Simply to a REPORT FORM <anything> TO PRINTER and you'll see the same garbage output in the main foxpro window.  Any ideas for turning this output off?


    Saturday, October 20, 2007 10:52 PM
  • I tryed it but on my computer is working fine. If you put SET TEXTMERGE OFF before report command do you have same behaviour ?


    Sunday, October 21, 2007 2:55 AM
  • Thanks, I tried that but no difference.  I still get what looks like debug output in the main foxpro window (if REPORT FORM from the command window) or garbage in the form (if called from a form).  I tried changing printer drivers but nothing is helping.


    Sunday, October 21, 2007 4:10 AM
  • Did you have that behaviour before SP2?

    Sunday, October 21, 2007 3:46 PM
  • No I did not.  And didn't change anything, just installed SP2.  So definately a SP2 'feature' or bug I don't know yet.  Still have not found a solution.  If all else fails I will have to roll back to SP1 - not good.


    Sunday, October 21, 2007 7:24 PM
  • Aha.  It appears that you have to do a "SET REPORTBEHAVIOR 90" in order for this bug to appear.  I noticed that if I "SET REPORTBEHAVIOR 80", the problem goes away.  It appears that Microsoft left some debug output in the report engine in SP2.  Could someone else confirm this on their machine please?


    Sunday, October 21, 2007 8:42 PM
  • I confirm ...after installed SP2...

    Monday, October 22, 2007 11:59 AM
  • OK, now what?  This is a show stopper for me.  SP3?  And can they get it out today?  Sheeeeesh.......


    Monday, October 22, 2007 1:31 PM
  • I tried with REPORTBEHAVIOR 80 and is doing the same thing. SP2
    Tuesday, October 23, 2007 5:29 PM
  • It is possible. There are a lot of things "modified" after SP2....and who are working totally wrong...After I will evaluate all I can, I will take a decision to keep it or not...

    Tuesday, October 23, 2007 8:00 PM
  • My work-around for now is as follows:


    1.  Set REPORTBEHAVIOR 80 as the default.  This solves the REPORT FORM problem for now (until I run into a report that does not work I suppose).


    2.  I have XFRX.  When I am running an XFRX report, I temporarily SET REPORTBEHAVIOR 90.  The XFRX listener works fine, no garbage on screen.  When the report is done, I switch back to REPORTBEHAVIOR 80.


    So far, this seems to work OK, but not really what I wanted.  I realize the Microsoft VFP team is spread pretty thin these days but hopefully they can release an SP3.


    Tuesday, October 23, 2007 11:15 PM
  • I don't think will be SP3...may be a SP2 enhanced...

    Wednesday, October 24, 2007 12:42 AM
  • I tried this again on Windows Vista on another PC.  Same problem.  Has anyone else encountered this problem.  It is not possible to create reports using ReportBehavior 90 in VFP9 SP2.  I would think there would be a community revolt but as I search the internet....nothing.  Am I the only one with this problem?


    In addition, since the release of XFRX Version 12.4, it is no longer useable either, due to this SP2 bug.


    Saturday, November 17, 2007 3:42 PM
  • Here is one solution to this problem:


    In the LoadReport() method of fxlistener (in the _reportlistener class of VFP), move the line “THIS.SetFRXDataSessionEnvironment()” above the line “THIS.createHelperObjects()”.


    Wednesday, November 28, 2007 3:22 AM
  • Looks like the results of TALK being ON. Before the report, issue SET TALK OFF.


    Wednesday, November 28, 2007 3:23 PM
  •  Craig Berntson wrote:
    Looks like the results of TALK being ON. Before the report, issue SET TALK OFF.



    No, but thanks for replying.  That was the first thing I tried.  See my earlier post for a fix to the problem.


    Wednesday, November 28, 2007 10:49 PM
  • Good thing I've learned to save form content to disk before submitting as this site was down for a few hours a couple of days ago.


    Please pardon the disorganized content but the solution for me exists. Bottom-line, until SP2 issue with SDI forms calling a modal or modeless and "as top-level" form [Form.ShowWindow=2], show the report preview in a *clean* _SCREEN that is temporarily visible and compile the preview, output and builder apps into the run-time executable via the XSOURCE code.


    I had the same problem with the echo to a SDI form. The NOCONSOLE parameter for REPORT FORM() didn't solve the problem.


    Work-aound for me was SET CONSOLE OFF [preferred] or ACTIVATE SCREEN to dump the ouput to _SCREEN. You may need to first make _SCREEN.Visible = .F. temporarily for ACTIVATE SCREEN, but try without.


    Capture the debug text echoed to the form:


    SET MEMOWIDTH TO 256 && minimize short line-wrapping
    ...Report preview code


    Bug report:


    I resolved the SP2 bug by using a temporarily visible *clean* _SCREEN with custom preview attributes. The SetExtensionHandler() for the preview container allows access to the preview form [see VFP9 SP2 Help topic "Leveraging the Default Preview Container"]. You can view the source code for the preview form via "[VFP install dir]\Tools\xsource" to see the form properties that can be modified via the handler.



    I'm getting a runtime error regarding "listener.vcx does not exist". See the following URL about SET CLASSLIB TO ClassLibraryName IN APPFileName -- the "IN" parameter is key to pointing the embedded class library to the APP file.


    Best solution for me was to avoid including the applications



    compile into the into the run-time executable:

    [VFP install dir]\Tools\XSource\VFPSource\


    See VFP9 SP2 Help:
     "How to: Specify and Distribute ReportPreview.App"
     "How to: Specify and Distribute Report Output Application Components"
     "How to: Specify and Distribute ReportBuilder.App"


    Make certain to include the free tables in the project for ReportOutput and ReportBuilder or *include* to build into the executable, per the program help.





    [VFP9 SP2 Help]

    "Building Report Output Application components directly into your application"

    Locate the following two lines of code in the header file:


    Edit the value "OutputConfig", replacing it with the name of the table (.dbf) you want your application to use as a default value for finding the table on disk. Edit the value "_ReportOutputConfig", replacing it with the name of the table you want your application to use as a default value for finding the table built into your application, if it does not first locate a table with the default name on disk.

    You can avoid using the SetExtensionHandler() with direct access to the form properties. I also was unable to set the preview form's left and top placement via the handler so setting the form properties to zero solved the issue of screen container placement.

    This is what worked for me for a simple singe page report:


    *-- Doesn't seem to work in config.fpw, so I placed into main.prg
    COMMAND = _SCREEN.BackColor = RGB(0,0,0)
    COMMAND = _SCREEN.WindowState = 2
    COMMAND = _SCREEN.Caption = ''
    COMMAND = _SCREEN.ControlBox = .F.
    COMMAND = _SCREEN.MaxButton = .F.
    COMMAND = _SCREEN.MinButton = .F.
    COMMAND = _SCREEN.TitleBar = 0


    *-- In main.prg
    _SCREEN.BackColor = RGB(0,0,0)
    _SCREEN.WindowState = 2
    _SCREEN.Caption = ''
    _SCREEN.ControlBox = .F.
    _SCREEN.MaxButton = .F.
    _SCREEN.MinButton = .F.
    _SCREEN.TitleBar = 0
    _SCREEN.Visible = .F.


    LOCAL lcPath
    lcPath = ADDBS(SET('DIRECTORY'))

    SET PATH TO lcPath + 'Classes,' + lcPath + 'Data,' + lcPath + 'Docs,' + ;
     lcPath + 'Forms,' + lcPath + 'Menus,' + lcPath + 'Prgs'


    *** Ultimately used source code to compile into run-time executable
    * _REPORTPREVIEW = lcPath + 'Apps\ReportPreview.App'
    * _REPORTOUTPUT = lcPath + 'Apps\ReportOutput.App'
    * _REPORTBUILDER = lcPath + 'Apps\ReportBuilder.App'

    _REPORTPREVIEW = 'frxpreview.fxp'
    _REPORTOUTPUT = 'frxoutput.fxp'


    * SET CLASSLIB TO (lcPath + 'Apps\listener') IN ReportPreview.App ADDITIVE

    LOCAL lnWidth, lnHeight, loPreview
    loPreview = NULL
    _SCREEN.Visible = .T.

    *-- To maximize the preview window
    lnWidth = INT(_SCREEN.width * 0.95)
    lnHeight = INT(_SCREEN.height * 0.90)


    *** Not sure about the accuracy of the following as I ended-up not needing

    *-- the two lines in this block of code [(_REPORTOUTPUT].

    *-- See VFP9 SP2 Help: "How to: Specify an Alternate Report Output Registry Table"

    *-- How to: Specify and Distribute Report Output Application Components

    *-- How to: Register Custom ReportListeners and Custom OutputTypes in the Report Output Registry Table

    *** Need to pre-load the 'eUnload' 3rd parameter to initialize _REPORTOUTPUT
    *-- to avoid run-time error for missing embedded 'listener.vcx' class library
    *-- DO WITH nListenerType [,eListenerReference [,eUnload]]




    WITH loPreview
     .Top = 0
     .Left = 0
     .Width = lnWidth
     .Height = lnHeight
     .Caption = ''
    * .AllowPrintFromPreview = .T.
    * .ToolbarIsVisible = .F.


    *-- Extension handler
    xh = NEWOBJECT('custPrev', 'Prgs\rptexthndlr.fxp')

    loListener.PreviewContainer = loPreview
    lolistener.ListenerType = 1

    REPORT FORM Reports\agent NEXT 1 OBJECT loListener

    _SCREEN.Visible = .F.

    * Extension Handler Class:
    DEFINE CLASS custPrev AS Custom

     PROCEDURE Show(iStyle)
    *  This.Top = 0
    *  This.Left = 0
      This.PreviewForm.frxFilename = ''
      This.PreviewForm.Caption = ''
      This.PreviewForm.FormCaption = ''
    *  This.PreviewForm.Icon = ''

     PROCEDURE Paint()

     PROCEDURE Release()
      RETURN .T.



    Saturday, December 22, 2007 12:58 AM
  • I've changed both: SET ENGINEBEHAVIOR 80, and moving THIS.setFRXDataSessionEnvironment()

    and completely recompiled the exe.


    It is still the same problem.

    Am I missing a step?


    Monday, February 11, 2008 11:34 PM
  •  Dabble wrote:

    I've changed both: SET ENGINEBEHAVIOR 80, and moving THIS.setFRXDataSessionEnvironment()

    and completely recompiled the exe.


    It is still the same problem.

    Am I missing a step?




    You might be.  It worked fine for me.  Are you sure you moved it to the right place?  Here is my LoadReport method code:


    * always start with full reset for this run:



    THIS.commandClausesFile = THIS.CommandClauses.File

    * see notes in BeforeReport






    RETURN DODEFAULT() && these changes can be passed on to successors



    The _reportlistner class is included in my project under 'classes' so when I do a rebuild, this class gets recompiled.  Could that be your issue?

    Monday, February 11, 2008 11:40 PM

    Bill Price, your solution is very thorough but seems very complex.  Are we talking about the same problem?  I read the bug item at Microsoft that you referenced and this seems to be a different problem from the one this thread is addressing.  Correct me if I'm wrong.  Thanks.
    Monday, February 11, 2008 11:45 PM
  • It does work!

    But initially I changed SET ENGINEBEHAVIOR 80 from SET ENGINEBEHAVIOR 90

    What I needed was SET REPORTBEHAVIOR 80.

    So I set SET ENGINEBEHAVIOR 90, SET REPORTBEHAVIOR 80, changed the THIS.setFRXDataSessionEnvironment()  to be before the THIS.createHelperObjects() and now it is working fine.


    Is this because I'm not really using anymore?


    I sure hope that we can use SET REPORTBEHAVIOR 90 in the future.

    Tuesday, February 12, 2008 4:49 PM

    I find that if I set SET REPORTBEHAVIOR 90, the bug returns even with the fixes to the report listener class.  My solution was to create an empty form of size 0,0 and placed at LEFT = -3000000.  The I show that form while the report runs, then restore the original form when done.  This sends the report junk output to the form the user can't see.  Works like a charm.


    But c'mon Microsoft.  How about a SP3 for all these bugs that were introduced in SP2?

    Sunday, February 24, 2008 4:46 AM
  • I found that setting CONSOLE OFF just befor the REPORT FORM fixes the problem.

    Friday, February 29, 2008 9:46 PM
  •  RicU wrote:

    I found that setting CONSOLE OFF just befor the REPORT FORM fixes the problem.


    I tried this, and can confirm that it worked for me too, and it's a simple solution.  So basically something like this:


    lOldConsoleSetting = SET("CONSOLE")


    REPORT FORM  ....

    SET CONSOLE &lOldConsoleSetting


    Sunday, March 09, 2008 11:46 PM