Printing

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
> > Since you are taking requests... ;)  I seem to recall that you have
> > different versions of a package related to printing for Window XP and
> > non-XP (or maybe it is a different SP of XP).
>
> I've had a go at refactoring the printer goodie and have come up with a
set
> of packages that I _think_ will work on all Windows OSs (all I know is
that
> it works on XP(SP1) and 2000 which are the only ones I have).  I've gone
> back to just using the PrintDlg api (rather than trying to use PrintDlg
and
> PrintDlgEx), which means I lose a small bit of functionality, but makes it
a
> lot easier to accommodate all OSs.  I've also factored out all the places
> where the RichEdit class (my wrapper for the RichTextEdit control
available
> in XP(SP1)) is used so that doesn't cause a problem any more.
...

Thanks, I downloaded it, and it looks good so far.  I need to pull in a
RichTextEdit2 class to test page breaks.  I suppose I need to figure out
what version of Windows support RichTextEdit2 (or can be made to support
it).  It _might_ be worth considering including it in your printer packages.
But then we need to sort out Windows version issues.  I suppose there could
be a RichTextEdit subclass (not sure what to call it), that could use the
latest RichTextEdit version available, and fall back to older versions.  It
looks like OA has a #todo indicating that may have eventually been their
intent.  FYI, my reasons for needing RTE2 are  explained here:
http://groups.google.com/groups?&threadm=aqnj7v%24bnlk9%241%40ID-50880.news.dfncis.de&rnum=1
Basically I just followed Chris Uppal's suggestion.  It looks like your code
will allow me to pass an instance of whatever RTE version I want, so I don't
think there is any reason you would _need_ to include RTE2 in your packages,
unless you wanted additional functionality provided by RTE2.

I will try your printer package under Windows 98 on VMWare, and try to provi
de any fixes if needed.

Thanks for doing this.  I really appreciate it.

Chris

Chris,
:
> Thanks, I downloaded it, and it looks good so far.  I need to pull in
> a RichTextEdit2 class to test page breaks.  I suppose I need to
> figure out what version of Windows support RichTextEdit2 (or can be
> made to support it).  It _might_ be worth considering including it in
> your printer packages.

The intention is to rework my RichEdit class structure so that it has a base
class and than a subclass for each of the RichEdit versions, each subclass
introducing the functionality (and fixes!) for that version. Something like

RichEdit
    RichEdit2  (available on NT and 98)
        RichEdit3 (ME, 2000 and XP)
            RichEdit4_1  (XP(SP1))

Asking for a RichEdit would then answer an instance of the highest version
available on the current platform.  The highest version available would be
worked out by checking the dll available rather than using the OS version.
That might be a bit difficult for RichEdit2 and RichEdit3 as they have the
same dll name but I think it can be done.

