 |
|
|
Hello!
Once again my thanks for this wonderful contribution. I wanted to let you know about a couple things I uncovered.
I started using grids in some templates and noticed a problem with column sizes. The columns were consistently smaller widths in the Generator compared to the Editor. I kludged around the problem by replacing the CUnitConversion::InchesToPixels calls in the "void CDrawGrid::Draw( int page, CDC* dc )" column calculations with:
CUnitConversion::LineToPixels
{
double pixelsPerInch = static_cast(CUnitConversion::s_resolution) *
(inches * 1.25);
return static_cast(pixelsPerInch);
}
The 1.25 offset made them fit the border rectangle perfectly, but I don't know why my kludge works or why InchesToPixel wasn't sufficient. It seems my results are not totally correct either since I can make a box in the Editor the same width as the column, but box and column will be different widths in the Generator.
The second problem with sizing was with the page itself. I set a page to 8.5 x 11 inches and set a .5 inch border on each side. The page then prints/previews from the Editor with an extra .5 inches on the right and bottom.
I traced the problem to "void CReportCreatorView::OnDraw(CDC* pDC)" and made another kludge as follows:
// Print zoom is the difference between screen and printer resolution.
double zoom = pDC->GetDeviceCaps( LOGPIXELSX ) / m_screenResolutionX;
zoom += .12;
Again, I don't know why adding .12 to the zoom factor was necessary or exactly how it fixed the problem.
If anyone knows why this is or has a good fix for the problem(s) please let me know. Thank you in advance.
|
|
|
|
|
|
|
Wouldn't you know I discovered and fixed the column width bug right after I sent in my question!
The problem is that in CColumn the width is set to type int, where it should be type double. If you have columns that are fractional they would be truncated to int!
To fix, simply change all CColumn "width" properties and methods to type double. All the column width issues disappear.
|
|
|
|
|
|
|
ReportEditor source looks have lots of things.
I'll appreciate again if you offer some usage to use it in MFC apps.
Could you upload a ReportEditor demo project?
|
|
|
|
|
|
|
|
|
|
I need to use one field more than once. I have looked at CReportGenerator::Add (as you sugested on 5 Jan '07 to yokosuna) and have tried to modify it, unfortunately without any luck.
How do I get the name of the objects that I iterate over? I am thinking of something like this:
BOOL CReportGenerator::Add( const CString & field, const CString & data )
{
SetErrorMessage( _T( "" ) );
BOOL result = FALSE;
CDrawField* obj = dynamic_cast< CDrawField* >( GetObject( field ) );
if (!obj)
return FALSE;
int iMax = GetData().GetSize();
for(int i=0; i<imax;>
{
if (obj->GetName() == ?????->GetName()) {
obj->AddData( data );
result = TRUE;
}
}
return result;
}
However, I am not sure that this will solve the problem. For testing, I added a second obj->AddData(data); right after the first one but the second occurence of the field was still not printed.
I believe it is important that the same field can be used more than once. Any help would be very much appreciated.
Like others have already said, thank you very much for this great code.
modified on Thursday, February 19, 2009 2:28 AM
|
|
|
|
|
|
|
I'm not sure why you want to use the same field twice? As the field would have the same properties, it would just print over itself, and being the same instance, any delete would wreak havoc with the other instance. You might want to copy the field to a new one instead - which still would be of little use if the attributes of the two fields would be identical.
|
|
|
|
|
|
|
Thank you Johan for your reply. I will try to elaborate with a simple example of Swiss post office checks. See the following pdf which shows the orange type (there are 2 other types as well):
http://www.ocrb.ch/download/inpayslip_isr_man.Par.0001.File.pdf
After page 7 there are quite a few examples. On page 28 and 29 there are examples of these checks (reduced in size) which are perforated to the invoice. In these examples you will notice that the name and address as well as the amount will be required at least 3 times on a single form.
Unfortunately I have other examples which can use up to 60 fields being used 2-4 times on the same form.
Maybe you have a suggestion how I can do this. The optimal solution would obviously be to be able to print the field as many times as required.
modified on Thursday, February 26, 2009 3:23 AM
|
|
|
|
|
|
|
Ok, there is nothing inherent disallowing several fields with the same name in the framework. You'll have to derive a class from CReportGenerator to access the protected GetData()-member, and loop through the fields using the field object index rather than the field name, setting data as necessary (asking each object for its field name to make sure that the correct data gets in the correct field, of course). Print should work anyway, it is just looping the fields, not caring about the name.
Another idea is creating the field names with a suffix, a running number, and create a field name, try to get the field object, increase the number, try to get the field object etc. until no field is found.
|
|
|
|
|
|
|
I have been enjoying your Report code for some time. It's a wonderful contribution!
My question regards editing and including new entity types. I've been trying to implement a polygon shape and I could really use a shove in the right direction.
Since the polygons I want to use are a freehand collection of an indeterminate number of points the problem I ran into was capturing all the necessary mouse points for the corners.
Is there a way to set the granularity (how often to capture etc.) of the mouse points and add them to my polygon point collection for inclusion in the draw cycle?
I thought initially this would be simple (like scribble and all the other illustrations of point capture) but those examples all have independent mouse capture/control mechanisms that are tied to the shape objects themselves.
I hope someone may have a tip towards solving this.
Thanks again for the wonderful code and best wishes.
|
|
|
|
|
|
|
Thanks for the feedback!
What I would do would be to use the normal line objects, but group them (automatic or as a user selection - or why not both). You might want to look at the ancestor projects, the flow chart- and UML-editor for some ideas.
To go into the mouse handling is indeed possible, but you might have to do an awful lot of overriding.
|
|
|
|
|
|
|
Is there a way to assign attributes (almost back/fore color,font weight and text alignment) to a grid's cell programmatically from code?
thanks for this fantastic piece of code, anyway.
|
|
|
|
|
|
|
Thanks for the feedback!
CReportGenerator::GetObject gives access to the individual drawing objects, then you can use RTTI to cast the objects to the specific type, or access the public CDrawObject members.
|
|
|
|
|
|
|
Only one word:
!Excelent!!
Josewh
|
|
|
|
|
|
|
Thanks alot for the feedback!
|
|
|
|
|
|
|
Can Strengthen Grid Function?
Support Merger and Ajust Cell like Microsoft Word.
Best regards！
|
|
|
|
|
|
|
Lots of enhancements would be possible, calculated fields, image fields etc. etc. etc. What you have here is a documented framework to build from, or rather to derive from and add to as you see fit. The main purpose of the code is to give a way to create reports, which I know something that is a daunting task initially even for experienced programmers.
I will indeed continue to maintain the code, but find little time to expand on it in the forseeable future, unfortunately.
|
|
|
|
|
|
|
Firstly, I should say thank you very mush for your great code. Your code is very helpful for me.
My questioin is how to add new menu items to the pop-up menu (right button message) for different entities seperately without modifying your source code?
I'm looking forward to your answering.
Thanks!
Xiaoming Huang
|
|
|
|
|
|
|
Thanks for the feedback!
There is support for this, detailed in the documentation for the underlying CDiagramEditor, if you mean the report editor. You'll find that documentation here http://www.codeproject.com/KB/miscctrl/diagrameditor.aspx[^]- see Creating your own editor popup menu in the How To-section.
|
|
|
|
|
|
|
I have used the Report Generator in my application for several years and appreciate the work you have done on this.
After upgrading my compiler to Visual Studio 2008 SP1 (from Visual Studio 2008), my application now bombs when trying to print or print preview from release mode if the the page includes a grid of any kind (empty/full, with or without lines, etc.). The problem only seems to occur on Vista Machines, not on XP machines. The application does not fail in debug mode.
Please let me know if you have any suggestions.
Scott Moss
|
|
|
|
|
|
|
Not using Vista (yes, I'm old and conservative), I really can't tell. The debug-version initialises variables, so you might indeed see problems in release but not debug. In this excellent article by Joe Newcomer http://www.codeproject.com/KB/debug/survivereleasever.aspx[^] you'll find everything you need to go on.
|
|
|
|
|
|
|
I will let you know what I find.
Scott Moss
|
|
|
|
|
|
|
I was able to determine that the problem (application will crash) is not related to Windows Vista (the error also occurs in Windows XP).
It actually is related to the upgrade of Microsoft .Net Framework 2.0 Service Pack 1 (SP1) to Service Pack 2 (SP2). If you upgrade your compiler to Visual Studio 2008 SP1, this installation will also install Microsoft .Net 3.5 SP1. This .Net upgrade also upgrades .Net Framework 2.0 from SP1 to SP2. When this upgrade of .Net 2.0 occurs, printing no longer works.
Also, I believe that the error only occurs if the application uses the new MFC ribbon interface (I was able to do a print preview using the Report Generator when creating an application that did not use the ribbon interface).
I know that the error is occurring in the CDrawGrid Draw method but am unable to isolate the actual error.
To temporarily solve the problem, I made sure that .Net 3.5 (not SP1) was installed on user machines.
Scott Moss
|
|
|
|
|
|
|
Thanks a lot for the info! Not running VS2008 (still using MSVC 6.0, yes, I know I'm old and conservative), this is not something I can easily analyse.
|
|
|
|
|
|
|
I wanted to update you on this issue. The project that experienced the problem that I had described earlier was compiled using managed c++ (where the Common Language Runtime, /clr setting was turned on in Visual Studio.
If one uses your printing classes in such a managed c++ project and the application tries to print a page that contains a grid, the application will fail in release mode if .Net 3.5 SP1 has been installed. The application works if .Net 3.5 or earlier is installed, or if the application is run in debug mode.
To get around this problem, we explicitely specified that the files used for printing (as contained in your sample project) were unmanaged by using the "#pragma unmanaged" compiler directive at the top of your .h and .cpp files. Once this was done the application no longer fails when printing a grid in release mode.
Scott Moss
|
|
|
|
|
|
|
Firstly, I should say thank you very mush for your great code. Your code is very helpful for me.
My questioin is how to add new menu items to the pop-up menu (right button message) for different entities seperately without modifying your source code?
I'm looking forward to your answering.
Thanks!
Xiaoming Huang
|
|
|
|
|
Prize winner in Competition
"MFC/C++ Feb 2005" 
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin