Report Sculptor Website www.report-sculptor.com

RS Preview Print is main UI/presentation layer for Report Sculptor reporting. It is ordinary VFP9 form (Powered By GdiPlusX!)
which you will be able to further customize and tune to your requirements/app style . This functionality will further evolve together with the rest of Report Sculptor. Here is how does it lok at the moment;

Features already implemented or planned for implementation, are those of all modern document viewing programs. Next to content navigation tree, It will feature text search, zooming, drilldowns and meny other usefull things. Being modeless form alows for multiple reports being previewed simultaneosely or even multiple instances of the same report. (as on picture above) 

Report Sculptor Reporting can go trough VFP9 Native Preview/Print

Next to ReportSculptor preview which is sort to speak still 'baby', RS engine can also 'feed' VFP9 native report preview.
So You basically get chance to use RS script (and/or all other RS Stuff) and all this directly goes to VFP9 Preview/Print.
Meaning that you can in fact write all those cool 'report-impossibles' with various page layouts, rotations, page decorations, dynamic formating, keeping group content together and so for, without writing/implementing single listener.   
No FRX from your side is needed for this eighter. RS will use predefined ones, which are by default cleaned up from problematic printer info.  

All advanced design techiniques described here , can be therefore seamlessly integrated into your standard VFP9 reporting, without changing anything on the surface that your user is acustomed with. (If that is VFP9 preview of course)
On picture below you will see previous script report sent directly to VFP9 preview;

What you saw above *can* be normally achieved via FRX / Decoration Listeners applying custom Gdi+ drawings on report surface
(or SP2/Sedna but ...)   This *IS* in fact custom GdiPlusX drawing on VFP9 report surface,  but it has been done using
very simple straight forward RS script. FYI Script does all this quiet easy! Rotation for instance,  is just another parameter passed to RS engine which being built on top of Gdi+(x) natively supports it for most of drawing commands. When you do report with script, then not only formatting and coloring; but everything else is *dynamic*. Aldough scripting is tedious process by nature; some of you just might prefer it this way for some specific reports.
You get 100% control over report creation, and that means dynamic formating, coloring, kepping content together and meny other things. 

Script Is Power

RS report scripting revolves arround very simple idea;  It is decades old 'print-as-you-go' concept.
We start each page by being positioned in topleft corner of page. Then we write that line to the right unitil is filled up.
Then we advance one or more rows down and continue writing next line. After page is all written up, we simply flip another one,
and carry on writing until report is all done. This simple principle is all you have to grasp to fully understand RS report scripting!  
As you will later see, it will be  respected all the way up to and troughout Visual OOP Reporting.
Weather you are doing WYSIWIG page composition or Visual OOP report (or both!), You will Never loose control  over execution and content writing. When we place objects on some form or classlib and then ask RS to render them all, it will be done in TopToBottom/LeftToRight order. So you can insert script writings very precisely between visual content or just carry on writing from where ever some
previous object finished.        

Back to Print-As-You-Go report scripting / Reporting primitives;
What used to drive that rusty DMP printer back in DOS/xbase 'stone age' - were procedural reports written
with ? / ??  / ...SAY / Eject  commands.  (Menu of You remember this I am sure...)

Here they simply became  .lf() / .lw() / .DrawString() / .Eject()  script calls respectively.   
So, don't worry, meny of you already know how to put all this in action, and produce fully blown reports I am sure!
You did it already meny times before!  I even wanted to name methods the same way, but making method name like '??'
is as you know impossible. I believe people who have huge legacy of such procedural reports will find their way to use
this matching methods to their benefit. Some of those old procedural reports are almost impossible to rewrite
with RD/FRX, so being simillar in nature, RS script might offer possibility for some sort of conversion
and/or  even 'extreme makeover' with new design elements.

I call it somewhat incorrectly 'scripting' whereas these are in fact class object method calls, but after you create RS object
and enclose it into with/endwith pair, everything in between should be prety much familliar to you. (See below) 

But it is not like you are going back to 'stone age' ;  There is already, and will be much more more power (higher level scripting elements)  and flexibility added to it. On top of it, scripting can be combined with visually composed parts (Page&Group Headers/Footers etc) , frx reports and other content sources. 

