I am generating print preview using report class object of Infragistics.Windows.Reporting namespace,
but the problem is when dealing with large amount of data, application usually becomes irreponsive and gets stuck while preview generation also takes several minutes which is not desired, i am attaching my sample application here, please suggest any good workaround or solution for it
download sample project
Related
The problem is, we dont have MS Office in our university anymore, earlier we used its
preview feature in Windows File Explorer, so to view multiple assignments on the fly by
just clicking on the word file or using arrow keys navigation. This helped us the teachers, to
check many assignments without having to open each file 1 by 1. Now we switched to WPS Office,
thus the preview feature in windows explorer is gone. This made the assignments checking extremely
slow as now we have to open each file before marking it.
I am a teacher too, who can code a little, so I want to build up an application in windows forms,
that enables to preview .docx, .dox and .rtf files. I tried hard since 1.5 months so far, used
Pandoc, OpenXML Powertools, tried with trial versions of libraries like Aspire, Aspose, GemBox, Xceeds
But so far no free and reliable solution is found, some of them either spoil the formatting in unacceptable way. Some of them have trial limits. Most of them do not convert word own drawings (that the students draw inside Word document itself).
So basically I am looking for a reliable and free resource that converts the whole document,
doesn't miss anything and is free. We the teachers, still can overlook formatting a little.
What I have tried: Everything as listed above, in win forms application
Current best solution working for us: Using Syncfusion DocIO library to convert the said file
formats to PDF and then loading that PDF in a CefSharp browser control in winforms. This requires
just ~2 seconds load time of the document and gives nice zooming options. But its a trial version
and eventually it will expire after trial period.
NOTE: I cannot use any online or server based solution as it will be very slow (consider clicking on the file and then waiting for more than 10 seconds to load a converted document).
I've used App Maker for several small projects since the launch of the EAP. Coming from TDD with PHP and hot reloading with Node, I'm frustrated by how long it takes to see changes and debug. I'm now wondering if I'm missing some critical piece of knowledge, because it seems too tedious.
Here's an example:
I have a form field that's bound to a client-side function. The function returns a calculated number based on the value of other form fields (some of which are also calculated). When I click preview and fill out the form, of course, there's going to be a console error or the calculation will be off. So I tweak the function, hit preview, and try again - repeatedly, until I get the expected output.
Since it takes 10-15 seconds for my preview to render each time, I'm spending a ton of dev time staring at a rotating circle.
I've had some success composing and debugging some of the scripts in another environment (Google Apps Scripts, local IDE, etc), then cutting and pasting them into App Maker. That doesn't work well when the function references App Maker models and widgets though.
Is there something I'm missing here, or is repetitive previewing really the only way to design and debug within App Maker?
A quick and dirty method I use a lot is adding this line to any function I want to look at closely. AppMaker shows a warning for every debugger call so there's no risk of forgetting it in the code as well.
debugger;
Of course, this only works for client-side scripts.
My first question here :)
I have a report generating website. When the user clicks a button the report is generated in a different sub as a html-file and is written to a txt-file. The html-file is later converted to a PDF in a different sub.
When the report is long (200 pages), I get out of memory exception when the PDF is generated. Memory seams to be allocated by the html generation, since when I convert the html to PDF in a different webform it works perfect.
I have tried to use analysis program like ANTS, but I dont have the knowledge to sort it out.
How can I release the html generation from memory?
Thanks!
/Georg
Your memory from a good component should hopefully get cleared out - however in this case since its a fairly large document it may by OK design but max the memory out. You can
1. Try to increase the memory in IIS available to your worker process
2. http://support.microsoft.com/kb/911716
3. (you didnt specify server version so this is dependent on that) http://support.microsoft.com/kb/820108
With ANTS - there are tutorials on RedGates site discussing its usage. If its a third party component there may not be much you can do except increase the available memory or contact the vendor.
I'm working with an asp.net application that produces large PDF documents from HTML. The content is perhaps complex (detailed grid type listings, css styled, running to 40+ pages) compared to typical usage. None of the libraries we've tried are performing adequately. Typically a 40 page document is taking upwards of a minute to render on a powerful multi-core machine.
We are able to decouple the generation from the web application and also pre-generate documents in some cases. Still, the frequency with which content changes requires a faster solution.
So, does anyone have experience of a PDF generation component that can output a content heavy 40 page document in seconds rather than minutes? Or are our expectations unrealistic?
NB: I'd rather not "out" the poorly performing components here as we are seeking support from vendors to make improvements. I've reviewed previously questions posted on StackOverflow and none appear to deal with this type or size of document.
An option might be to not convert html to PDF and take another approach. We use the ActiveReports reporting tool that generates PDF, its pretty powerful when using sub-reports for multi-dataset reports, and completely integrates with visual studio.
This means that you would need to rebuild the report to produce the same data that you see on-screen. This is sometimes not such a bad thing as you can style up the report specifically for printing.
PDFs can be generated via a back-end service and/or emailed or produced on the fly to the browser.
We have an ASP.NET application that uses the Infragistics WebSchedule control to display appointments etc in the same manner as Outlook. The problem we have is that the customer wants to be able to print the page as it appears on the screen - which the control itself does not appear to support directly.
We have developed a Crystal Report that does a fair job but it is pretty complicated and just a little bit flaky (it does not stretch to accommodate all of the appointments for a particular day so if there are too many then they spill over). Bascially we have bullied Crystal to doing something it is not really meant to do - render a graphical representation of a diary rather than list the data in a tabular manner.
Does anyone have a better alternative to this?
Thanks in advance
DayPilot Pro (our product) supports PNG export that allows easy calendar/schedule printing (almost a pixel-by-pixel copy of the HTML control).
It's working for both the Calendar (traditional Outlook-like day/week view):
http://www.daypilot.org/demo/Calendar/
and for the Scheduler (showing a time line for multiple resources):
http://www.daypilot.org/demo/Scheduler/
Try "Print/export" button below the controls.
Well in the end I decided to junk the Crystal Report in this instance. It's fine for tabular data and graph data but not really suitable for a graphical representation of a diary/scheduler.
I opted for an XML/XSLT solution which has turned out better than I expected - especially in terms of speed.
I was able to generate an XML stream and depending on the date range feed it to a suitable XSL template which produced a Weekly or Monthly view of the report. A colleague sprinkled some CSS over it and we're sorted.