Is RR too easy? Or too hard? (was) Is RunRev marketed to

Jim Ault JimAultWins at yahoo.com
Mon Jun 2 12:13:39 EDT 2008


On 5/31/08 12:31 AM, "Peter Alcibiades" <palcibiades-first at yahoo.co.uk>
wrote:

> You have lets say a tab separated file with data in it.  This seems to be
> the approved way of storing a few thousand or tens of thousands of records
> of data, and indeed it does work fine for storage.  Now you want to produce
> reports out of it.  The recommended way (which I've done) seems to be one
> field per item of information, lay out the card so that it looks halfway
> decent, and then print card.
> 
> However any report is quite capable of having 50 -100 cells, more, in it.
> Now, it may be that there is an easier way, which if so it would be great to
> hear about, but addressing all those cells individually in a script so you
> go through the file and extract and calculate what is wanted is immensely
> tedious, inflexible, lengthy and error prone. Also, your reports may well be
> multiple pages, in which case layout again becomes problematic.  The card
> metaphor does fine when you are dealing with screen fulls of info, but when
> you're dealing with page fulls, less so.  Maybe there is a good way to lay
> out a field with totals and subtotals and percentages in it, and that does
> not involve addressing all the cells individually?  Even then however, in
> Linux, I would have to re-export it to a text file at the moment in order to
> format it properly for printing it.  (Yes, a bug has been filed on this.)

I don't do this kind of reporting, but used to in FileMaker many years ago.
Of course, Filemaker was layout-driven so the tools were there.

In Rev, I would use custom properties to store incoming data, formatting
definitions, and calculated results.  Loops could be made to scan the data,
sort, tabulate, cross tabulate, and summarize.  The final step would be to
print one or more pages using a single card.

This means populate fields for page one, print, then page two, etc.  This
also allows the use of headers and footers that track the page numbers.

I would think that you could have different card layouts to optimize the
choice of fonts, margins, orientation, page size.

Some advantages to using custom properties are speed, unlimited 'cells' for
storage, naming of properties, duplicating data instantly, saving the stack
would also save the custom properties (and calculated values if created),
and sub stacks could be used to help build summaries and tabulations.

Others on the list have much more experience at this than I.

Hope this helps.

Jim Ault
Las Vegas





More information about the use-livecode mailing list