Have look at snapshot picture below (watch comments!), It is of a script that produced above shown report. 
You would be amased how easy some reports can be written in pure (script) code.



Why bother with scripting/coding when things can be done visually ?  Why do we need all this ?
Answer is simple;  We all crave for more control over code execution, and nothing can be more precise in writing
that report then our own 'hand' (script).  Back in DOS days, even when RD/FRX already stepped into our lives, meny of us still had
to code our reports, simply becase meny of our reports still required that *control* which we had to give away in return for 'free lunch' (RD/FRX).  

I never understood (or came in terms with!) - Why comfourt of visual codeless creation and full control over content writing had to be mutually exclusive! I hope Report Sculptor will manage to prove, that this not necessarily have to be the case! This is more or less main
reason why I gave lot of attention to report scripting. Most of the time we don't want or need 100% of control (code by hand), but if situation ever requires then we can have it !   

There are other reasons and situations where script comes handy;
Not all stuff we need to report is always kept in VFP tables, nor we always need structured grouped data report. How about reporting from arrays ? Reporting from Form properties, Database properties, Project structures ?  Small reports;  It will be some times simpler to write 15-20 lines of script,  simply grabbing some figures off your running form and doing few odd pages printout, then prepare temporary cursor, build FRX etc. Eventually, you will build your own provisions which will make those small script reports even more simple.  Simple record listing for instance, can relatively easy become one-line function call and this way significantly reduce number of FRX-es shipped along with your application.   
 
Or how about various combinations with excel OLE automations?  Report extraction can feed excel directly, while excel can
feed back report etc. Script should play very well in COM/WEB implementations right ?  You can have it silently produce PDF or some
other format and simply return results back.

I don't know what else, This was off the top of my head, but I am sure You will figure out how to take advantage of all this  :)  

Below shown is one example of mixed column layouts that were easily done via script, No alias was used; just various expressions
and arrays ; 

Within the same report, pages that folow this one have various running layouts mixed. Field structures, indexes,
database and table properties etc. BTW, What you just saw above, might become your Databases/Tables Documenting
tool tumorow.

 
Interpreting Other File Formats 

As mentioned at the beginning of this page, Report Sculptor can use more then just pure VFP stuff to produce
reports. One of most common request in our VFP, pro-business reporting is to incorporating boiler plate content into our reports.
I mentioned earlier that example of invoice followed by Sales contract.  Up to now I experimented with two file formats which are common in our lifes. One is plain text file and second is Excel.

1. Excel
In order to support excel, I used my own excel wrapper library published originally
in rep2excel and CodeRep downloads. Using automation object attached to Sculptor I managed to reproduce excel content with text formating limited to whole cells (one cell - single font) . Even with that limited replication I was able to pretty accurately reproduce legal documents on my reports.  I would simply copy whole thing from word into excel, and then rearrange chapters/sentences little bit so I fit each different font in different cell and voila, they appeared on my report looking pretty much the same as in original version. 
This, now simple excel replicationwill be improved in the future to parts of excel sheets much much better.
You can use precise sections (ranges) of excel sheet to show on your report, and you can also read/write from/to excel while doing it,
hence all things you can do with this.

2. Text Files (RS Smart Text with Simple Html Tags & Scripting)

Plain Text files are something we all used. VFP is very good at reading and creating them. However including them into our reports
was not all that easy in the past. With FRX you could present them by reading them into variable, but that was
limited to current band you placed them with possibly some some streach/overflow. Not much else we could do with them.

There is good news here ; With report Sculptor they become totally acceptable report content source. 
Then can span to unlimited number of report pages, and they can be combined and enriched with scripting.  
Report Sculptor will read file and then interprete it to report line by line. Prior executing simple HTML like text formatting tags (<b><b/>,<i></i> etc)  it performs TextMerge() so we can easily merge our variables and table fields into it.
Report Sculptor text processing skills are not really high at this point, but that will hopfully change/improve in the future.

