Printing produces headers on blank pages

It wouldn't surprise me if this problem was unique to my set-up, but when I try
to print or preview the contents of a workspace using Ian's printer utilities,
I end up with nothing more than a large number of blank pages.  They all have
proper headers, so things work at some level, but no source ever appears.  I'm
using Dolphin 5.0.1 on Windows 2000 SP2 with IE6 (both up to date on patches),
with the 12 June version of Goodies.

Trying to step through what happens doesn't tell me much (since I don't really
know how it's supposed to work anyway ;-), but it does lead me to wonder
whether this is another manifestation of the evil Rich Text control issue.

Any helpful ideas?

Don

Don,

> Any helpful ideas?

Not really I'm afraid.  I've just tried on my Win2K machine (same setup as
you described except that it uses IE 5.5) and it seems to work, both to a
local laser and a networked inkjet.

> I end up with nothing more than a large number of blank pages.

Does the number of blank pages roughly match the number of pages you expect
or does it just keep churning them out?

If you open up the "Page Setup" menu option does that look roughly right,
the margins and the little graphic for example?

Can you try it on a fresh image (with default fonts etc).

Does evaluating the following work?

pc := PrinterCanvas choose.
pc
    startDoc;
    startPage.
pc text: 'Hello World' at: 400@700.
pc ellipse: (400 @ 400 extent: 200).
pc
    endPage;
    endDoc

I'm out of ideas now. I'll have a think and see if I can come up with some
theories and/or debugging strategies.

Regards
    Ian

Ian,

> Does the number of blank pages roughly match the number of pages you expect
> or does it just keep churning them out?
It creates a large number of pages, close to the number of characters in the
rich text control.  This happens on the 2 Win2K systmes I have, but I also was
one of the Win2K users who .

I'm out of my depth here, so if what follows is nonsense, please just ignore
it.  From a workspace, I executed

     View active presenter halt; printPreview

When the debugger came up, I stepped into printPreview.  The page count seems
to be set in IDEPrinterAbstract>>printPreviewSetup:.  The argument is indeed a
RichTextEdit, so that seems fine, but the number of pages equals the size of
the pageOffsets collection, which is based on the range, which is equal to the
number of characters in the control.  I don't know whether this is where the
problem starts (possible), or this is where I stopped understanding what's
going on (for certain), but maybe it's of help.

> If you open up the "Page Setup" menu option does that look roughly right,
> the margins and the little graphic for example?
That all looks fine.  The little dotted outline of the margins (all at 1 inch)
look just like I'd expect.

> Can you try it on a fresh image (with default fonts etc).
Same behavior.

> Does evaluating the following work?
That worked fine, which just makes me all the more suspicious of the rich text
stuff on my machines.

> I'm out of ideas now. I'll have a think and see if I can come up with some
> theories and/or debugging strategies.
We've got one Win2K Advanced Server system that I'll try it on next.

How about the rich text DLLs?  Mine are:
     12/07/1999  07:00a               3,856 riched32.dll
and
     12/07/1999  01:00p               3,856 RICHED32.DLL
They're the same file version (5.0.2134.1) and identical to each other
according to fc.  Our Windows XP systems have
     08/23/2001  07:00a               3,584 riched32.dll
Their file version is 5.1.2600.0.

I'll see whether I can get any interesting (as opposed to disastrous) results
with a different version of the DLL.

Thanks for your quick response.

Don

> Regards
>     Ian
>
>
>
>
>
>
>

> rich text control.  This happens on the 2 Win2K systmes I have, but I also
was
> one of the Win2K users who .
Hello?  Incomplete sentence?  What I meant to say was that this same system had
another odd problem with the original D5 that OA immediately figured out, even
though they couldn't reproduce it.  That makes me think that some peculiarity
in the configuration might be at fault.

> I'll see whether I can get any interesting (as opposed to disastrous) results
> with a different version of the DLL.
Well this was neither disastrous nor interesting.  I copied the XP DLL to my
machine (with a special name), edited RichTextEdit(class)>>registerClass to
point to my new DLL, saved the image and restarted it.  No difference.  Oh,
well.

I had a different set of problems trying to test this on our Windows 2000
Advanced Server machine without having to reboot the thing.  Wisdom being the
better part of valor, I decided to give up on that before something bad
happened to a perfectly functional server.  Oh, well again.

Don