|
A column title can be added by just placing a text label above the column. By adding a text label at the bottom and putting in the text [%page%], you'll get a page number printed. Download the documentation for more info!
|
|
|
|
|
want to break the print/preview page of records from database. i'm using MS ACCESS DAO database. i want to print only 6 (six) records onto a page and next six on to next page and so on upto the end of the records available.
how can i do it?
when i`m printing it it is showing all the records on to a single page and showing 8 or nine records onto first page... but it is not continuing after it to the next page.
plz help me in detail how can i print records on the next page after 6 records.
i'll be highly thankful to u.
regards!
Shiv
DRDO
INDIA
|
|
|
|
|
This should be possible by creating a grid 6 lines high.
|
|
|
|
|
plz describe in detail...
|
|
|
|
|
Start the ReportCreator. Select Layout | Settings. Set the grid size to, say, 0.2 inches stepsize. Check Snap to grid.
Now, add a grid to the template. Right-click and select Properties. Set 6 in Lines per inch (well, you don't have to do that, as it will already say 6 lines per inch). Add columns as desired.
When you fill the template with data from your database and print it, it will now print the 6 first lines on the first page, the 6 next on the next and so on.
Experiment! You have access to all the source code and documentation as well.
|
|
|
|
|
Hello,
I have created two templates: a title template and a section template.
The title template has a grid with 30 lines per page called "Grid".
The section template has a grid with 30 lines per page called "Grid" as well.
In addition, the section template has a small grid called "Hoohoo" with 15 lines per page.
Following is the code I am using:
<br />
strTitle = "c:\\title.rpt";<br />
strBody = "c:\\body.rpt";<br />
<br />
if( m_reportGenerator.AddTemplate( strTitle, TEMPLATE_TYPE_TITLE_PAGE ) &&<br />
m_reportGenerator.AddTemplate( strBody, TEMPLATE_TYPE_SECTION ) )<br />
{<br />
CStringArray arr;<br />
m_reportGenerator.Add( "Grid", arr );<br />
}<br />
However, I am not filling the "Hoohoo" grid with anything.
When I am printing the document, I am only getting a single page output; the title page. I debugged the code and found out that the "CalculatePages" is detecting two grids in the section page: "Grid" containing 20 lines and the empty "Hoohoo" grid. Due to the empty "Hoohoo" grid, the function is executing the "if( emptygrid )" block and is not considering the second page (although is does have another grid with data).
Is this the intended behavior of the CalculatePages or is it a small booboo?
Thanks in Advance!
~~~~~~~~~~~~~~~
CDRom
|
|
|
|
|
This is most definitely a booboo. If you mail the report-files to me directly, you'll help me save some time. I'll look into this during the weekend, together with the zoom/ruler thing. Note, however, that the report creator is just a convenience, if I have to break my back fixing it, it might be left as it is. Ha! vanity will forbid me leaving it unfixed.
|
|
|
|
|
First of all, thanks for the brilliant code...
I have visited this article since a long time but did not have time to utilize it in my programs. Today I spent some time testing the "ReportCreator" and found the following problem:
1- In "Report Creator", create a new report
2- Zoom-in, using the scroll control on the mouse, until the report exceeds the screen's length.
3- Scroll down to the end of the report
4- Zoom-out, using the scroll control on the mouse, until the complete report is visible on screen
5- Problem: The left ruler no longer starts from zero...
I have read "all" the acticle's discussion board and was unable to find anything related to the problem. However I found many useful sugesstions and corrections.
Could I possible obtain an updated version of the package? I have not used any part of your current package and do not mind of any backward-compatiblity issues. In case you have anything to send, my email is: omtara@gmail.com
Thanks in Advance,
-- modified at 10:39 Saturday 12th August, 2006
~~~~~~~~~~~~~~~
CDRom
|
|
|
|
|
johan,
i decided to start a new thread instead and take you up on your offer.
i'm trying to modify ReportGenerator so it can support different charsets. i've done it successfully with ReportCreator, so i thought i'd do the same with ReportGenerator.
here's a list of things i edited from the original:
1. i removed all dynamic_cast from ReportGenerator.cpp, since these were apparently causing the program to have runtime errors.
2. in the .rpt file i am reading, i inserted a field after the fontSize field for a fontCharSet field. no particular reason for placing it there, just thought it was more similar to the fontSize field than any of the others.
3. in the FromString functions of DrawLabel, DrawField, and DrawGrid, i inserted lines for tokenizing the fontCharSet field, also after the fontSize lines
4. in both Column and DrawObject, i declared a new member fontCharSet, with 2 new functions for setting and getting the values.
5. in the Draw functions of DrawLabel and DrawField, i inserted lines for fetching the charset of the LOGFONT.
my test program is actually quite simple: a pushbutton calls a filedialog that loads a .rpt file, which then calls a printdialog, then the .rpt is supposed to be printed. the .rpt file contains only one label.
when i run the program and start the printing, the program crashes. sometimes a message appears saying "application cannot access memory" (not verbatim). most times it just stops responding and i have to end task to get it to terminate.
stepping through the program, i find that the program actually gets stuck in CalculatePages() function, which is being called before printing.
i made another program with the same functionality, but using the original ReportGenerator and the original .rpt format. i've found that the two programs start to deviate after the following line: (i removed dynamic_cast from the original)
CDrawGrid* element = ( CDrawGrid* )( fields->GetAt( i ) );
looking at the m_data (CStringArray) member of the element, i see that m_nSize is 0, which eventually causes CalculatePages to return 0 pages, and which eventually causes the program to hang (i think...)
i'm sure i'm just missing something here, i just started programming Visual C++ 2 weeks ago. any help would be much appreciated. sorry if the message was quite lengthy. thanks.
archie
|
|
|
|
|
archie,
I have a charset addition in the pipeline, but feel free to send you changes to me, and we'll see if there is something I have forgotten.
The dynamic_cast shouldn't really be the problem, that it fails would indicate problems elsewhere. I would really like to help you, and easiest would be if you packed together your project and the relevant rpt-file and mailed it to me.
|
|
|
|
|
finally realized what i was doing wrong. i forgot to enable RTTI. i think that should solve my problems.
thanks a lot for your help. good luck with your next release!
|
|
|
|
|
That is a tricky one. Good luck with the rest of the project!
|
|
|
|
|
First this is a good job, but i have a problem in arabic fonts not work
is there any special things to done to be work or what?
ahmed abd elhady
-- modified at 8:49 Monday 10th July, 2006
|
|
|
|
|
Can't say I have much experience with arabic fonts, but one thing is for sure - the current version is not taking the charset into consideration. But don't despair, I've recently updated the underlying CDiagramEditor , and an update of this article is also on the way (during the weekend, most likely), supporting charsets. We'll see if that helps!
|
|
|
|
|
you can add
lf.lfCharSet =ARABIC_CHARSET ;
for every font and it will work as i try it for arabic Language
ahmed abd elhady
|
|
|
|
|
This will be the case - that is, the charset of the selected font from the font dialog will be saved together with the rest of the font settings, which will give the result you mention.
|
|
|
|
|
would that also work for East Asian fonts? thanks in advance!
|
|
|
|
|
|
i guess i should probably start a new thread, but i think my problem is just a few lines of code away.
i modified both ReportCreator and ReportGenerator to support charsets. so far i got ReportCreator to save, load, display, print Asian characters nicely. its ReportGenerator that i'm having problem with.
i'm having problems when i use the CalculatePages() function. as i understand it, the function treats all objects on the report template as grids to calculate the number of pages. however, i'm getting strange values for m_nSize, m_nMaxSize and m_nGrowBy for the StringArray inside the DrawGrid. this causes my program to crash.
any help would be greatly appreciated. thanks in advance!
|
|
|
|
|
I would indeed be glad to give a hand, but I'll either need more info, or some actual code to look at. Feel free to mail me privately, if you don't think this is some general matter.
|
|
|
|
|
I faced the same page break puzzle, did something in a few weeks and seems it works...
Thanks for Johan's great work, the change I did is heavily based on his.
It's a single template attempt. So it may violate the logic for multiple templates.
Concepts:
A) Report Template / Report Creator
Add all objects using the report creator as usual
Tricks: for result to be displayed using grid, I just draw a single row
i.e. say if you want to print 5 lines in a row, set the row height to 0.2" and set proper line per inch value as 5
*key concept - grid will grow or split into multiple grids at run time, objects below it will be shifted down.
B) Report Generator
DrawObjects added to "fields" are "sorted", i.e. index 0 will store object on the top of the template. This makes the logic to identify objects "below it" much easier.
A new CalculatePages() was written to calculate and return the max number of pages. It needs to know the instance of CPrintInfo*.
And here it comes the stupid algorithm:
In first pass, all grids will be expanded to its actual size, the change of height would affect all objects below it.
So after first pass, I have a piece of long paper.
In second pass, grids across page border will be splited (I used a recursion here) into "extended grids" until all of them can fit into a page boundary, "extended grids" are created based on the original instance so that properties can be preserved. However, they need to have an unique name. Each DrawObject will be checked to see if it is across two pages, if found, it will be moved down.
All changes of height once again would affect all DrawObjects below it.
So after 2nd pass, we have DrawObjects that never overlap with two pages.
In order not to affect the original object stores, "extended grids" are firstly added to a temporary store and then added back to the original object stores
at the end of the 2nd pass.
Each DrawObject also has a variable to store the page # it belongs to. All DrawObjects will be repositioned to page one coordinate, (say object A
on page top of page 1 and object B on page top of page 2 both have the similar values for its "top" poistion, but A will have page # 1 and B will have page # 2.)
When print routine starts page by page, only objects on the right page will have its Draw function called.
That's it! Hope it helps!
-- modified at 7:17 Thursday 29th June, 2006
|
|
|
|
|
Hi Johan,
I am trying to print to a 2nd printer (non-default printer) but it's not working and I can't figure out what I am doing wrong. I must be calling Print(dc) incorrectly.
I use GetPrinterDevice as per microsoft kb Q166129:
((CApp*) AfxGetApp ())->GetPrinterDevice(_T("WPLUSB"), &hDevNames, &hDevMode);
AfxGetApp()->SelectPrinter(hDevNames, hDevMode);
Load up the report and then:
CPrintDialog pd( FALSE );
HDC hdcPrinter = pd.GetPrinterDC();
CDC dc;
dc.Attach( hdcPrinter );
RepGenerator.Print(&dc);
I get a debug assertion in CReportGenerator::Print( CDC * dc )
at: if( dc->StartDoc( &docinfo ) )
Thanks.
CarlH
|
|
|
|
|
Right of the cuff, I can't say. When an assertion is triggered, you are given the option to break into the MFC source code, where more often than not, you'll be able to see what is the problem.
If SelectPrinter is setting the indicated printer as the default printer (I've never tried that call), you would not need add a CDC as in-parameter to the Print -call, the default CDC will be used automatically. Have you verified that this call really selects the secondary printer as default?
|
|
|
|
|
SelectPrinter does not select the secondary printer as default, it allows to print to a non-default printer.
CarlH
|
|
|
|
|
For whoever is interested the solution is:
CDC dc;
((CApp*) AfxGetApp ())->CreatePrinterDC(dc);
RepGenerator.Print(&dc);
dc.DeleteDC();
Thanks,
CarlH
-- modified at 9:26 Monday 3rd July, 2006
|
|
|
|
|