Next to Boiler Plate text, You can place whole blocks of script within plain text file (even entire little subreports!) and they will get executed as they come along, among ordinary text lines. I used it up to now mostly to assign font characteristics to sections of plain text file, but perhaps there will be more cases where this plain text+script processing can be used for reporting purpose.

Have look at this example of report produced by combining one FRX and predefined Text file (template). 




Those of You who are experienced with RD/FRX will understand that what was shown on picture above is almost impossible
to do with FRX alone. Now let see how 'hard' was to achieve this result;

 
  


* * *

Future plans in this respect are to build  as meny of these interpreters as possible  alowing people to reuse content created elsewhere
simply calling file by name/path.  Here I primarily think of Office file formats available via OLE automations  

FRX Interpreter  

You heard meny times in this document about Report Sculptor, 'interpreting', 'importing', 'converting' FRX based reports.
FRX being an 'assembly' etc.   So what is actually going on here ??  Well, all of above! 
As we have seen in previous example, Report Sculptor can run any ordinary FRX report (no labels!) and withold pages generated for further use.  When you run FRX report trough ReportSculptor engine (via RS ImportListener) all FRX report pages are simply stored inside RS engine session - alone or together with the rest of RS content. 

Point here is, that by sustaining pages in the memory cursors, we can further combine them with other report content sources. What is 'other report content' ?  That could be anything you wish! It could be simply another FRX, or range of excel file, or more scripting, or some form controls replicated into report content etc.  That is why I consider FRX  to be 'one of meny'  report content sources.
The more the merrier :)

Since RS support more then just preview/print as output types (RS natively exports to pdf,tif & xff) , this directly means that you can use Report Sculptor (to a limited extent) as Report Converter as well. But don't hold me accountable for this. Aldough RS will convert just fine majority of our ordinary reports, that is NOT purpose of Report Sculptor. Idea of building frx interpreter, was not to convert your hyper complex old FRX reports with 100% accuracy into some other format, but to actually built new reports contents.
Sculptor is Free Report Design Concept. Therefore FRX interpreter was built with sole purpose to *fit* your FRX into that greater reporting design/picture. 


Accessing and Manipulating Pages in Memory
 
Anything You do with RS , weather it is processing your existing frx, or writing script creates report pages stored in memory.
While with RD/FRX execution this is normally 'no go land' (metafiles), here you are free to do whatever you want with pages,
for as long as you don't close and release RS session yourself.  You can search, add, remove content etc.  

If  you need just simple decorating of some existing report, you can do that very easy and without doing any changes to actual FRX report. You simply process ordinary FRX report trough ReportSculptor engine, and then apply  'decorations' afterwards,  manipulating directly pages in memory via script. Watermarking pages,  hiding sensitive content comes to mind but perhaps it will be meny good uses for this added
flexibility.  

What is shown below is report composition from  3 different FRX reports with some free pages added inbetween them and some 'decorating' applied afterwards by directly manipulating pages in the memory via RS Script;
 

 As  I said before, RS scripting can greatly complement FRX based reporting. That was one of main ideas.  

Output Distribution

As mentione earlier Report Sculptor is very flexible when it comes to outputs. Below here is shown just fine selection of
report distribution facilities.  But there is more to come eventually.

 

Any report composition you do, can be sent as per your (or your user) wish to standard VFP9 Preview/Print or ReportSculptor modeless Preview/Print facility. Those aspects were presented earlier. When it come to exports to file formats folowing formats are supported

1. PDF 
2. TIF  
3. XFF  

1.  PDF 
Free and extremely fast (!) PDF option, is provided by genuine effort of Dorin Vasilescu, wrapping OpenSource Haru PDF library written by Takeshi Kanno. I just wrote simple RS extension which uses that wrapper and 'voila', now you can export anything you do straight to PDF. What makes it extremely attractive is very high speed.  PDF export shown on picture below is 777 pages(!) of VFP9 sample report which atfter being imported into RS and shown in RS Preview,  got exported to PDF in staggering 6.7 seconds!  
Speed of HaruPDF library is just Amasing!

I hope you will appreciate Dorin's hard work on his HaruPdf wrapper so He can allocate more time improving his classlib. If this project move forward, then I will be able to build more sophisticated RS extension to it.    

{easypaypal button=http://www.paypal.com/en_US/i/btn/btn_donate_LG.gif,address=dorin_vas@yahoo.com,itemname=Free HPDF ClassLib For VFP9,amount=0,Amount=1}

By helping Dorin improve this library, not only ReportSculptor can achieve better exporting results, but we can ALL benefit having extremely fast PDF support in VFP9. Also don't forget Haru DLL Original Author Takeshi Kanno  

2.  TIF  
Multipage TIF option is also free. Can be also previewed via MS Office Document Viewer or any other default app.
It is usefull output extension, done as demonstration of flexibility and extensibility of RS, and of course power of  GdiPlusX! 

3. XFF
Xff is native format of popular XFRX Report Converter product. It can be directly translated to meny other file formats.
Check  www.eqeus.com , for full list of supported file formats.  To send your RS reporting directly there, all you have to do is fill up one property with full XFRX path, and you are automatically 'connected'.

To clarify; Report Sculptor does not include ANY part of XFRX product, so this option will work only if You already own, or purchase
full XFRX licence. I highly recommend that, being myself long term user of XFRX product.    

After getting XFF intermediate format as result of RS report, you can very simply delegate conversion into all other formats to XFRX, which does them very well. Moreover, there will be entire line of simple function calls doing it very easy for you.

* * *

So here we come to second part of Report Sculptor foundation download which ventures into completely 'new world' 
when it comes to VFP reporting;

Report Sculptor WYSIWIG Design & OOP Reporting 

Introducing true OOP Reporting.
Form is something everybody used. With Visual Sculptor components any form can very easily become part of, or your entire OOP report.
Next to it's own specialised class objects, VisualSculptor will be able render more less any visual control off your forms directly into your RS report! Not snapshot of control (except for ActiveX) but actualy meaningfull report representation of it. Form controls being equiped for
building our forms are quiet capable of acting as report controls as well! They can be bound to our data, Textboxes are having format and inputmask properties,  controls also have precise coordinates, height, width, back/fore color border etc. So now that there is posibility to replicate them directly into our report, we will build more on top of this new possibility, and see how far it will get us :)

Below shown is snapshot of form whose controls are directly transported to report surface;    These controls do not come from RS libraries and do not have any reporting powers themselves. They are simple, VFP base controls. So any controll off your forms will be just as good for reporting purposes !

What was shown on the picture above might not look exactly as some serious reporting possibility. Looks more like a mess of form objects replicated from form to report page. But here comes the twist! If You remember, RS does scripting as well!
Let see now how we can combine these two. 

This time, instead of taking all objects from the form in their natural order and positioning, I am going to use specific ones (containers) and combine them with script in order to produce simple record listing report. So, let's go little bit behind the scenes; (See picture carefully)




So what have I done here ;
As you can see on picture of click method, I instantiated RS engine object,  then told engine to use particular two containers on form as Page Header and Footer bands respectively. Then I used simple Scan/Endscan loop to show all records by simply pointing to another;
this time detail container!  Containers had textboxes directly bound to my alias and voila - here comes our very first OOP report !
See below !

 

Since Form is object itself, and everything on a form is an object then what ever reporting you do this way, can become eventually
your own OOP reporting setup. Think of what you saw above as a sort of 'kit' for creating your own reporting stuff. Those containers
served in this case as actual report bands to our totally free report composition! 
You can for instance, visually design Page/Group Headers/Footers on your form, then have script write dataflow, then use some ActiveX to show graph  or ListBox to expose some arrays etc. All you will use will be real objects, so it is all OOP!  You will then decide to store those Header/Footer container objects into your class librarries and voila; You are almost knee deep into world of OOP reporting!

 WYSIWYG Page Design  

I would dare to say that this particular possibility was painfully missing from our VFP reporting in the past. Now since we gained
possibility to replicate our form controls on report surface,  next step towards fully OOP and constraint free reporting
is naturally WYSIWYG page design.     

Very simple way to put all this into action is via ordinary Container object and even better PageFrame. 
On top of it it does not requires any special skill from your side! No special classlibs, controls - nothing!

