I am trying to implement a Table of Content.

I am using IGFilterRowEvent (which is raised for each row prior to printing) to add details to my table of content, but at this point I do not know the page number it will be printed on.
The page number is present in IGCustomDrawPageBandEvent but this is raised after IGFilterRowEvent (as you may decide to filter the row).

Can I get the page number of a printed row after it is printed?

Thanks

There is no direct way to retrieve the printed page number from the FilterRow event, but we can consider adding a parameter for this in the future iGrid updates. We will need to see whether it makes sense there because the FilterRow event is used to filter rows so that in the general case it may not be possible to determine the corresponding page number before a row is actually printed.

To implement what you need in the current version of iGrid, you can try to use the PrintPage event of the Document property of the iGPrintManager component. The Document object is an object of a descendant of the standard .NET PrintDocument  class, and it provides all standard events including PrintPage . This event is raised after PrintManager finished printing of a next page, and you can increase your counter of printed pages in it to access this variable in your FilterRow event handler.

An alternative is to harness the existing CustomDrawPageHeader/CustomDrawPageFooter events of PrintManager for the same purpose (but do not draw anything in the event handler).

Thank you for your reply.

I can only use the iGFilterRowEvent to add my TOC entry as this is the only event I can see which is raised when printing a grid row. As it is raised before the row is printed (so you can filter it if you need to) the page has not yet been constructed (no footer for page 1, no header for page 2 etc). So when at the bottom of the first page the row will still have a page counter set to 1 in iGFilterRowEvent as it would not have raised any page events because at this point you do not know if you need another page (i.e. if the row is filtered or not).

So at the moment all rows have a correct TOC page entry except for the first row of every page from page 2 onwards.
To work around this, once the report ends I will reprocess all TOC entries making an adjustment to the first entry on each new page.

Ideally could you provision to raise an event directly after (or before) drawing the row on the page so that I can add a TOC entry at that point (either with or without the current page number passed to it).

Thanks

You are trying to use the FilterRow event for something other than what it was intended for. Its purpose is to tell PrintManager whether a row should be printed or not. As such, this event can be raised while PrintManager is constructing pages but before real printing. This is what I meant in my previous post.

Why can't you create an event handler for the iGPrintManager.Document.PrintPage event and count the number of printed pages in it?

I needed an event each time a row was printed, not just the page, so that I could add a TOC entry for each page.

I have worked around this by creating a correction routine after the whole document has been printed which adjusts the first TOC entry of each page to that of the page before it so its not a problem.

I remembered another event that could be used for your purpose, RequestPageBreak. It does not provide the current page number in its arguments, but it is raised before a row is really printed. Will it work for you?

Perhaps a better name for this event would be BeforePrintRow, and one of its arguments would be to allow inserting a page break.

Thanks Igor that works perfect.

Just to summarise, I am incrementing a custom PageNo counter within CustomDrawPageHeader and saving the grid row key and updating my TOC within RequestPageBreak.

Using the above I no longer need to use my TOC correction routine as previously mentioned.


I agree with your comment "Perhaps a better name for this event would be BeforePrintRow, and one of its arguments would be to allow inserting a page break."


Thank you.

Spoke too soon.

The RequestPageBreak event does not appear to be raised once the system has issued its own page break (this is correct in what it is doing).

So if I update my TOC within this event it misses adding an entry for the first row on each page.

For now I have reverted back to using my original method of updating the TOC within 'FilterRow' and then calling the TOC correction routine once the report has been printed.

Regards

My bad, I also hurried with RequestPageBreak. Indeed, it triggers only starting from the 2nd printed row on a page.

So, we have a suggestion for future updates - a BeforePrintRow or AfterPrintRow event, in which PrintManager should provide the printed page number in the event arguments, right?

No problem and yes that proposal sounds good.

No rush though, its working fine with my 'TOC adjustment' routine.

Happy New Year!