Prev: Windows 7 Compliance: VB6 and Adhering to REstart Manager messages
Next: Poooooor Fred...
From: Mike Williams on 17 Jun 2010 18:08
"Shotgun Thom" <tmoran4511(a)gmail.com> wrote in message
news:8ddc34e9-af22-43f5-85cb-13feac34ffcb(a)x27g2000prf.googlegroups.com...

Further to the response I've just posted, I think there is something else I
need to add, just to clarify things a little for you. In your own response
you said, "When calling these methods we actually do pass the Printer.hDC to
the control but it seems to have no impact on the settings".

I my own response to that statement I said that you should instead pass the
hDC returned by the printer dialog in the code I posted, which should work
okay for you because that hDC is fully modified by all the user's selections
in the dialog. However, in view of what you said, I think I should also make
a few comments regarding your act of passing the printer Object's hDC, and
explain to you in more detail why that particular method would in fact not
work.

As far as your VB code is concerned, regardless of the state of the dialog's
PrinterDefault property, from WinXP onwards only the printer itself is
regarded as a "user setting", but its properties are not. In other words,
the act of the user changing the printer name in your dialog will change the
default printer for that user, but the act of him also changing various
properties of that printer will /not/change the default properties for that
printer for that user (does that make sense the way I have explained it?).
In Win98 the act of the user changing the printer and its properties in the
dialog would result in /all/ those changes being reflected in the default
printer, whereas in XP onwards only the default printer itself would change,
but none of its default properties

So, what happens when you present a printer dialog to the user is the actual
"default printer to use" gets changed, but none of its default properties do
(they all remain the same as they were before). That is why the various
options to deal with that problem, including the MS vbprndlg DLL, rely on
"reading" the changes made by the user in the dialog and then passing them
on to the VB Printer Object's own equivalent properties. If you did not do
that then when you used the VB Printer Object to print something it would go
to the correct printer okay, but it would use the pre-existing default
properties of that printer. (I've had quite a few glasses of wine tonight,
but hopefully I am still making sense?). And, of course, the printer dialog
does not itself have any properties for the esoteric settings you are
talking about, and even if it did do so the VB Printer Object could not
"eat" them.

The alternative method that I posted does not need to concern itself with
any of that stuff, because the dialog itself returns a DC for you and that
DC is set up by the user exactly in accordance with the printer he wants to
use and also in accordance with all the settings he has chosen for that
printer, including all of the esoteric setting we have been talking about.
Printing to that DC should work fine, because it has nothing whatsoever to
do with the VB printer Object's hDC.

Have I helped at all in that supplementary explanation, or have I perhaps
just "muddied the waters"? (I must confess that I'm slightly inebriated at
the moment!).

Anyway, if you do what I suggested in my previous response then you should
be okay (although I've never heard of and never used your TxText Control and
so I cannot be absolutely certain of that).

Mike




From: Shotgun Thom on 18 Jun 2010 01:29
On Jun 17, 3:08 pm, "Mike Williams" <M...(a)WhiskeyAndCoke.com> wrote:
> "Shotgun Thom" <tmoran4...(a)gmail.com> wrote in message
>
> news:8ddc34e9-af22-43f5-85cb-13feac34ffcb(a)x27g2000prf.googlegroups.com...
>
> Further to the response I've just posted, I think there is something else I
> need to add, just to clarify things a little for you. In your own response
> you said, "When calling these methods we actually do pass the Printer.hDC to
> the control but it seems to have no impact on the settings".
>
> I my own response to that statement I said that you should instead pass the
> hDC returned  by the printer dialog in the code I posted, which should work
> okay for you because that hDC is fully modified by all the user's selections
> in the dialog. However, in view of what you said, I think I should also make
> a few comments regarding your act of passing the printer Object's hDC, and
> explain to you in more detail why that particular method would in fact not
> work.
>
> As far as your VB code is concerned, regardless of the state of the dialog's
> PrinterDefault property, from WinXP onwards only the printer itself is
> regarded as a "user setting", but its properties are not. In other words,
> the act of the user changing the printer name in your dialog will change the
> default printer for that user, but the act of him also changing various
> properties of that printer will /not/change the default properties for that
> printer for that user (does that make sense the way I have explained it?)..
> In Win98 the act of the user changing the printer and its properties in the
> dialog would result in /all/ those changes being reflected in the default
> printer, whereas in XP onwards only the default printer itself would change,
> but none of its default properties
>
> So, what happens when you present a printer dialog to the user is the actual
> "default printer to use" gets changed, but none of its default properties do
> (they all remain the same as they were before). That is why the various
> options to deal with that problem, including the MS vbprndlg DLL, rely on
> "reading" the changes made by the user in the dialog and then passing them
> on to the VB Printer Object's own equivalent properties. If you did not do
> that then when you used the VB Printer Object to print something it would go
> to the correct printer okay, but it would use the pre-existing default
> properties of that printer. (I've had quite a few glasses of wine tonight,
> but hopefully I am still making sense?). And, of course, the printer dialog
> does not itself have any properties for the esoteric settings you are
> talking about, and even if it did do so the VB Printer Object could not
> "eat" them.
>
> The alternative method that I posted does not need to concern itself with
> any of that stuff, because the dialog itself returns a DC for you and that
> DC is set up by the user exactly in accordance with the printer he wants to
> use and also in accordance with all the settings he has chosen for that
> printer, including all of the esoteric setting we have been talking about..
> Printing to that DC should work fine, because it has nothing whatsoever to
> do with the VB printer Object's hDC.
>
> Have I helped at all in that supplementary explanation, or have I perhaps
> just "muddied the waters"? (I must confess that I'm slightly inebriated at
> the moment!).
>
> Anyway, if you do what I suggested in my previous response then you should
> be okay (although I've never heard of and never used your TxText Control and
> so I cannot be absolutely certain of that).
>
> Mike