Once You set procedure to ReportSculptor.App all this becames almost like native VFP capability.   

So we will add very ordinary PageFrame to our very ordinary form, design content visually using our good old Form Designer 
See picture below ;

After Visually designing our ordinary page frame we will simply issue single line function call from any form method
(someButton.Click)  passing directly PageFrame reference and Output Type ;   

=ReportPageFrame( thisform.Pageframe1 , 2 )   

Then we run that form, click that button and Voila!  We will get folowing result in our VFP9 Preview/Print form ;

We got our first totally freely (and visually) composed report. It included WYSIWIG designed page, and used two aliases  as dataflows.
We could use as meny aliases as we need. However, none of them  turned up to be  that famous 'driving alias' that we always had to 'dance arround'. By adding few grids into the mix, we made them all do their job by looping trough their records so we can expose them out. Nothing more, nothing less. Unlike with FRX tightly predefined order and set of events , using dataflow to produce report content did not impose any constraints in this case.

Using more then one running alias has nothing to do with 'Multiple bands'. Design philosophy here is totally different from FRX. These aliases (grids) are simply *placed*  here as we need them. We are no longer on the (single) run trough data and folowing prefixed order of events (bands) as with FRX. We are simply placing content as we need it. We have full freedom to design our report visually using both static and dataflow elements. And We still have full control over what is going on.


Totally Free Report Composition using PageFrames  

It is important to understand design concept of combining WYSIWIG static pages (or page parts) and 'running ' or 'dataflow' design elements via Form and PageFrame. It is one of major design concepts with Report Sculptor, which will be greatly expanded in the future . As you will see that old, 'rusty' VFP PageFrame is quiet capable of serving as very flexible multipart design surface. It is an easy and intuitive way of using and integrating all Report Sculptor functionalities.

You can easily understand it, if you picture again that old print-as-you-go idea from scripting, but this time instead of thinking in
line by line and page by page mode, you think in visual terms;  Frame By Frame (Or Report part by Report part ) and vertically.

So report parts are easily put together (and later executed) frame by frame, going top to bottom. Each page of pageframe will produce one or more reporting pages depend on design elements used and they will be all appended to ongoing report. 
It is quiet simple and intuitive execution logic.   

If we place objects which do not spread beyond their own height/width we get practically WYSIWYG page content. If we place some flowing element such is grid 'exposing' table or cursor, then that particular framepage might  'spill' downwards on variable number of pages, depend on number of records.  
Beware that flowing design elements can overwrite (spill down) over static content below, so simply make sure that static content folowing flowing content always start on top of next page(frame) folowing variable content. Later in elevated OOP setup (with Part 2) we will be able to float groups of objects (containers) to fit precisely behind flowing elements. 

However, Grids are not only variable report parts available here. Via script, we can precisely call-inn and place entire FRX reports, or parts of excel files, or do some scripted report/data flow.  And again, wherever that flow finish , next frame will flip new page and carry on execution.  Where you had to think of chaining multiple FRX reports to put related report contents together, here we are talking about simply placing them next to each other visually and/or via script. 

Note again that everything is always executed in strict Frame by Frame and Top to Bottom order. So By placing objects You directly determine  precise order of execution/rendering. This gives you possibility to reliably place custom script objects inbetween visual objects and this way  interact with with both engine and report objects themself at execution time. To add script you will simply drop RS Custom Script class and write your code in hook method (.RsScript) which receives entire engine object as parameter.  
From in there, you can do more or less whatever you want; Write entire section of report or just interact with objects
comming along.

More less anything Report Sculptor is capable of doing, will be doable both visually and in script. And the combination of the two.
This is that design freedom, power and flexibility Report Sculptor was all about

On picture below is snapshot of report produced; which as you will notice starts with static (wyswig) page, then continues by
including entire FRX report, then uses plain text file (enriched with script), then uses simple grid to present clients table. It laters
continues with scripted part, excel etc.
Obviosely, contents put put together in this demo do not actually make sense, but you will understand that this is only
demostration of power and flexibility of this reporting/datapresentation concept.   