I would include it as a separate package, or packages, and the Printer
package already tries to use RichEdit if it is available (but can drop back
to Dolphin's RichTextEdit if not).

FWIW, you can find a list of the differences between RichEdit versions on
MSDN -

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl
atform/commctls/richedit/richeditcontrols/aboutricheditcontrols.asp>

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
> The intention is to rework my RichEdit class structure so that it has a
base
> class and than a subclass for each of the RichEdit versions, each subclass
> introducing the functionality (and fixes!) for that version. Something
like
...

That sounds like a great idea.

> Asking for a RichEdit would then answer an instance of the highest version
> available on the current platform.  The highest version available would be
> worked out by checking the dll available rather than using the OS version.
> That might be a bit difficult for RichEdit2 and RichEdit3 as they have the
> same dll name but I think it can be done.

Something like the code bellow might work for that.  Interestingly, what
productVersion returns does not seem to jibe with what I see in the windows
properties dialog for the file.  The properties dialog say the "Product
Version" is 3.0, but Dolphin says it is 5.0.0.0.  I am not sure if this is a
bug or what.  BTW I am using XP SP1.
===========
v := VersionInfo forPath: SessionManager current systemDirectory ,
'\RICHED20.DLL'.
v productVersionString.
v fileVersionString .
===========

> I would include it as a separate package, or packages, and the Printer
> package already tries to use RichEdit if it is available (but can drop
back
> to Dolphin's RichTextEdit if not).

Great idea, and thanks for the OS info.

Chris

Ian,

> There is a download (18K) available at the following address if you, or
> anyone else, would like to try it but please bear in mind that is just a
> test version so all the obvious warnings and disclaimers apply.
>
> http://www.idb.me.uk/files/printing.zip

I'm sorry, but I haven't had a chance actually to /try/ this code yet[*] (and
anyway I only have WinXP and 2K to test on).  I have eyeballed it, though, and
you've made /exactly/ the split between the 'Printer' and 'Printer API'
packages that I was hoping for, so thank you very much.

(Well, to be honest, it's not /exact/ -- I had guessed that you'd call it "IDB
Printer WinAPI" ;-)

But, just to be awkward, can I ask you to "expose" a few more fields of the
DEVMODE structure ?  I'll send you my modified #defineFields if you like,
though the only difference is that I've changed all the printing-related fields
from #filler to #new.

Many thanks.

    -- chris


[*]  I've put printing on hold for a while -- there's only so much time you can
spend thinking about Windows printing APIs before your starts to wither.  As
I'm /sure/ you already know...

I wrote:

> there's only so much time
> you can spend thinking about Windows printing APIs before your starts to
> wither.

Sigh...

Please insert the word "brain" between "your" and "starts".

See, it's happening already.

    -- chris

Chris,

> But, just to be awkward, can I ask you to "expose" a few more fields
> of the DEVMODE structure ?

Sure.  I'll change the structure definition and probably add wrappers for
the fields that look like they may be useful (and which I can understand).
It may take a few days as I'm working my way through the RichEdit api at the
moment - and there are a _lot_ of messages.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
> I've had a go at refactoring the printer goodie and have come up with a
set
> of packages that I _think_ will work on all Windows OSs (all I know is
that
> it works on XP(SP1) and 2000 which are the only ones I have).  I've gone
> back to just using the PrintDlg api (rather than trying to use PrintDlg
and
> PrintDlgEx), which means I lose a small bit of functionality, but makes it
a
> lot easier to accommodate all OSs.  I've also factored out all the places
> where the RichEdit class (my wrapper for the RichTextEdit control
available
> in XP(SP1)) is used so that doesn't cause a problem any more.
...
> I _really_ would appreciate any feedback on this, good or bad, especially
> from anyone using it on 98 or ME.

PrinterAbstract<<initialize causes an assertion failure in this bit of code
under Windows 98:
====
apiResult := ComDlgLibrary default printDlg: printDlgStruct asParameter.
printDlgStruct flags: (printDlgStruct flags maskClear: PD_RETURNDEFAULT).
self assert: [apiResult].
====
I guess it does not like something about the printDlgStruct on Windows 98.
I am going to try to review the structure.

Additionally when I try to use a RichTextEdit2 (version 2 on Windows XP SP1)
the print preview seems to enter an endless loop in
RichTextEdit<<printerPrintPage:on:preview: in [range cpMin < range cpMax]
whileTrue: [...].  It looks like your code may depend upon version specific
behavior.  This may not be important now, since it probably does not
officially support RTE2 anyway.  If you want to see what I am talking about
you can load the package bellow (There is some code in the package comment):
http://www.mitchellscientific.com/smalltalk/temp/CJD-IDBPrintTest.pac

Chris

Chris,

Thanks for the feedback.

> I guess it does not like something about the printDlgStruct on
> Windows 98. I am going to try to review the structure.

It might also be that the return value is different (not just true or false)
on Win98.  I'll have a look tomorrow....

> Additionally when I try to use a RichTextEdit2 (version 2 on Windows
> XP SP1) the print preview seems to enter an endless loop in
> RichTextEdit<<printerPrintPage:on:preview: in [range cpMin < range
> cpMax] whileTrue: [...].

I've seen that before, it's caused by the printer code thinking there is
more text in the RichEdit than there actually is..  Can you check the
RichEdit>>printerRange: method to see if the last line reads

ifFalse: [CHARRANGE cpMin: 0 cpMax: (self getTextLength: #precise)]

or

ifFalse: [CHARRANGE cpMin: 0 cpMax: self plainText size]

The first line should work on XP (SP1) but the second is more generic.
Could you try changing it to see if it makes a difference please.

> probably does not officially support RTE2 anyway.  If you want to see
> what I am talking about you can load the package bellow (There is
> some code in the package comment):
> http://www.mitchellscientific.com/smalltalk/temp/CJD-IDBPrintTest.pac

Thanks, I'll have a look at that tomorrow as well.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Chris,

> Additionally when I try to use a RichTextEdit2 (version 2 on Windows
> XP SP1) the print preview seems to enter an endless loop in
> RichTextEdit<<printerPrintPage:on:preview: in [range cpMin < range
> cpMax] whileTrue: [...].

OK, this is down to the big problem that I had with my original attempts to
replace the RichTextEdit class with a wrapper for the later RTE versions.
The original uses cr-lf line delimiters and all the later ones (from RTE 2.0
onwards) just use a cr.  This means problems for anything that has to know
the exact number of characters in the control.  To get round it you will
need to ....

add a new Win32Structure subclass called GETTEXTLENGTHEX with one class
method

defineFields
    self
        defineField: #flags type: DWORDField new;
        defineField: #codePage type: DWORDField new

and then override the #printerRange method in your RichTextEdit2 class

printerRange: aPrinter
    | gtl len |
    gtl := GETTEXTLENGTHEX new.
    gtl flags: 2. "GTL_PRECISE"
    len := self
        sendMessage: 1119  "EM_GETTEXTLENGTH"
        wParam: gtl yourAddress
        lParam: 0.
    ^((aPrinter printDlgStruct flags anyMask: PD_SELECTION)
                and: [self hasSelection])
        ifTrue: [self getSelectionRange]
        ifFalse: [CHARRANGE cpMin: 0 cpMax: len]

This sets the range to the correct value for a RichTextEdit2 instance and
allows the PrintPreview to work.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Chris,

> PrinterAbstract<<initialize causes an assertion failure in this bit
> of code under Windows 98:

I can't see anything obvious at the moment.  Can you insert the following
just befor the #assert so that we can see what the error is ...

err := ComDlgLibrary default commDlgExtendedError

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Ian Bartholomew" <[hidden email]> wrote in message
news:ck_vc.10748$[hidden email]...
> > PrinterAbstract<<initialize causes an assertion failure in this bit
> > of code under Windows 98:
>
> I can't see anything obvious at the moment.  Can you insert the following
> just befor the #assert so that we can see what the error is ...
>
> err := ComDlgLibrary default commDlgExtendedError
>

The error it returns is 4104. Which looks to be: PDERR_NODEFAULTPRN = &H1008
"The function could not find a default printer." Which means that I'm a
dope!  I had been using the Windows 98 VM to test my application.  Since I
never had to print I apparently never added a printer, hence the error
above.  After I added a printer to the OS the preview works great in Windows
98.  Sorry about that Ian.

Chris

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
> > Additionally when I try to use a RichTextEdit2 (version 2 on Windows
> > XP SP1) the print preview seems to enter an endless loop in
> > RichTextEdit<<printerPrintPage:on:preview: in [range cpMin < range
> > cpMax] whileTrue: [...].
>
> OK, this is down to the big problem that I had with my original attempts
to
> replace the RichTextEdit class with a wrapper for the later RTE versions.
> The original uses cr-lf line delimiters and all the later ones (from RTE
2.0
> onwards) just use a cr.  This means problems for anything that has to know
> the exact number of characters in the control.  To get round it you will
> need to ....

After making the changes you suggested it works perfectly.  Thanks!  The
interesting thing is that I used to be able to use the RTE2 with version 5b
(August 2002) of your Printer package without additional changes.  I guess
the formatting strategy was changed in between that version and the latest
version.

Chris

Chris,

[combined reply]

> After making the changes you suggested it works perfectly.  Thanks!
> The interesting thing is that I used to be able to use the RTE2 with
> version 5b (August 2002) of your Printer package without additional
> changes.  I guess the formatting strategy was changed in between that
> version and the latest version.

To be honest I can't remember how the earlier versions worked and I'm sure
there have been a lot of changes since then - mainly because I understand
(to some extent anyway) a bit more about what is happening.  The structure
and message I mentioned yesterday aren't available in the original RichEdit
(version 1.0) so I may have included a workaround in the earlier versions of
the printer goodies?

> The error it returns is 4104. Which looks to be: PDERR_NODEFAULTPRN =
> &H1008 "The function could not find a default printer."

Yes, that would probably cause a problem :-)  Thanks for tracking it down.
I'll change the #assert to a "proper" error that includes the error number
(and possibly description) which should make thing easier in the future.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

"Christopher J. Demers" <[hidden email]> wrote in
message news:[hidden email]...
[Re: Determining the version of RichEdit20 DLL]

> Something like the code bellow might work for that.  Interestingly, what
> productVersion returns does not seem to jibe with what I see in the
windows
> properties dialog for the file.  The properties dialog say the "Product
> Version" is 3.0, but Dolphin says it is 5.0.0.0.  I am not sure if this is
a
> bug or what.  BTW I am using XP SP1.
> ===========
> v := VersionInfo forPath: SessionManager current systemDirectory ,
> '\RICHED20.DLL'.
> v productVersionString.
> v fileVersionString .
> ===========
>

A Windows VersionInfo resource typically contains the file and product
versions twice, once as "named" values, once in the so-called "fixed"
information structure. Unfortunately, and somewhat inevitably, these version
numbers do not always tally. The standard Dolphin VersionInfo accessor
methods you are using in your example used the information from the "fixed"
info because the other values are not required to be present. Windows
Explorer's file property dialog typically shows the both file versions - it
displays the fixed File Version at the top of the dialog, and lists all the
available named values from the resource in the listbox at the bottom. It
doesn't show the product version from the fixed info, so you'll only see
this if it is one of the named values, and of course that may not match the
fixed info. To get at any named value in the resource the VersionInfo class
defines a #at: method, e.g.

    v at: 'ProductVersion'

Which I think you will find will show the same value as you see in the
Windows dialog.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:[hidden email]...
> "Christopher J. Demers" <[hidden email]> wrote in
> message news:[hidden email]...
...
>A Windows VersionInfo resource typically contains the file and product
> versions twice, once as "named" values, once in the so-called "fixed"
> information structure. Unfortunately, and somewhat inevitably, these
version
> numbers do not always tally. The standard Dolphin VersionInfo accessor
> methods you are using in your example used the information from the
"fixed"
...
> fixed info. To get at any named value in the resource the VersionInfo
class
> defines a #at: method, e.g.
>
>     v at: 'ProductVersion'
>
> Which I think you will find will show the same value as you see in the
> Windows dialog.

Yes, that does get the value that Windows shows.  Thanks for explaining
this.

Chris