LEDGER PAGE NO. 3

[mohinder singh]

HI
I WANT TO STORE EACH PAGE NO. IN MY ACCOUNTING LEDGER REPORT FOR INDEX PAGE

 

[herbstgy]

CREATE A FIELD ON THE REPORT.
PUT _pageno SYSTEM VARIABLE IN IT.

 

[Tore Bleken]

HI
I WANT TO STORE EACH PAGE NO. IN MY ACCOUNTING LEDGER REPORT
HOW?
HOW TO STORE PAGE NO. WHILE RUNNING REPORT?

Please don't SHOUT in this forum.

 

[GriffMG]

Do you mean that for each item on the ledger report you want to write back the page number it appears on into the original data?

if so, you are looking to run something like this for each detail in the report - in the run on entry property on the detail band

function LedgerPageUpdate
select myLedger
set order to LedgerKey
seek (myTempCursor.LedgerKey)
replace myLedger.ReportPage with _pageno
select myTempCursor
return(.t.)

I haven't tested this, never used the property...

 

[Chriss Miller]

I wonder why you would call printing storing. And if so, the simpler question is how to print a page number. It does not depend on what data you print. As you obviously struggle with the English language you would ask just that.

I wonder even more why you would want a report to store (save) something into data. You got both options as answers. And even though the request to store the current page number into data seems very odd, I bet you need Griffs answer considering what I said above.

I even can imagine a use case for this data, you could print an index page that tells on which pageno a ledger is to be found. But then, if you need to look up data, you best do it on a computer/tablet/phone, not on a printed report. To need an index page suggests the report has a magnitude of 100 pages, maybe even several 100s. Why would you even print out all that data at all?

Just one tip: If you're really that bad in English, you better use a translator like google translate, and to best ensure the meaning comes over, be verbose about it, don't stop at just two questions, especially two questions that are just the same. Always imagine yourself on the other end, would you get it? If you really want to store the page number in data, you will know yourself that this is very unusual and people might not assume you mean that, so that's one thing to mention to make clear you really mean it and it's not just a translation error. I actually looked up whether storing and printing look or sound the same in Hindi, but they don't.

 

[mohinder singh]

Do you mean that for each item on the ledger report you want to write back the page number it appears on into the original data?

if so, you are looking to run something like this for each detail in the report - in the run on entry property on the detail band

function LedgerPageUpdate
select myLedger
set order to LedgerKey
seek (myTempCursor.LedgerKey)
replace myLedger.ReportPage with _pageno
select myTempCursor
return(.t.)

THANKS
I WILL TRY THIS CODE

 

[GTGeek88]

Looks like GriffMG deciphered what you wanted, but more details would have been helpful.

 

[GriffMG]

really

 

[Joe Crescenzi]

This is an odd question. I can't imagine why you would store a page number someplace unless each page has some meaning.

For example, if there are 550 rows to print, and each page holds about 55 rows, you would get 10 pages. So, are you saying you want an index that tells you what page each row is on?

So the first 55 lines will have a column that says each of them are on page one, and the next 55 say page 2, etc.?

If that's the case, you could write a simple user defined function and pass the row number and page number as parameters. Then place that in a box on the report for example LogPageNo(keyfieldname, _PageNo). Then every row could call LogPageNo with the key field for the row, along with the page number it appears on. That function would simply create your index with the key field and page number for later reference.

Like I said, it's an odd request, but it would work.

Of course, if you know ahead of time how many rows fit on each page, you could mathematically determine what page each row will be on without actually running the report.

 

[mohinder singh]

THANKS
I WILL TRY THIS CODE

RESPECTED SIR,
YOUR CODE NOT WORK
PLEASE TELL ME HOW TO STORE (WANT TO REPLACE IN OTHER DATABASE) LEDGER REPORT'S PAGE NO. (FOR CREATING INDEX PAGE)
WHICH COMMAND/FUNCTION I GIVE IN LEDGER.FRX
THANX IN ADVANCE

 

[Tore Bleken]

RESPECTED SIR,
YOUR CODE NOT WORK
PLEASE TELL ME HOW TO STORE (WANT TO REPLACE IN OTHER DATABASE) LEDGER REPORT'S PAGE NO. (FOR CREATING INDEX PAGE)
WHICH COMMAND/FUNCTION I GIVE IN LEDGER.FRX
THANX IN ADVANCE

Again, please don't SHOUT!!! Using UPPER case only is considered SHOUTING!!!

 

[GriffMG]