Have look ;





With second download, our reporting powers and diversity of design elements will further increase, while need (but not possibility!) to use script will be further minimised by use of RS class objects.  They will have special reporting capabilities, compatible with Frame based design and will be directly insertable into page frames. (FRX Wrapper Control, Excel ActieX Control etc)
See sneakpeak of PART 2 donload further below.   


* * *

If we don't need complex multipage/report part  design, but rather simple quick record listing, again in simillar manner we can call single function to report (replicate) just any grid;

=ReportGrid( thisform.Grid1 , 2 )   

You will get record listing which completely ressembles your grid. Your user can resize it at run time, and if you sport dynamic
on-the-fly grid creations then they might as well build their own simple record listings. You help them interactively build that grid
by setting order, size and color grooming of columns, while ReportSculptor will transport it all into usefull printout or export to other format.   





Later when You get used to idea of having fully OOP reporting, You will build your own personal 'styling'  by creating various classes
to replicate your controls just as I did with basic ones. All I used was that very same script I mentioned before. 
Just think about simple record listings for instance. You can 'equip' your grid classes to print their own content way You like it,
to fit your recogniseable application style.

And story goes on and on, You will hopefully write some of it yourself :)  

                                                               * * *

As You have seen, from usefull but not so attractive possibility to script our reports by hand, having power to do so, we relatively easy worked our way up to WYSIWYG codeless report design.  
OOP with VFP is trully beautifull thing, It is only up to our imaggination what else we can do with all this new possibilities.

When we consider VFP well known connectivity and strong datahandling capabilities, then add to it these scripting capabilities, OOP reporting with forms and form controls, possibility for classic FRX reports to be combined with let say excel and hopefully meny other content types (few more Office Documents types!) and all that be used as part of some greater reporting task/design, then all this together becomes quiet powerfull reporting and/or data presentation mix.

Not only FRX/RD, but meny other VFP9 functionalities can be utilised directly or indirectly in RS Reporting purposes; 
Intelisense for RS scripting, Newly built modern Form Designers for RS OOP Report Design, OLE Automations as Office Content providers,
GdiPlusX for various Report Decoration effects, VFPX/FoxCharts for Charts, ActiveX, Web content etc. Add to it few smartly selected
commercial reporting add-ons, and we can assert serious power when it comes to reporting with VFP9.   

I hope you will find the way to gainfully use all what I exposed above. And that will be all for our first downoad - RS Reporting Engine Foundation.    


I will appreciate all of your feedback, comments , suggestions being sent to admin.AT.report-sculptor.com 

* * *
 
                                                                                   PART 2 (Sneakpeak)


This of course, is not the end of our OOP reporting journey;  comming next is taking our newly established Visual OOP Reporting
freedom to the Next Level with;  

Fully OOP Grouped Data Reports, OOP Report Design(ers), Advanced Libraries etc;   

Next to your ordinary forms and controls acting as report content source I will (re)build specialised RS form which will be used to design our complex multipart reports very easy.  So as we already saw before with YOUR OWN PageFrames and controls, we will expand further this concept, but this time taking full advantage of VFP's strong OOP capabilities.

As we did before, we will be simply filling up RS page frames with content parts, (with or without little help from our wizzard
friends!)   Every page of RS page frame can be eighter single WYSIWIG created page or some multipage flow.
But this time arround, this will not be 'blind' base form controls, but special RS library objects with special reporting capabilities
and rich subclassing prospects.

To embed your existing FRX, you will simply drop FRX wrapper control, to a Special RS PageFrame, fill in FRX filename and you are done 'chaining'.  Similarly we will drop RS/Excel ActiveX subclass for Boiler Plate content, or RS Option Group for bulleted list, Listbox to show arrays, ActiveX can show Graphs and Charts as screen snapshots etc. 
I will also try to incorporate more accurate rendering of ActiveX controls and RichText, by providing hooks for Moxie Report Objects (Commercial library by Bo Durban) and also full support for using VFPX/FoxCharts  (awesome) project by CesarC.

Once you fill up all frames (report parts) they will get executed in their natural order, and results appended to ongoing Report composition.
To do that, we will again use simple function cal like; 

