Reporting

[mainhatten]

So, I did some looking around for these "Sources"... There is XSource.zip in the Visual FoxPro ToolsXSource directory.

Ooops - should I be more explicit in defining location ? Had surmized you being around here for some time plus an "old fox" this was common knowledge... If no need for speed on your side just ask if I am not clear enough
.

Next I discovered that Doug Hennig has put the VFP Reporting source code from XSource in a GitHub repo, and it has had many updates and revisions since the production release. So, anyone working with this should start from Dougs repo, not the one that shipped with VFP.
Here is the repo: https://github.com/VFPX/ReportingApps

Yes, by all means get the version of vfpX - I referred to vfp install first as licensing terms are best read there, before embarking on that route with enhanced code - remember the hoopla with Whil and installing runtimes in Linux?

Probably the most mysterious part of this is the _GDIPlus.vcx library that is part of the VFP installation.
The VFP Help file says this about _GDIPlux.vcx:
.

The GDI Plus API Wrapper Foundation class library, _GDIPlus.vcx, contains a collection of classes that wrap GDI+ Flat API functionality for use in Visual FoxPro. You can use these classes to add GDI+ features to forms and reports.

So, maybe _GDIPlus.cvx is just wrapper code around Windows "stuff" and maybe once the code is finally down that GDI+ level, it can still run from X#, but I am not sure about that.

AFAIR it is a Windows dll, seems there is at least a libgdiplus for Mono, but nothing for Android
https://www.mono-project.com/docs/gui/libgdiplus/

[lumberjack]

Matt,

why not recompile the "stock" report handling added in vfp 9. ? Sources to ReportOutput and Reportviewer (as well as ReportBuilder) are included in vfp.

So, maybe _GDIPlus.cvx is just wrapper code around Windows "stuff" and maybe once the code is finally down that GDI+ level, it can still run from X#, but I am not sure about that.

We can probably drop the GDI stuff, .NET got the System.Drawing.Graphics and System.Drawing.Printing.PrintDocument classes.

I for one already have a Printing class wrapped around this in .NET. What is missing on my side is the GUI Designer, since I use a Data-driven approach. I am sure with what is available in ReportPro, what I have done, and also Phil Hepburn, who did a series called BestPrint, we can relatively quickly bundle these together to support Reporting. Not only in X# but .NET in general.

So in essence, if we can read the VFP Report repo, it can be "interpreted" already by what is available.

[lumberjack]

Here are the core of all of my Report work. It emulates the ReportPro methods:

CaptureReports.JPG (212.49 KiB) Viewed 569 times

CaptureReports0.JPG (194.74 KiB) Viewed 569 times

CaptureReportsItem0.JPG (218.79 KiB) Viewed 569 times

CaptureReportsItem1.JPG (234.18 KiB) Viewed 569 times

[David Martin]

Is there somewhere that tells us about ReportPro 2/3?

[lumberjack]

Is there somewhere that tells us about ReportPro 2/3?

I have found this link: ReportPro documentation

[wriedmann]

Hello,

Is there somewhere that tells us about ReportPro 2/3?

ReportPro was produced by the software company DataPro as Reportwriter for Visual Objects and written in Visual Objects itself. The version 2 used the VO GUI classes for the designer and the preview and is AFAIK the most used reporting tool in the Visual Objects world.
Then DataPro released their own string typed version of GUI classes that could replace the VO GUI classes and based their Report Writer on it: ReportPro 3 exposed an ActiveX for the designer and the preview and DataPro planned to expand their market beyond the Visual Objects market.
Now, the X# development team has taken over the support for this reporting tool (Robert knows the sources very well), and so they have a working report writer that can be adapted to changing needs without the need to rewrite one.
Wolfgang

[David Martin]

Thanks for the information guys.

[DexterZ]

ATM here's my work around to run FoxyPreviewer "inside" winform.

1. Install VFP9 runtime only.
2. Still the report designing of FRX needs to be done in VFP T_T.
3. Call or host the reporting inside Winform app using Process.

It looks seamless and integrated inside Winform application ^_^y

[RGreim4XS]

Hello, in the past I have produced „ a lot of paper“. But after a while I solved it different : maybe doesn’t work for everbody as it is not a one fits for all solution...

1. Offer data which can be handled in other apps ( maybe office with ms query )
2. Export the data as Json, xml, or... and let another app do it.
3. If you need „live reporting „ : everybody has a browser, so produce html code which is then be handled static , dynamic with a appserver and a Webserver.
4. If you need labels ( I have a non profit app for sport ), use the sdk of the label printer - Im using brother for almost 10 years now... -
5. I made a prototype based on elastic stack , where Kibana is the report engine. Input is json generated by a vfp app, uploaded by logstash into a. Lucerne db.
6. As I have also Xojo,,, but stuck with vfp, I got in a bundle Valtentina, which is more than reporting ... : I know there a re much more options on the market, some are free, for some you have to pay..
7. Is a report really needed : I alway try to push my date into complete workflows... But ... my usecase is build and releamanagemt in large projects, to fill the gap between daily business with workflow automation and enterprise tools..
8. Do you really need static reports ? Maybe u can offer apps, changes in workflows ....

Just some ideas, hope they are useful.

BR Rainer