Counter in report (revisited).

[HunterEC]

Guys:

How can I display / print a counter in a report column ? Thank you.


FWH 10.6

[nageswaragunupudi]

Have you tried using oRep:nCounter ?

[HunterEC]

Rao:

Thank you for your response. I have not, but what I'm looking is a column that counts each detail line printed. For example:

Header 1 Header 2
---------- -----------
1 Data line 1
2 Data line 2
3 Data line 3
. .
. .
n Data line n
--------
total


Thank you.

[nageswaragunupudi]

Thats what I meant.

Try

Code: Select all  Expand view

COLUMN oRep:nCounter TITLE "Counter" PICTURE "9999"

[HunterEC]

Rao:

It worked, but if I use the TOTAL clause the page and report totals are wrong. On page totals it add the oRep:nCounter data as a total. I'm trying a simple counter where each line counts as one. Thank you for your help.

[Marcelo Via Giglio]

Hello,

then try using bstratLine, bStratREcord, bSkip


nLine := 0
REPORT oReport

COLUMN nLine.....


oReport:bSkip := {|| nLine++ , ...... dbf->( DBSKIP() )}

or

oReport:bStartLine := {|| nLine++ }

or

oReportbStarRecord := {|| nLine++ }

I think some of them will work, try and comment us

regards

Marcelo

[nageswaragunupudi]

oReport:bSkip := {|| nLine++ , ...... dbf->( DBSKIP() )}

This has the same effect of using oRep:nCounter. In the Method Skip(), oRep:nCounter is incremented with every evaluation of oRep:bSkip. By having nLine++ in the skip block we are duplicating the work already done by report object. This is in no way different in functionality.

but if I use the TOTAL clause the page and report totals are wrong. On page totals it add the oRep:nCounter data as a total.

If that is happening, it must be due to some other programming logic, but nothing to do with my suggestion.

Here is a sample using totals and works perfectly. I have used \fwh\samples\customer.dbf for test. You may complile, run and check the results.

Code: Select all  Expand view

#include 'fivewin.ch'
#include 'report.ch'

REQUEST DBFCDX

function Main()

   local cAlias, oWnd

   if ( cAlias := OpenData() ) != nil
      DEFINE WINDOW oWnd
      ACTIVATE WINDOW oWnd HIDDEN ;
         ON INIT ( ( cAlias )->( Report() ), oWnd:End() )
   endif

   ( cAlias )->( DbCloseArea() )

return nil

function Report()

   local oRep, oFont
   local cAlias   := Alias()

   DEFINE FONT oFont NAME 'TAHOMA' SIZE 0,-9

   REPORT oRep FONT oFont PREVIEW

      COLUMN TITLE "LineNo" DATA oRep:nCounter + 1 ;
         PICTURE "9999" TOTAL FOR .f.
      COLUMN TITLE "UNIT" DATA 1 PICTURE "999" TOTAL
      COLUMN TITLE "First" DATA ( cAlias )->FIRST SIZE 20
      COLUMN TITLE "State" DATA ( cAlias )->STATE SIZE 5
      COLUMN TITLE "Age" DATA ( cAlias )->AGE ;
         PICTURE "9999" RIGHT
      COLUMN TITLE "Salary" DATA ( cAlias )->SALARY ;
         PICTURE "99,999,999.99" RIGHT  TOTAL

   ENDREPORT

   ACTIVATE REPORT oRep ;
      ON ENDPAGE ( oRep:aColumns[ 1 ]:nTotal := oRep:nCounter )


RELEASE FONT oFont

return nil

static function OpenData()

   local cAlias, lOpen := .f.

   cAlias := cGetNewAlias( "CUST" )
   USE C:\FWH\samples\customer.dbf ;
      NEW ALIAS (cAlias) SHARED VIA 'DBFCDX'

   lOpen := Select( cAlias ) > 0

return If( lOpen, cAlias, '' )
 

[HunterEC]

Rao:

Now it worked perfectly. The missing part was that of ON ENDPAGE ....

Thank you very much.


Gustavo

[HunterEC]

Rao:

When I filter the report the counter column fails. The filter is:

Code: Select all  Expand view

  oRep:bFor := {|| ( cAlias )->SALARY >= 100000}
 

The Line NO column beings with the number 2 and skips those that does not match the filter. Thank you.

[James Bott]

You could just set the filter on the database instead.

Regards,
James

[HunterEC]

James:

Do you mean by way of SET FILTER TO ? If so, I don't like it because it is too slow. Any other suggestions ? Thank you.

[Enrico Maria Giordano]

There are better options than filters: scopes and conditional indexes.

EMG

[James Bott]

Hunter,

Using SET FILTER TO isn't any slower than using oRpt:bFor. They are both filtering the database. But, as Enrico suggested, scopes and conditional indexes are much faster. If you don't know what they are or how to use them just ask.

Regards,
James

[nageswaragunupudi]

James:

Do you mean by way of SET FILTER TO ? If so, I don't like it because it is too slow. Any other suggestions ? Thank you.

Filters being slow was a story more than a decade old. Except with DBFNTX, all RDDs like DBFCDX highly optimize filters with bitmap filter technology.

In any case using FOR clause in report is as slow or slower than the old non-optimized filters you are talking about.

Filters and scopes are quite fast enough if we use the index expressions and filter expressions judiciously with proper knowledge of how filters are optimized by the RDDs.

[HunterEC]

Thank you James, Enrico & Rao.

What I'm trying to implement is a report where the end user fills up a dialog with a lot of fields and then I create the filters. Basically, the end user can filter by any field in the database . So my questions are:
1. In case I have to count records in a report that is working with the bFor data, how can I do it ?
2. hen I have to build filters at runtime, what's the best way to do it ?

Thank you guys,


Gustavo