I can't be more specific with the code, without knowing your data structure etc.

But you trigger the function on entry to each detail line

 

[mohinder singh]

Again, please don't SHOUT!!! Using UPPER case only is considered SHOUTING!!!

what is your problem??
are you angry with your family?
cool down man

 

[mohinder singh]

I can't be more specific with the code, without knowing your data structure etc.

But you trigger the function on entry to each detail line

View attachment 1863

thanks again sir, i will try this
thanks

 

[Joe Crescenzi]

what is your problem??
are you angry with your family?
cool down man

I assume you are not familiar with writing in forums.

Capital letters are generally avoided except for occasional emphases, or in the case of FoxPro, they are often used as FoxPro commands, just like in the official documentation.

The fact that you felt he was angry when he replied is the perfect example of how capital letters often give you the impression of shouting in anger. He used capital letters in his reply to show you how it makes text seem to convey emotion.

 

[Tore Bleken]

thanks again sir, i will try this
thanks

My ears hurts when people shout...

 

[Chriss Miller]

Mohinder Singh,

there are further, simpler ways of getting the call to a function. The simplest is making it the expression to print in one field. And to not change what's printed, the function could take what you want to print as its input parameter and return it. On top of that it can do anything else, like updating a table.

As Griff said his code is just a sketch of what you need, as you don't tell us into whoich table and which field of it you want to store the current page number. But you know this yourself and on top of this you need a ledger identifier and the _pageno variable holding the page number. So it would be well suited for the report field printing the ledger number, if you print that.

In short: Any field of a report can not only be set to just a table field, but as the Field Properties windows General tab displays: "Expression". That's any expression returning what you want to print. What else the expression does, like updating a table or even changing the background colour of the screen or plaing a song, is up to you, you have all the freedom of doing what you want there, as long as you eventually return what get's printed. You don't even need to print anything, as the expression could return an empty string. So report fields are a door to anything you want to do at all, there's no need for anything fancy like the "Run expression on entry" of a report band.

 

[Joe Crescenzi]

In short: Any field of a report can not only be set to just a table field, but as the Field Properties windows General tab displays: "Expression". That's any expression returning what you want to print. What else the expression does, like updating a table or even changing the background colour of the screen or plaing a song, is up to you, you have all the freedom of doing what you want there, as long as you eventually return what get's printed. You don't even need to print anything, as the expression could return an empty string. So report fields are a door to anything you want to do at all, there's no need for anything fancy like the "Run expression on entry" of a report band.

Well said. I will add one warning.

Since you intend to run this when you run the report, just keep in mind that when you run your report, as long as you place the function in the detail area it will run one time per row, which could be a problem if your function is inserting rows into your index rather than updating a row in an existing table because it will insert the row EVERY time the function is called (notice I shouted for emphasis here).

That means if you run the report ONCE under normal circumstances, it may, in fact insert more than one row for certain conditions.

For example, if your report is called with PREVIEW turned on, the first page will be displayed. That means it will trigger the function once for every row on that first page. When you hit print, it will likely trigger your function again for the items on the first page. Another interesting side effect is that when a report has _PAGENO anywhere on the page, if you hit the last page icon to jump to the last page, it will actually run it TWICE for technical reasons. Hitting print will trigger the function yet again on each row giving you as many as 4 triggers per row.

Naturally, this is made worse if you re-run the report, so my suggestion is to avoid INSERTing rows and just update the original table with a page number column or create a new one with exactly one row for each unique row identifier. Then it won't matter if you run it multiple times. The extra calls will only give you a minor loss of speed as it updates the rows.

 

[Chriss Miller]

To avoid too many function calls, organize your report, fields in group headers will obviously only call this function once per group change. Etc. So you control the frequency of calls by using the expression mechanism where it is appropriate.

If you would choose fields that are printed more than once per group and you expect multiple calls for the same ledger... On the one side you could choose another report field for that, on the other side you could program the update/replace only on the condition the pageno field is unpopulated, i.e. 0 or NULL or BLANK(). and so multiple calls don't lead to multiple records or multiple unnecessary updates.

You may also look into SYS(2040) to see whether the report is in preview or printing status.

 

[Joe Crescenzi]

I'm less concerned with the performance issues of whether to detect whether it's in preview or not and how many times it may call the function in any given report run.

Even if you guarantee the function is called only once per row, they still may run the report another day, so what I was trying to empathize is that it should update a row, rather than insert one into a log. It would not only solve for running multiple times per row, but it even lets the user run the report every day without adding more rows to the log.