=ReportRSForm('..\myRsForm.scx', 2 )

What user will see, will be simple progressbar and then depend on output parameter passed, fully blown report will appear as 
RS Preview, VFP Preview, Email Attachment etc.

FYI, There is already working prototype of structured grouped report as container class object which works/behaves very similar
to old reporting engine (prior to VFP9) so I will try to build more on top of it. Not really repeat listeners/additional bands
(we have that already!) but more like expanding set of report controls with whatever can come handy. People already
started building custom report controls with GdiPlusX, so I would optimistically say here - sky is the limit :)

That part of RD/FRX did not change for years, so now that limitations are gone, we can expand it as we are pleased. 
Perhaps some specialised Report Form Builder will come as well on agenda. 

Here below is glimpse of how that future Visual OOP report might look, as part of our future Visual Report Composition; 



In above  case that complex report composition was in fact PDF broshure describing possibilities of this concept, back in previous
(unpublished) version of Report Sculptor which was built on top of XFRX/Xff scripting.  (see PDF document)
Now since everything changed with VFP9/GdiPlusX , this can only get better next time arround...  

This is just to get you puzzled, when it is to be released, Visual Report Sculptor (PART 2) will be presented and documented in much more details.   I expect to release this sometime next year.

                                                                         * * *

And now those 'small prints'

YES, IT IS FREE !!! 

Report Sculptor Framework is Free and Open Project. Not Open source, but in fact Open! 

About Licencing;

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Report Sculptor Foundation is royalty free, for all end-developers and their end-users.
However, If you are Vendor selling tools to other developers, then you will have to obtain special licence/agreement for using ReportSculptor solutions within your commercial product.

* * *

Future of ReportSculptor

With Report Sculptor being an Open project;
Anybody with significant contribution to this project, can become registered RS Author, entitled to fair share of ownership
over this project.

Report Sculptor will be owned, maintained and managed by it's major contributing Authors, and that could be you as well. There is much more ideas then time to explore and implement them all. So I cordially invite VFP experts to join this project.  
I still need lot of help, and there are still meny challenges to be meet! So TIA & Wellcome aboard :)
  
Although there is no 'crew' behind it yet,  there is quiet a bit of work already done here. Project is only relativelly 'new'; I had it  'brewing' for years  trough Rep2Excel and CodeRep free projects, which were direct predecessors to this one, so it is sort of already 3rd, if not 4th generation of my own OOP/crossformat reporting efforts.  I  got some great help from VFP community members by now, so I finally managed to put major peaces of this big puzzle together. Now I am putting it forward, as free foundation to be built uppon. I do believe that this code base can eventually grow into an excellent reporting tool, and will do my best to make it happen. 
Aldough highly unlikely, but If for any reason I am not able to continue these developments, then I will make sure that this code
become available to general VFP public. So fill safe to invest your attention in this concept. 

Community will play important role, by hopefully adopting and using it and then providing some feedback. It will help me a lot in
in this effort to make Report Scuptor become robust and reliable reporting tool for VFP9.
If you create some really cool report with Report Sculptor and you are willing to share it, please drop me PDF version of it, or code that produced it and I will publish it here in Report/Code Gallery. Next to promoting Sculptor as reporting concept, this site is designed also
to become meeting place for people who share real passion for VFP programming in general, and Reporting in particular. 


There will be eventually some advanced class libraries published under low cost subscription schemes, but that will happen only if acceptance and usage of Report Sculptor really grows. If so just happen, and things go well, then I will be more then happy to allocate more time to hopefully expand this project to it's full potentials. When I say full potentials, that is kind of hard to estimate. There is no limits here!
Whole concept is very extensible, open, and it will evolve in the future depend on your interest and acceptance.

I hope VFP community will enjoy constant improvements of reporting possibilities with our favourite tool - FoxPro.
Keep on chasing that Fox and Enjoy using ReportSculptor! :)

Djordjevic Srdjan
RS Founding Author & Self appointed Class Librarian
Limassol, Cyprus
Email: Djordjevic(at)PrimeHome.com