I think I understand, and I believe that's what I'm doing with the
TxText Control. The control has a property which must be set before
printing. TXTextControl1.PrintDevice = Printer.hDC

I obtain that hDC by setting the cdlPDReturnDC flag in the
vbprndlg.dll print dialog. I believe the DC then get's set in the
Printer.hDC property (at least according to MS help docs). It's then
passed to the control. It selects the correct printer but only passes
the defaults.

Isn't that the same DC as I would get using your code?

API Printing is not practical with the TxTextControl. It has highly
specialized formatting, style sheets, formats in .doc,
docx, .rtf, .html, xml and so forth. There are MS merge and mail
merge fields, Columns, PDF printing, etc. Text boxes, floating
images... very much like Word.

Tom
From: Mike Williams on 18 Jun 2010 02:09
"Shotgun Thom" <tmoran4511(a)gmail.com> wrote in message
news:8ddc34e9-af22-43f5-85cb-13feac34ffcb(a)x27g2000prf.googlegroups.com...

> The problem with the Konica client is that we are using the
> TxText control, which has two internal print routines. A
> print page method and a print doc method. When calling
> these methods we actually do pass the Printer.hDC to the
> control. However, it seems to have no impact on the . . .

Looking again at what I wrote in my last couple of responses there may be
something I didn't make quite clear, mostly because of my old habit of
sometimes using "non standard" naming conventions. When I said you should
pass the hDC that my sample code returns to the TxText control I meant the
handle that it picks up from the CommonDialog property and that it dumps
into the MyPrinter (PrinterInfo) UDT, so if you're using my code, or an
extract from it, then you should pass MyPrinter.Handle to the TxText
control.

Having said that, the code I posted was intended to show how you can do the
things you have asked for (pick up /all/ the user's printer dialog settings,
including the special settings) and how you can draw stuff to the selected
printer (text, boxes, graphics etc) using the standard GDI printing and
drawing functions. If (as it now appears) you are drawing the entire
document using /only/ the functions exposed by the TxTextControl, which
apparently requires you to pass it the selected printer's hDC, then you
will not need most of the GDI code in the example I posted.

If the above is the case then you can much more simply use just a standard
CommonDialog Control which you use in the normal VB way without all the
extra GDI code I posted and when the user has finished with the dialog you
can pass the Common Dialog's hDC property to the TxText control. This hDC
property will be the DC of the printer selected by the user and it will be
set up with /all/ of the settings selected by the user in the dialog,
including all of those esoteric and otherwise hard to get at properties.
This will require you to use much less code. The important thing is that
when using the CommonDialog control you should set its Printerdefault
property to False and should include at least the cdlPDReturnDC flag in the
Common Dialog's Flags property.

Mike









From: Mike Williams on 18 Jun 2010 02:36
"Shotgun Thom" <tmoran4511(a)gmail.com> wrote in message
news:90a325b5-c6cd-484a-a811-93cead96a773(a)a16g2000prg.googlegroups.com...

> I think I understand, and I believe that's what I'm doing
> with the TxText Control. The control has a property
> which must be set before printing . . .
> TXTextControl1.PrintDevice = Printer.hDC
> I obtain that hDC by setting the cdlPDReturnDC flag in
> the vbprndlg.dll print dialog. I believe the DC then get's
> set in the Printer.hDC property (at least according to
> MS help docs).

Well I don't ever use the MS vbprndlg.dll myself but I have written code
that uses it in the past, just out of curiosity, and I'm fairly certain
that's not the way it works. If the MS help docs say that the vbprndlg
returned DC gets set in the VB Printer.hDC property then they are wrong, or
perhaps you have misread them? MS have always been rusbbish at writing help
files! What you need to pass to the TxText Control in that specific case is
the prnDlg.hDC property, not the VB Printer.hDC property. Coincidentally I
had just posted an other response just minutes before I saw this one come in
from you, which explained how to do the same thing using just the standard
VB CommonDialog Control. Either of those methods should work for you.

Mike




First  |  Prev  | 
Pages: 1 2 3
Prev: Windows 7 Compliance: VB6 and Adhering to REstart Manager messages
Next: Poooooor Fred...