Mike,

I am using 2008.1.2161.

The error is not a PC or Infragistics error.

The printer will blink for about 1 minute and then print a PCL XL error page.  All it says is

Error: InsufficientMemory

Operator: text.

Position: 245107

It would take me a little while to create a sample pgm.

I have tried 3 printers with this output.  the first had about 2 MB and it choked.  the second had about 16MB and it choked.  the third has 32MB and it printed fine.  

So I changed the AppStyle right before printing to reduce the amount of graphics. It will print on the 16MB printer now.  But this is not a solution.

It seems that the UltraPrintPreviewDialog is sending the document as one continuous page and not breaking it up into pages.  The printers are set up for spooling and that should force them to print upon pagebreak.  But it acts like there are no pagebreaks being sent.

i had problems getting that one down to 200kb.

try this one.

Hi,

I ran your sample and I was able to get the print preview and actually print the grid with no problem. I got no Exceptions.

The only thing I noticed that might explain this is that your sample is using v8.1 of the grid - which I don't have. 8.1 is retired and no longer being updated. So I had to use v8.2.

You might want to try downloading the trial version of v8.2 and see if it works with that version.

If not, then I'm afraid the issue must be related either to the printer(s), the print drivers, or the machines you are using to test.

I want to try the v8.2 trial version, but how do I get to it?  I am only seeing v9.1

Trial downloads are available for the latest of our NetAdvantage for .NET releases.  Because of this, trial downloads of NetAdvantage for .NET 2008 Volume 2 are not available.  You will need to have a registered license key to download this version.

If you want to test with a later version, I suggest you use NetAdvantage for .NET 2009 Volume 1, which is (as you mentioned) currently available for trial download.

Vince,

Thanks for the tip.  It saved me some searching time.

Mike,

Good points.

I had actually created a new isl that I use just for printing.  It prints alternate rows with a light gray background and column headers with a light gray background.   I also dropped the FitWidthToPage.   It is printing faster.

The scaling issue is something that needs to be looked at because of the need for it.  As it is, I can print without scaling.  But soon I will have grids with too many columns for one page and it would be nice to be able to print them scaled down.

Thanks for the help.

-duane

Hi Duane,

Hm.. I was looking for an exception when I tested this the first time. I wasn't really thinking about how long the printing took.

I tried it out again and the print preview seems to come up pretty quick. When I press Print, it seems to take a bit longer than it did for the print preview. But I can see the dialog comes up and says "Printing page 1", and goes through the 3 pages at what I feel is a reasonable speed.

After that, the printer does seem to take a while to actually print it out. But at that point, the grid has already sent all the information to the printer and it's up to the print driver and the actual hardware - so I'm not sure the grid can do anything about that part of it.

One thing I noticedis that there are lots of different colors on the grid and lots of gradients in the grid. That all goes away when you take out the application style, though, so if turning off the ISL doesn't help much, then that's not the issue.

The other thing I suspected is that the scaling might be a problem. You are setting FitWidthToPages to 1 so the grid is scaled down to a page and the scaling is done by setting the scaling on the printer's graphics object. So I turned of FitWidthToPages and that seems to have sped it up some.

I notied that if I turn off the Isl AND FitWidthToPages, it's pretty fast. So it seemt o me that this is just a matter of the printing dealing with complexity and scaling. Perhaps the printers deal with the scaling of gradients in some way that is processor intensive.

Unfortunately, I don't see anything we can do about this, unless we completely revamp the grid's printing logic and find some other way to do the scaling. But that would be a major effort and would have to be handled as a feature request.