common dialog setting defaults for other VB6 programs?

[Eduardo]

I tried the following:

I added a common dialog dlg1

on form load:

dlg1.ShowPrinter

Printer.Print "A"
Printer.EndDoc

In the dialog that appears, there is a checkbox "Print to a file", I checked
it.
I pressed OK.

A small window (like an inputbox) appeared asking to set a file path (I
cancelled it)

I removed the common dialog

I in the form load just left:

Printer.Print "A"
Printer.EndDoc

Run.
Again the window asking for a file path.

I closed the IDE and opened it again, again in the form load:

Printer.Print "A"
Printer.EndDoc

The same window appeared.

Compiled project1.exe, the same, project2.exe, the same.
Only if I show the common dialog again and do not select "Print to a file"
and click OK, then it goes back to normal.

At the same time, I tried printing from other programs and that window
didn't appear.

???

[Eduardo]

The same happens if you select another printer than the default printer, the
common dialog changes the default printer for the entire system. That's
crazy.

I tested it with the common dialog that comes with VB.

[Deanna Earley]

Did you try disabling the controls "PrinterDefault" property?

--
Deanna Earley (dee.e...@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the
group.)

[Eduardo]

"Deanna Earley" <dee.e...@icode.co.uk> escribió en el mensaje
news:k43s3j$94g$1...@speranza.aioe.org...

>
> Did you try disabling the controls "PrinterDefault" property?

OK, I see that it doesn't change the printer default then, but I don't see a
way (a property) to know what printer the user has selected in the dialog.

[David Youngblood]

"Eduardo" <m...@mm.com> wrote in message...
>
> "Deanna Earley" <dee.e...@icode.co.uk> escribió en el mensaje...

>>
>> Did you try disabling the controls "PrinterDefault" property?
>
> OK, I see that it doesn't change the printer default then, but I don't see
> a way (a property) to know what printer the user has selected in the
> dialog.
>

MS made a replacement because of this. I've never used it. I use the API to
call the dialog.

http://support.microsoft.com/kb/322710

[Eduardo]

"David Youngblood" <d...@flash.net> escribió en el mensaje
news:k44217$i5d$1...@dont-email.me...

Thanks for the info.
I'm planning to use the API also, I just used the common dialog control for
performing quick tests, but couldn't believe it was so dumb.

[Mike Williams]

"Eduardo" wrote in message news:k43spv$b8o$1...@speranza.aioe.org...

In my opinion, the best way to solve this problem and also the other
problems mentioned in your other thread (Big Issue with Print Dialog
Options) is to ditch the VB Printer Object altogether and instead print your
stuff using API methods (StartDoc, StartPage, EndPage, EndDoc and all the
API drawing and text printing methods that go in between).

The cause of most of your problems is not the VB CommonDialog Control itself
but rather the fact that there are a lot of properties that it does not
expose to your code (although it does of course expose them to the user),
coupled with the fact that even if it exposed everything to your code you
are still left with the fact that the VB printer Object itself cannot "eat"
many of them, and you would be left with that latter problem of the VB
Printer Object being unable to "eat" stuff even if you used an API dialog.
Also, for certain printers there are various special printer properties that
are not even exposed by the API printer dialog (what I mean is that they are
exposed to the user for selection, but your code cannot effectively "get at
them" by examining the data because they are buried in the Extra section of
the Devmode in a way that only the printer driver itself understands), so
even if the VB Printer Object understood such things (which it does not) you
could not pass then to the Printer Object because you cannot get them in any
meaningful way from the dialog's data.

However, If you print to the dialog's returned DC using API printing methods
then your user can properly select anything at all that is available
anywhere in the dialog, including all those things that are buried in the
Extras section. If you use API printing methods instead of the VB Printer
Object then it doesn't really matter a great deal whether you display the
dialog using the VB Common Dialog Control or the equivalent API print dialog
methods because in both cases it is the dialog itself which sets up the
print DC for you in accordance with the choices made by the user in the
dialog. All you need to do is show the dialog and then print to the DC it
returns (using StartDoc, StartPage etc). If you use the VB CommonDialog
Control then make sure you set its PrinterDefault property to False and also
make sure you include the cdlPDReturnDC flag in its Flags property, along
with any other flags you wish to use. Then print your stuff to the
CommonDialog Control's hDC property.

I know this means a significant rewrite of your current VB Printer Object
printing code, but in my opinion it is well worth the effort.

Mike

[Mike Williams]

"David Youngblood" wrote in message news:k44217$i5d$1...@dont-email.me...

> MS made a replacement because of this. I've never used it. I use
> the API to call the dialog.
>
> http://support.microsoft.com/kb/322710

The only problem with that, and also with API dialogs, is that you are still
left with the problem of the VB Printer Object being unable to "eat" many of
the properties that are available. In my opinion the best way is to ditch
the VB Printer Object and print using API methods instead.

Mike

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje
news:k445q9$8vr$1...@dont-email.me...

> The cause of most of your problems is not the VB CommonDialog Control
> itself but rather the fact that there are a lot of properties that it does
> not expose to your code (although it does of course expose them to the
> user), coupled with the fact that even if it exposed everything to your
> code you are still left with the fact that the VB printer Object itself
> cannot "eat" many of them, and you would be left with that latter problem
> of the VB Printer Object being unable to "eat" stuff even if you used an
> API dialog.

[...]

> However, If you print to the dialog's returned DC using API printing
> methods

[...]

> Control then make sure you set its PrinterDefault property to False and
> also make sure you include the cdlPDReturnDC flag in its Flags property,
> along with any other flags you wish to use. Then print your stuff to the
> CommonDialog Control's hDC property.
>
> I know this means a significant rewrite of your current VB Printer Object
> printing code, but in my opinion it is well worth the effort.

I'm in a good moment for doing this, because I need to rewrite the entire
printing routine because of other reasons.

Mike, could you mention a couple of the features that are not available in
the printer object?
At the time I mainly have noted two things available in the dialogs that I
can not access (what the user selected) and that also would require a huge
extra work to implement in the case that I could get them: as mentioned in
my other thread: pages ascending/descending and pages per sheet (or
something like that, I'm translating from Spanish and guessing what it could
say in English). These two settings are accessed from the button
"Preferences" of the print dialog you can see them from Notepad print menu).

But as I explained in my reply to DaveO in my other thread, I'm still stuck
with a design dilemma, because I need to offer more than one dialog, at
least three:
1) Page setup dialog.
2) Formatting options (that's particular options for selecting some
formatting of the report offered by my program).
3) Print dialog.
and perhaps a 4): print preview.

I'm not sure if I'll implement print preview now, but I want to make the new
printing routine ready for implementing that in the future. Otherwise I'll
have to rewrite the entire printing routine again later when I decide to add
print preview (perhaps in a new version of the program).

To make available to the user to select what pages to print (or not to
print) is also an issue, because the printing routine needs to "pre-print"
or scan all what is going to print without actually printing anything, to
know where each page starts and ends.
Doing that, I'm closer to be able to implement also the print preview
feature.

Returning to the dialog issue:
I believe that it must be one dialog that appears from a single button in
the toolbar, the print button.
The way I want it to work is: the user clicks the "Print" icon, a dialog
appears (just one dialog window), if the user don't want to modify anything
just clicking a button (a "print" button or an "OK" button) must print the
report with the default settings (most of the settings -or all them- will
be the settings that were selected for the last report, and if it's the
first time the user prints a report, then they will be default settings).

I mean, just one toolbar icon, and just one click in the dialog to start to
print.
But... I still want to make available for the user to customize 1) Page
setup (margins) , 2) Formatting options particular of my program (font
sizes, lines, etc), and 3) Printer options (printer device, paper,
color/monochrome, etc) if the user wants to.

But, I would end with a dialog with three buttons: "Page setup", "Formatting
options" and "Select printer options", and two more buttons at the bottom:
"Print" and "Cancel".
I think it's an ugly design, at least I should offer something there, like
to select the Printer device.

Besides, the button of the printing common dialog 3) says "Print", not "OK",
so after this dialog, the user will expect to print directly, not to return
to the main dialog after selecting the printer, paper, color mode, etc.

I have made a dialog form for selecting all the options in just one dialog,
it is half done already, but I started to think that may be not a good idea
to make such a custom dialog, different to what all the other programs use.

What do you think?

Thanks.

[Eduardo]

"Eduardo" <m...@mm.com> escribió en el mensaje
news:k453a5$i8c$1...@speranza.aioe.org...

I made some decisions: I added an icon to the toolbar, the "Print preview".
The "Print" icon will show the standard Print dialog (I'm planning to use
the API based one), the "Print preview" will open the print preview screen
(I'm forced to implement this now). The page setup screen will be available
only from the Print preview screen.
The page setup screen, won't be the standard one, but a custom one where
I'll include the formatting options.

It will work very much like any other program does. Firefox displays a
custom page setup screen also.

Now I'll start to work on the Print preview form.

I still didn't decide about using the Printer object or the hdc returned by
the common dialog, but I'll need an hdc before the common dialog is
displayed because I need to measure some heights of texts that I need to do
with:

Call DrawText(hdc, nText, ByVal Len(nText), iRect, iAlingment Or DT_CALCRECT
Or DT_WORDBREAK)

I need to measure the texts in order to know where the pages break to be
able to show the print preview.

[Mike Williams]

"Eduardo" <m...@mm.com> wrote in message
news:k453a5$i8c$1...@speranza.aioe.org...

>
> Mike, could you mention a couple of the features that are
> not available in the printer object? At the time I mainly have
> noted two things available in the dialogs that I can not access
> (what the user selected) and that also would require a huge extra work to
> implement in the case that I could get them:
> as mentioned in my other thread: pages ascending/descending
> and pages per sheet

It depends on the printer. Some of them may be important to you and others
may not, depending on the nature of your application and on what you are
printing. There are the pages per sheet and page order settings you have
already mentioned, and there are often various duplex settings that are not
covered by those available in the Printer.Duplex property (from memory
things to do with different binding options). There are also the borderless
and the minimize margins settings (some printers have one or the other and
some have neither and some have both). Then there are various photo printing
options and also options for printing on special coated paper that are not
covered by the normal Printer.PrintQuality settings. That's not an
exhaustive list but I think it covers the majority of them. Additionally
there will often be settings which are special to a specific printer. For
example, I once had a printer that would print using the typical standard
CMYK colours but it was also capable of printing both in metallic silver and
metallic gold, something which the user could select in the Print dialog but
which of course the VB Printer Object knows nothing about. The only way the
VB printer Object could print metallic gold on that printer is by the user
having metallic gold set as the default setting in Control Panel, which of
course would not usually be the case. Other printers will probably have
other special options, depending on the printer. You can easily do those
things by displaying a printer dialog though and by printing to the returned
hDC using standard API printing methods.

Mike

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k46oak$chs$1...@dont-email.me...

The pages ascending/descending and pages per sheet is something that I can
see in (any?) two printers that I have installed (one PDF Writer and one
normal printer). They can be accessed from the Preferences button of the
print dialog. I don't see many other options there.
If these two options are made available to the user to select, I should do
something with it, or otherwise be able to hide the options.

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k46oak$chs$1...@dont-email.me...

> depending on the nature of your application and on what you are printing.

They are reports, just texts and lines, and some background color for the
headers.

[Eduardo]

I have the print preview window designed, now I need to start to write code.
It's an array of pictureboxes to show the pages.

My idea is to print the full report to some DC, may be a hidden picturebox
or a memory DC (may be all the pages in one DC or one DC per page), and then
copy the image to the pictureboxes of the print preview in the right scale
according to the zoom that the user is previewing (or the number of pages at
the same time on the screen). Perhaps I'll need to stretch the images with
something better than StrechBlt, but I know there are some functions for
scaling images with better quality (although they could be slow).

But now, I need to select the proper DC for doing that. What do you suggest?
I'll call DrawText with DT_CALCRECT to break texts in lines, but the breaks
and sizes must be the same of the final printing...

[Schmidt]

Am 29.09.2012 15:22, schrieb Eduardo:
> I have the print preview window designed, now I need to start to write code.
> It's an array of pictureboxes to show the pages.

Don't do that, if you expect more than two or three Pages,
because it can get pretty memory-intensive otherwise.
(since for a PrintPreview to look good, a certain "oversizing"
of the Bitmap about ot be "Stretched down" is usually helpful).

In my Print-Previews I use only one single oversized Bitmap
(for the currently displayed page) or max. two of them (in
case you want to allow for a side-by-side-view of two pages)
and then I render the current Page always live (against the
oversided Bitmap, followed by a quality-stretch-down to the screen).

If you want to pre-render *all* you pages beforehand instead
(before you switch to the PrintPreview) - then by all means render
them to MetaFiles (one MetaFileHandle per Page).

This way you would end up not with an array of large PictureBoxes
(or Bitmaps) for all your pages in the report, but with an
Array of Metafile-Handles (a MetaFileHandle is a Long-Value,
and the content-behind-that-handle are only "accumulated GDI-
commands and their parameters").

Rendering from a Metafile-Handle to this one single oversized
PagePreview-Bitmap can be done in only one API-call (PlayEnhMetaFile).
After that you will only have to blit the oversized BackBuffer
with HalfTone-Stretch to the final 'screensized' PagePreview-PictureBox
on your Preview-Form.

> I'll call DrawText with DT_CALCRECT to break texts in lines,
> but the breaks and sizes must be the same of the final printing...

Then you should definitely go with the MetaFile-Handles-per-page
approach, because Metafiles are the only way to guarantee the
same Output of wordwrapped text "on screen" and "on printer"
(other than printing every page onto a huge Bitmap in Printer-resolution
and blitting this thing directly to the Printer - but on PDF-Printers
you would loose the "Text-Information" this way, meaning Text would
not be selectable or copyable in the PDF-Reader).

The whole MetaFile-Reporting/PagePreview approach is already wrapped
in nice Classes in my RichClient-Tooslet (already in the older versions
which didn't integrate cairo yet). There's a cReportDocument-Class
(which aggregates all EMF-based pages - and can remove/add new ones
add any position you want) - and a cReportPage-Class (its ChildClass)
which wrap a Metafile-Handle each - and allows all kind of Drawing-
Routines against it (DrawText among them) - just in case you don't
want to fiddle with the MetaFile-APIs and all the proper GDI-Calls
(Handle-Selection/Destroying) on your own - the Classes all clean up
their internal stuff properly on Class_Terminate.

The final rendering of one (or all) of these MetaFile-Handle based
cReportPage-instances (aggregated in cReportDocument) can be done
either against a Screen-hDC, but also against a "naked Printer-hDC"
(so it complies with the requirements Mike pointed out before,
when you use the API to retrieve a printers hDC over the appropr.
enhanced settings of the Printer-Dialogue).

Here's a small simplified Demo (contributed by Wolfgang Wolf):
www.datenhaus.de/Downloads/SimpleMetaReports.zip (4.5KB)

Olaf

[Eduardo]

"Schmidt" <s...@online.de> escribi� en el mensaje
news:k47624$v2f$1...@dont-email.me...

>
> Here's a small simplified Demo (contributed by Wolfgang Wolf):
> www.datenhaus.de/Downloads/SimpleMetaReports.zip (4.5KB)

Thanks Olaf, I will study it... but now I have to sleep.

[Eduardo]

"Schmidt" <s...@online.de> escribió en el mensaje
news:k47624$v2f$1...@dont-email.me...

> Then you should definitely go with the MetaFile-Handles-per-page
> approach, because Metafiles are the only way to guarantee the
> same Output of wordwrapped text "on screen" and "on printer"
> (other than printing every page onto a huge Bitmap in Printer-resolution
> and blitting this thing directly to the Printer - but on PDF-Printers
> you would loose the "Text-Information" this way, meaning Text would
> not be selectable or copyable in the PDF-Reader).

But the user can change the page size again from the print dialog, from the
advanced options...
I thought that I had to print the whole report again over the final hdc.

[Mike Williams]

"Eduardo" <m...@mm.com> wrote in message

news:k46sml$8e8$1...@speranza.aioe.org...

>
> I still didn't decide about using the Printer object or the hdc returned
> by the common dialog, but I'll need an hdc before the common dialog
> is displayed because I need to measure some heights of texts that I
> need to do with:
> Call DrawText(hdc, nText, ByVal Len(nText), iRect, iAlingment
> Or DT_CALCRECT Or DT_WORDBREAK)
> I need to measure the texts in order to know where the pages break

> to be able to show the print preview . . .

> My idea is to print the full report to some DC, may be a hidden
> picturebox or a memory DC (may be all the pages in one DC or one
> DC per page), and then copy the image to the pictureboxes of the

> print preview . . . Perhaps I'll need to stretch the images with

> something better than StrechBlt, but I know there are some functions

> for scaling images with better quality . . . But now, I need to

> select the proper DC for doing that. What do you suggest? I'll call
> DrawText with DT_CALCRECT to break texts in lines, but the breaks and
> sizes must be the same of the final printing...

If you are going to display a print dialog to the user which allows him to
select the printer he wants to use and to alter its various settings and if
you want the print job to then immediately be carried out (which of course
is the normal thing to do) then you cannot really create DC in advance which
accurately reflects those print dialog DC settings because you do not know
in advance which printer he is going to choose or how he is going to set it
up. So you will need to use any suitable DC to initially create your
document and then take steps later to make sure the document outputs in
exactly the same manner to the printer DC which the user eventually creates
by virtue of his selections in the print dialog.

You can create your initial DC (perhaps against a specific printer or
against the default printer, or you could use the Printer Object's DC) and
you can use that DC for your various measurements, but the values it returns
for the height and width of any specific piece of text at a specific font
name and size might be different than the values which would be returned by
the printer and settings that are eventually chosen by the user in the print
dialog. Even very small differences can cause line wraps to occur on a
different word, and they can thereby cause a block of text (drawn using
DrawTextEx for example) to use a different total number of lines, so your
print preview generated using the values returned by the DC you have created
in advance is quite likely to be different from the actual printout. You
could of course require the user to select his printer and its properties
before you display any print previews, but that is not the normal thing to
do.

It is actually possible to create a totally accurate print preview even
before the user selects the printer and its settings in the print dialog (MS
Word for example has no problem doing it), but it is not quite as
straightforward as it might at first appear, at least not if you want it
exact. MS Word does it by creating a DC before you start typing the document
(I'm not sure whether it uses a DC from the default printer or perhaps a
sort of "stock" DC which it creates itself in memory) and it lays out the
document in accordance with that DC. MS Word of course knows that the DC
which the user eventually creates (by his choice of printer and printer
settings in the print dialog) is quite likely to return different actual
sizes for the height and width of text and so instead of drawing the text in
accordance with the target DC it draws the text in accordance with the DC it
initially created (the one which it used to lay out the document and to
produce the print preview), and it deliberately positions each character on
the page in exactly the same location that it is in the displayed document
and in the print preview. A VB RichTextBox is capable of doing something
similar, laying out its contents in accordance with a reference DC but
actually drawing them into a different target DC, but I don't think that
would suit your needs.

Doing a similar thing in VB would take a bit of work to cover all the bases
and to do it really accurately, but it can be done. For example you could
draw a text string representing a paragraph into your own created DC (which
you are currently doing with the DrawText API) and keep a record of the
words (character positions) at which each line wrapped and also a record of
the actual height of a line. (You might need to write your own wrapping code
to do this, or you could do it with a bit of judicious juggling with the
DrawTextEx function and DrawTextParams). Then when that same paragraph gets
drawn into the output printer you draw each line one at a time at the
appropriate positions. In that way the block of text will "wrap" at the same
words it wrapped in your own DC and in your print preview.

You would actually need to do a bit more than that though because the line
endings on the printout would quite likely not be in the same exact position
as they were on the "stock DC", and it is even possible that some lines
might run into some other object on the page when they did not do so in the
stock DC. So, you would really need to not only draw each specific line of
text as previously explained, but you would also need to draw every single
character of each line in exactly the same character position on the printed
page. If you look at a printout from an MS Word document for example then
you'll find that's what MS Word does. For this you would probably need to
use the ExtTextOut function which allows you to pass the string to print
together with an array of values which specify the exact required spacing
between each character and the next. All this would take a bit of work to
get right, but it can be done.

One method I have used myself in cases where I want the output on the
printer (any printer, regardless of its characteristics) to exactly match
the output on the display and also to exactly match the output in any
preview window is to draw all my stuff to an enhanced metafile DC (I think I
used one metafile for each page, it is a while ago now and I'm not quite
sure offhand). This would avoid all the above complications about logging
word wrap positions and character positions and other stuff (although of
course it introduces complications of its own because you need to get your
head around writing to a metafile, but I can help you with that). You then
just use all the normal DrawText and other methods in the normal way to
create your page(s), but you use them on the metafile DC. The metafile then
effectively contains the full contents of perhaps an A4 or US Letter Size
page. Then when the time comes to print the page (when the user makes his
various selections in the print dialog) you simply dump the metafile to the
printer (one per page) using a simple one line PaintPicture. You don't need
to worry about the stuff I have mentioned above, because the metafile will
automatically make sure that all the lines wrap at exactly the same point
and that they are all correctly spaced and it will even ensure that all the
characters on each line are exactly in the correct position, regardless of
the device you draw the metafile to. With this method a simple PaintPicture
can draw the metafile onto the user's printer page, or onto your main Form
or whatever, or into a PictureBox of any size you desire, and it will
automatically use the exact correct font sizes and line wraps and all the
other stuff, so that each page will look the same wherever you draw it.
Also, because it is a metafile (rather than a bitmap image which your
previous suggestion would produce) you always get a good quality output
because it uses the full resolution of whatever device you are drawing it
to, whether that is a 96 dpi PictureBox or a 600 dpi printer. It might not
be the way you want to go, but it is worth thinking about

Anyway, I'm sure other people have their own ways of doing these things and
that others will probably give you all sorts of other possibilities, so the
above things are just suggestions really for you to mull over and consider.

Mike

[Mike Williams]

"Mike Williams" <Mi...@WhiskyAndCoke.com> wrote in message
news:k47902$hd5$1...@dont-email.me...

> . . . lots of stuff about printing and previews

Sorry, in my last message I said to play the metafile using PaintPicture
whereas of course you will be creating a memory metafile rather than a disk
file metafile and you will also be dealing with output DCs rather than
objects, so you would use the appropriate API function (PlayEnhMetafile) to
play it to a DC rather than using PicBox.PaintPicture or
Printer.PaintPicture. Same principle, though, and still just a one liner.

Mike

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k47902$hd5$1...@dont-email.me...
[...]

> It is actually possible to create a totally accurate print preview even
> before the user selects the printer and its settings in the print dialog

[...]

> A VB RichTextBox is capable of doing something similar, laying out its
> contents in accordance with a reference DC but actually drawing them into
> a different target DC, but I don't think that would suit your needs.

I don't think so because I need to draw lines also.

> Doing a similar thing in VB would take a bit of work to cover all the
> bases and to do it really accurately, but it can be done. For example you
> could draw a text string representing a paragraph into your own created DC
> (which you are currently doing with the DrawText API) and keep a record of
> the words (character positions) at which each line wrapped and also a
> record of the actual height of a line. (You might need to write your own
> wrapping code to do this, or you could do it with a bit of judicious
> juggling with the DrawTextEx function and DrawTextParams).

Ummm. I've thoght about that, but I think that the API doesn't tell you were
the lines wrapped, it just print to the DC and you don't know the positions
and were the lines wrapped, you just know the final height (I need to study
this more in deep, but I think you cannot know that).

I'll have to write my own wrapping routine, that will be much slower.

[...]

> You would actually need to do a bit more than that though because the line
> endings on the printout would quite likely not be in the same exact
> position as they were on the "stock DC", and it is even possible that some
> lines might run into some other object on the page when they did not do so
> in the stock DC. So, you would really need to not only draw each specific
> line of text as previously explained, but you would also need to draw
> every single character of each line in exactly the same character position
> on the printed page.

It will be a lot slower.

> If you look at a printout from an MS Word document for example then you'll
> find that's what MS Word does. For this you would probably need to use the
> ExtTextOut function which allows you to pass the string to print together
> with an array of values which specify the exact required spacing between
> each character and the next. All this would take a bit of work to get
> right, but it can be done.

Almost any (professional or semi professional) program have print preview, I
didn't think it was so hard.
Or do most of the programs do it in the wrong way?

The way I wanted to go... I didn't take into account that I would have to do
all this, but if I have to...

I think the Metafile sound like the best option. Olaf also suggested this,
and posted a sample using his library.
I'll study it.

After your explanation (and also Olaf post), I'm already quite convinced
that the way to go is with metafiles.

> Anyway, I'm sure other people have their own ways of doing these things
> and that others will probably give you all sorts of other possibilities,
> so the above things are just suggestions really for you to mull over and
> consider.

Most of the times the user will go directly to print, not passing from the
print preview window.
But I guess that I could always write to the metafile first, right? I think
it will be easier for me doing that (for using the same routines).

One other "problem" is that if I want to set properly the "Max pages" for
the print dialog, I need to know how many pages the report will have before
showing the page dialog, but the printing to the metafile could take too
long time in cases of reports with many pages to do that before showing the
dialog, so I could set the Max pages to 1000...

Thanks.

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k479rp$mpp$1...@dont-email.me...

OK

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k479rp$mpp$1...@dont-email.me...

BTW I have been working with the print preview window design, it takes lot
of time to find good icons, edit them and produce a nice window with the
appropriate icons.

[Schmidt]

Am 29.09.2012 18:45, schrieb Eduardo:
> "Schmidt" <s...@online.de> escribi� en el mensaje

No, with the MetaFile-Approach (when using my Classes), these work
completely independent of the current Printer-hdc - the only
thing you will have to provide to these Metafile-Classes on
"creation time" is the Aspect-Ratio of your page, expressed by
some "virtual Page-Coords" you want to render your output against -
and if the current Meta-Page shall be Landscape or not.

The Ratio of "Paper-Pages" is usually the same over a whole
"group" - e.g. german A4-Format is 210x297millimeters and the
(twice as large) A3-Paper-Format is 297x420mm, having the same
aspect-ratio.

No matter what the "final destination will be" with regards to
the real Printer-Pagesize - you can render to a MetaFile-PageClass
with always the same "initially given virtual coords on creation time"
(e.g. treat this Meta-Page as if it was a page with the dimensions
of 210x297mm).


Later on, when printing-time comes, you can re-play the stored
MetaFile-content of each page to any current Page-Dimension
the Printer(hDC) tells you - just keep the Aspect-Ratio of
your page, when you calculate the final destination-rectangle
for the PlayEnhMetafile-call (wrapped in the cReportPage-Class
by its .RenderTo-method).

So the behaviour is so, that it is your *App-internal* "Document-
Size-Setting" which is reflected whilst rendering to the MetaPage-
Classes.
If this setting of the Document-Size for the Meta-Page was
initially A4=210x297mm - and later on this Document is rendered
to a Printer-Page which was selected larger (e.g. A3=297x420mm)
then the Document-Page is scaled to twice the size automatically
on the A3-PrinterOutput (filling the page completely).

So the whole thing can help to separate App-internal Document-
settings from the choice the user finally makes with the
PageSize over the Printer-Dialogue. These are two different
things - and if the user wants a larger page (which contains
more TextOutput per Page than with a smaller paper-format) - he has
to specify this in your App-internal Document-Size-Setting-Dialogue,
not in the Printer-Dialogue.
At least that's how the MetaClasses work - and are designed for
(app-internal Document-Size-Format - and app-internal Landscape-
settings per Page in the Report-Document).
This is somewhat similar to the behaviour of e.g. PowerPoint.
The PageOutput will finally always fill a complete Printer-Page,
no matter what Paper-Size was choosen in the Printer-Dialogue.

Olaf

[Mike Williams]

"Eduardo" wrote in message news:k47baf$c9d$1...@speranza.aioe.org...

>>>"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el
>>> mensaje news:k47902$hd5$1...@dont-email.me...

>>> (You might need to write your own wrapping code to do this,
>>> or you could do it with a bit of judicious juggling with the
>>> DrawTextEx function and DrawTextParams).

> Ummm. I've thought about that, but I think that the API doesn't tell you

> were the lines wrapped, it just print to the DC and you don't know the
> positions and were the lines wrapped, you just know the final height
> (I need to study this more in deep, but I think you cannot know that).

As I said in the post to which you have just responded, you can tell where
the line wrap occurred with a bit of judicious juggling with the DrawTextEx
function and DrawTextParams. Offhand I think you could draw the text with
DrawtextEx using DT_CalcRect and giving it a pointer to a DrawTextParams
structure and specifying a rectangle of the desired width but which is deep
enough to hold only one line of text. The DrawTextParams structure would
tell you how many characters were drawn, in other words where the wrap would
occur. Then you do the same with the remaining part of the string, etc.

> I'll have to write my own wrapping routine, that will be much slower.

Yes, as I also suggested you could write your own. It might be slower, but I
think you'd be surprised at how quick it would nevertheless be.

>>> You would actually need to do a bit more than that though because
>>> the line endings on the printout would quite likely not be in the same
>>> exact position as they were on the "stock DC", and it is even possible
>>> that some lines might run into some other object on the page when
>>> they did not do so in the stock DC. So, you would really need to not
>>> only draw each specific line of text as previously explained, but you
>>> would also need to draw every single character of each line in exactly
>>> the same character position on the printed page.

> It will be a lot slower.

Well yes it would of course be slower, but not perhaps as slow as you think.
You don't actually draw the characters by calling a draw method for each of
them. You just pass the entire line of text along with an array which
specified the placement of the characters in one call to the drawing
function. You do of course need to perform the calculations for the array
data, which of course would take some time, but you do get an exact
placement for every character in the string.

> Almost any (professional or semi professional) program have print
> preview, I didn't think it was so hard. Or do most of the programs
> do it in the wrong way?

No, they don't do it the wrong way. There are all sorts of ways of doing
almost any job. But you have said that you want the print preview to look
exactly the same as the actual printout, and you need to do that before the
user has selected the printer and selected its properties, and all
applications which do that need to use a significant amount of code. There
is no "magic bullet" which will do it for you without any code ;-)

> The way I wanted to go... I didn't take into account that I would
> have to do all this, but if I have to...

Well its up to you, but if you want what you said you want, which I
understand is line wraps at exactly the same word on each line and at
exactly the same page position, then you've got to do one of those things,
or use some other similar option. If you are happy with lines merely being
wrapped at the correct word and are not botherd about them also wrapping at
the same horizontal point on the page then it is easier because you will
then need to do /only/ the first thing in suggested, which is to draw the
stuff into your own DC or whatever and record the character position of the
wraps and then draw the individual lines one by one into the target device.

> I think the Metafile sound like the best option.

Yes, I do too, which is why I suggested it. In fact if you look back in the
archives of this group (or was it the c.l.b.v.m. group?) you will see a post
of mine maybe a year ago or more ago in which I posted some code of mine
which draws a page into an enhanced metafile and which draws it both to the
printer and to the Form. As I recall, there were some paragraphs of text and
a picture was drawn partially on top of it.The user can drag out the size of
the Form to any size he wants and the print preview will follow in real
time, and it will accurately represent the printed page no matter what size
you drag it to, and no matter what printer it was sent to. All the lines
wrap at the same word, and all the lines end at the same horizontal point on
the page and even the specific characters which are wholly or partially
visible at the four corners of the overlaid picture all stay exactly where
they are in relation to the picture, regardless of the preview size. Check
it out in the archives. If you cannot find it (and of course if you want
it?) then post again and I'll dig it out from my stuff at this end.

> Olaf also suggested this [a metafile], and posted

> a sample using his library. I'll study it.

Yes. taht would be a very good idea.

> After your explanation (and also Olaf post), I'm already
> quite convinced that the way to go is with metafiles.

Good, because it is the way I think I would go as well for your own
particular needs

> Most of the times the user will go directly to print, not passing from
> the print preview window. But I guess that I could always write to the
> metafile first, right? I think it will be easier for me doing that (for
> using the same routines).

Well, no. It is simpler than that. You write /only/ the metafile. The
metafile is in fact your document. When you want a preview (at any desired
size) you draw the metafile to a PictureBox or whatever. Then, when you want
a print, you draw /exactly the same metafile/ to the printer.

No time for any more now, so I'll skip your last question for the time
being. But I think you've got enough to go on, and you've got Olaf's code,
so you should be fine. Just let me know if you want my own metafile code as
well (if you cannot find it in the newsgroup archives).

Mike

[Mike Williams]

"Eduardo" wrote in message news:k47baf$c9d$1...@speranza.aioe.org...

> lost of questions about printing . . .

By the way, just a quickie, I noticed another question of your which I seems
to have missed previously (one which I see Olaf has just answered in respect
of his own metafile Classes). My own code which I posted a long time ago and
which I spoke about in my previous response can also be drawn at any size
you require. That's how metafiles work. You can draw them at whatever size
you want, either to a pictureBox for a preview or to a printer for real
output. Exactly the same metafile is capable of filling (or partially
filling if that is ever a requirement) an A4 page or an A5 page or even an
A3 or A2 page if you have such a sized printer. That is the nature of them.

Mike

[Eduardo]

"Schmidt" <s...@online.de> escribió en el mensaje

news:k47bkt$2bs$1...@dont-email.me...

> Am 29.09.2012 18:45, schrieb Eduardo:

>> "Schmidt" <s...@online.de> escribi? en el mensaje

>> news:k47624$v2f$1...@dont-email.me...
>>
>>> Then you should definitely go with the MetaFile-Handles-per-page
>>> approach, because Metafiles are the only way to guarantee the
>>> same Output of wordwrapped text "on screen" and "on printer"
>>> (other than printing every page onto a huge Bitmap in Printer-resolution
>>> and blitting this thing directly to the Printer - but on PDF-Printers
>>> you would loose the "Text-Information" this way, meaning Text would
>>> not be selectable or copyable in the PDF-Reader).
>>
>> But the user can change the page size again from the print dialog, from
>> the
>> advanced options...
>> I thought that I had to print the whole report again over the final hdc.
>
> No, with the MetaFile-Approach (when using my Classes), these work
> completely independent of the current Printer-hdc - the only
> thing you will have to provide to these Metafile-Classes on
> "creation time" is the Aspect-Ratio of your page, expressed by
> some "virtual Page-Coords" you want to render your output against -
> and if the current Meta-Page shall be Landscape or not.
>
> The Ratio of "Paper-Pages" is usually the same over a whole
> "group" - e.g. german A4-Format is 210x297millimeters and the
> (twice as large) A3-Paper-Format is 297x420mm, having the same
> aspect-ratio.

With some pages sizes the aspect ration will change, also if the user
decides to switch page Orientation the aspect ratio will change.

Here the two more common sizes are A4 (used 95% of the times) and Legal
(4~5%), and they have different aspect ratios.

>
> No matter what the "final destination will be" with regards to
> the real Printer-Pagesize - you can render to a MetaFile-PageClass
> with always the same "initially given virtual coords on creation time"
> (e.g. treat this Meta-Page as if it was a page with the dimensions
> of 210x297mm).

But that's not the usual thing to do with text. That feature can be useful
with photos.
With text, the normal thing is to use the page dimensions for printing more
text, not for making the letters bigger.

I'll explain more about what I'm trying to print in another message.

Thanks.

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k47lkd$1k1$1...@dont-email.me...

I criticized Olaf for suggesting that (to scale the page to another size),
but I opened Word and saw that it's what they do: in the print dialog they
offer "to scale" the page to another size.

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k47l46$u72$1...@dont-email.me...

> But you have said that you want the print preview to look exactly the same
> as the actual printout, and you need to do that before the user has
> selected the printer and selected its properties, and all applications
> which do that need to use a significant amount of code. There is no "magic
> bullet" which will do it for you without any code ;-)

[...]

> Well its up to you, but if you want what you said you want, which I
> understand is line wraps at exactly the same word on each line and at

> exactly the same page position...

I'm considering to change my mind about that.
I said that because I thought it was the ideal thing to do, but may not be
"a requirement".

I'll explain more the whole story, so you (I mean you, Olaf, or anyone else
who wants to comment) can give me suggestions on the actual situation.

I'm writing a program that I need to have finished quite soon and there are
still many things left to do (this printing issue wasn't even accounted
among the things left to be done).

In the program, I show the data in MSHFlexGrids.
I had a routine for printing grids from another program that I made before.
This routine directly writes a copy of the grid into the printer, it handles
to print properly each cell with their own properties, also it handles
MergeCells, and that feature at least worked well for the type of reports of
that other program.
Testing the routine with this new program I found some problem merging
columns when the page breaks in the middle of a merged column, something
that never happened in the other program.
Trying to fix that, I finished deleting everything. I wrote that routine
many years ago, and now I didn't like what I did before and decided to write
it again but "right".
That old routine had a basic scaling, I could set the scale and it would
change all the sizes, including the sizes of fonts (the grid always look
pretty much as it does on the screen).
But for this new routine I have another idea: if the grid width is larger
than the width of the page, my idea is to reduce the columns widths, but to
preserve the font size. Furthermore: I thought to offer the user in the page
setup window to be able to select to scale the fonts, so he can set the
fonts to 75%, 100%, 125%, 150% and 200%.
I thought to make also available to select whether to print or not the Rows
lines, Columns lines, outward borders of the grid, headers separator (when
the user selected not to print the Rows lines).
All those options were not available in my old routine, it just sent the
report right away to the printer and printed it like it was on the screen.
Of course the lines inside the cells will break different if the user
changed the font scale, that means that he changed the font sizes.

Thinking about the options, I thought it was the time to make it more
professional and to display the printer properties screen, aka the print
dialog.
But now I need to handle the options. If the user selected to print just
some pages and not the entire report (may be because his dog ate some pages
of a report he just printed, or the printer went out of paper and he
cancelled the task, or because he wants just the two first pages, or just
the last one, or whatever), I need to be able to do that.
From doing that, print preview was the next step.

As I saw that I had no way to display the page setup screen from the print
dialog (or to show the print preview from the print dialog), I had to add
another icon to the toolbar for the page setup, but it was too ugly to have
an icon just for the page setup, then I had to go ahead and add the print
preview feature, something that I didn't want to do now but I was forced to
do.
Doing that, the program looks and behave very much as "normal", because it's
what almost any program does in these situations.

It is no big deal if the render in the print preview is not exactly as it is
the printed one, if the pages breaks at different rows or the cells beaks
the texts at different words.
The user can't change the report very much in any case. He/She can change it
a bit changing the margins and the font scale, but I don't think he/she will
be disappointed if discovers that in the print preview the fist page broke
on row 30 and in the printed page it did on row 31.

It is pretty much a general purpose printing class for MSFlexGrids and
MSHFlexgrids.

Now knowing the real case, suggestions?
Is the metafile the best thing to go with?

Thank you!

[Mike Williams]

"Eduardo" <m...@mm.com> wrote in message

news:k47bke$d35$1...@speranza.aioe.org...

>
> BTW I have been working with the print preview window design,
> it takes lot of time to find good icons, edit them and produce a nice
> window with the appropriate icons.

Isn't that a little premature ;-)

Mike

[Mike Williams]

"Eduardo" <m...@mm.com> wrote in message

news:k485ms$8k1$1...@speranza.aioe.org...
>>>
>>> "Schmidt" <s...@online.de> escribió en el mensaje No matter what the

>>> "final destination will be" with regards
>>> to the real Printer-Pagesize - you can render to a MetaFile
>>> -PageClass with always the same "initially given virtual coords
>>> on creation time" (e.g. treat this Meta-Page as if it was a page
>>> with the dimensions of 210x297mm).
>
> But that's not the usual thing to do with text. That feature can be
> useful with photos. With text, the normal thing is to use the page
> dimensions for printing more text, not for making the letters bigger.

Olaf was explaining the general flexibility of metafiles to you with regard
to the fact that they can be rendered at any size you wish regardless of the
size at which they were created. Naturally, if you have a metafile which was
designed at one size and you print or display it at some other size then the
entire content of the metafile will expand or contract accordingly,
including any text it contains. Sometimes that is exactly what you want to
do, often with a metafile which represents an image or perhaps a table but
also sometimes even with a metafile which consists only of text.

The latter is in fact exactly what I wanted to do myself when I wrote my own
metafile code because I could very easily dump the metafile (which contained
only text) to an A5 page for a leaflet which I intended to laminate and
distribute to members of a club and I could just as easily dump it in
magnified form to an A4 page for any club member who required it (this is a
pensioners' club and many of them have poor eyesight) and I could easily do
so regardless of the printer currently in use whether it had its own scaling
properties or not.

But, despite your protestations ;-) Olaf was /not/ actually telling you that
you should do that in any specific case, merely that it can be done. In
other words, it is entirely suitable for displaying your print previews and
you can very easily display the preview any size you wish, and with a bit
more code you can allow the user to zoom into any specific section of the
preview, at virtually any magnification. And of course if the metafile was
created to represent an A4 page then you can just as easily dump the
metafile to an A4 page on the printer.

You will of course need to ensure that the RECT you supply to the
PlayEnhMetafile function represents the pixel size of the A4 page on the
printer which is currently in use, which can be different for different
printers (and for the same printer at different quality setting), and you
will need to offset all four values by a negative amount equivalent to
PhysicalOffsetX and PhysicalOffsetY of the printer currently in use, values
which of course are also different for different printers, but if you want
stuff positioned correctly on the page (as of course you do) then you always
need to account for PhysicalOffsetX and PhysicalOffsetY in your code no
matter how you perform your printout, even if you print standard strings of
text using the VB Printer Object.

As far as printing the document to a different page size is concerned (the
main point of your most recent remarks) then you have a choice. You can
either print the same metafile at the new page size and therefore produce a
magnified or a reduced size output (as you might want to do with images or
sometimes with tables and as I wanted to do with my 'text only' club
leaflet) or you can recreate the metafile at the new desired page size, in
which case you will fit more (or less) text on the metafile page depending
on the new required size. In fact I think Olaf has already mentioned
something similar to you in one of his previous posts. Essentially, if you
create a metafile as an A4 page then you should show any previews as an A4
page and you should print the metafile to an A4 page, unless the user at
some point changes the page size in either your page setup window or your
print preview window.

For your own specific requirements, and of course for most standard document
requirements, if you have created an A4 metafile and if the user at some
point changes the paper size to Legal in your page setup window or in your
print preview window then you need to dump the A4 size metafile (or hang
onto it for future possible use if you wish) and you need to create a new
Legal size metafile and recreate the page(s) of your document against the
new metafile. The new Legal size metafile then becomes the one which you
show in any print previews and the one which you eventually dump to the
printer. It is of course up to your user to make sure that he actually does
have Legal size paper in the printer. That's pretty much what MS Word does,
although of course it uses its own page creation mechanisms and not
metafiles.

I don't have Legal size paper here to perform any tests and the only paper
size I have is A4 so for test purposes I have just cut some A4 sheets in
half to produce a stack of A5 sheets and I inserted them into the printer.
Then I started up MS Word and set the page size to A5 and created a simple
A5 document. The MS Word print preview window of course showed the A5
document exactly as I had typed it and it printed in exactly the same layout
to the A5 page in the printer.

Then in MS Word I changed the page size to A4 under the page layout tab. MS
Word responded by immediately changing my view of the document to an A4 view
and my paragraphs of text consisted of very much longer text lines with the
word wraps at completely different points in the text and any previews
showed a copy of the new A4 page, exactly as you would of course expect. In
fact it had done exactly as I have described above in that it created a
completely new page for itself at the new A4 size using whatever internal
page creation mechanisms it uses (in our case we are using metafiles). The
A4 page of course printed out exactly as expected when I inserted A4 paper
into the printer.

Then I tried the same test again in MS Word, initially creating the same A5
document and printing it to A5 paper. This time I did not change the page
size in MS Word's page setup or print preview windows (as I had done before)
but I instead selected Print so that the standard print dialog popped up.
Then in the print dialog I changed to A4, making sure that there was A4
paper in the printer. MS Word clearly did /not/ create a new A4 page
(metafile in our case) because it printed the A5 page, looking exactly like
the A5 page as displayed in the MS Word main window and in the MS Word print
preview, but it shoved it into the top left corner of the A4 page, with all
the line wraps being at 'A5 positions' on the A4 page. In fact it was
effectively an A5 page stuck in the top left corner of an A4 piece of paper.

This is pretty much what I expected it to do under such circumstances.
Essentially, in your own application, you should do what I have mentioned
above (create a new Legal size metafile if the user started with an A4 page
and if he changed to Legal either in your page setup window or your print
preview window. This will cause your application to behave in exactly the
same way as MS Word behaves under similar circumstances. But if the user is
stupid enough to set up a document in A4 and then change to Legal or Letter
or A5 (or something else) only in the actual final print dialog then it's
his own daft fault!

Mike

[Mike Williams]

"Eduardo" <m...@mm.com> wrote in message

news:k48ajg$ht9$1...@speranza.aioe.org...
>
> Lots of stuff about print previews and printing . . .

By the way, here's a link to the code I posted a while ago. It was only
about three or four months ago, I thought it was longer than that. It's just
general testbed code but it should give you an idea of how the printout and
the print preview work in practice. Create the project as described in the
post and when you run it click the Form. Also try draging the Form to
various different sizes.

https://groups.google.com/group/microsoft.public.vb.general.discussion/browse_thread/thread/4d8cc6e4ce0c168c/722b7745322e811d?hl=en-GB&lnk=gst&q=metaDPIX+%3D+25.4#722b7745322e811d

Mike

[Schmidt]

Am 30.09.2012 03:23, schrieb Eduardo:
> "Mike Williams" <Mi...@WhiskyAndCoke.com> escribi� en el mensaje

As said (by Mike too) - MetaFiles can easily be stretched to any
(final) Page-Size the User finally selects in the real Printer-
Dialogue - or they can also be rendered "across multiple pages"
(if the Documentsize was defined larger in the Report than the
Printer-PageSize) - but they can also be printed PageTopLeft -
or PageCentered (when the original DocumentSize is smaller than
the PrinterPage-Size) - but you can also re-create the Report-
Page Document-Size according to the currently selected Printer-
Pagesize (the "fit more text into it" thingy).
But this "fit more text into it"-thing is IMO also a choice
at App-Runtime (before printing-time) - if the user thinks,
"this page needs to be Landscape-A3, so that I can have my
table-columns entirely fitting on the PageWidth" - then
he can do so at cReportPage-creation-time... and if such
a page is later on printed against the smaller A4 (with
scaledown) - then so be it - this smaller printer-page will
then contain the entire table (with smaller rendered Fonts).

But all this handling is entirely up to you - but I prefer to let
the User choose all these things without involving the Printer-Dialogue
(as App-internal and Printer-independent ReportPage-Settings).
So you can create a cReportPage with any Size- or Orientation-setting
without knowing about any Printers and "accumulate" all these Pages
within cReportDocument - and finally save this Document to a DBFile
as Blob (it supports serialization to ByteArrays) - but also saving
to Disk is possible of course. This way the Report-Document can
be "transferred" (treated like a PDF if you want) - to the place of
the final Printout - or just be stored for a Printout at a later time.

Long story short - Metafiles are extremely flexible - and they
keep your Textbreaks always "as rendered the first time" - no
matter how you scale them at a later time against any hDC you
choose.

As for your Grid-Printing - the cReportPage-Class supports a
DrawCell-Method which might come in handy in this regard (can
safe a few lines of code when you write your "Cell-Render-Loop".

Olaf

[Mike Williams]

"Mike Williams" <Mi...@WhiskyAndCoke.com> wrote in message

news:k49eub$js$1...@dont-email.me...

>>> "Eduardo" <m...@mm.com> wrote in message
>>> news:k48ajg$ht9$1...@speranza.aioe.org...
>>>
>>> Lots of stuff about print previews and printing . . .
>

> By the way, here's a link to the code I posted a while ago . . .

Incidentally, I've just noticed that in the code at the link I posted I
inadvertently used CLEARTYPE_COMPAT_QUALITY when creating the font whereas I
really intended to use CLEARTYPE_QUALITY. Because of this, the text in the
screen output does not have quite the quality it should have. There are also
a couple of other things, for example the code redraws the metafile on
screen at every Resize event, even if the actual size of the desired output
has not changed. If you do try the example then you should change to
CLEARTYPE_QUALITY to ensure you are seeing the screen output exactly as it
was intended, but the other things do not matter because it is after all
just testbed code. I'm afraid I'm not at all like Olaf Schmidt, who works
slavishly on all his projects, going completely without food and drink until
he has a polished and fully complete and totally flexible solution <g>. I
just continue with my code only until I am convinced that I have, or can get
to, a working solution and I leave it at that, ending up with a rather
'Heath Robinson' affair and leaving myself plenty of time for food and drink
. . . especially drink <g>

Mike

[Eduardo]

"Schmidt" <s...@online.de> escribió en el mensaje
news:k49h6j$d77$1...@dont-email.me...

> [printing stuff]

Hello Olaf, I tested your example using your library.
I'll check how to do it directly with API too.
Thanks.

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k49bud$flm$1...@dont-email.me...

Why premature?
Don't I need that window?
I need somewhere to show to me how my work in the routine is progressing,
and to see the results there could be more handy than printing pages (even
in a PDF writer).
In any case I need that window done, sooner or later.

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k49eub$js$1...@dont-email.me...

Thanks, I'll check that. I'll play with the code.

[Mike Williams]

"Eduardo" <m...@mm.com> wrote in message

news:k4aome$6qk$1...@speranza.aioe.org...

>
> "Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje
> news:k49bud$flm$1...@dont-email.me...
>> "Eduardo" <m...@mm.com> wrote in message
>> news:k47bke$d35$1...@speranza.aioe.org...
>>>
>>> BTW I have been working with the print preview window
>>> design, it takes lot of time to find good icons, edit them and
>>> produce a nice window with the appropriate icons.
>>
>> Isn't that a little premature ;-)
>
> Why premature?
> Don't I need that window?

I thought you would have gathered by my inclusion of a 'smiley' that my
remark was just 'tongue in cheek' ;-) The reason I said it is simply that
when writing code to perform a task that I don't currently know how to do
(as you are currently doing with your print preview stuff) I usually tend to
work the other way around, concentrating solely on the mechanics of the job
at hand and forgetting all about the details of the presentation of the user
interface until I have actually got the main code working. But that's just
me I suppose. That's just the way my head works. I didn't realise that you
might treat my remark with the seriousness you have done ;-)

Mike

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k4bi45$47u$1...@dont-email.me...

> I thought you would have gathered by my inclusion of a 'smiley' that my
> remark was just 'tongue in cheek' ;-) The reason I said it is simply that
> when writing code to perform a task that I don't currently know how to do
> (as you are currently doing with your print preview stuff) I usually tend
> to work the other way around, concentrating solely on the mechanics of the
> job at hand and forgetting all about the details of the presentation of
> the user interface until I have actually got the main code working. But
> that's just me I suppose. That's just the way my head works. I didn't
> realise that you might treat my remark with the seriousness you have done
> ;-)

Yes, Usually I also do that way. But as I still didn't have enough clarity
about what way to go, if the metafile or something else, I begun with
something that I could do at that time.

[Mike Williams]

"Eduardo" <m...@mm.com> wrote in message

news:k4bj1m$r8r$1...@speranza.aioe.org...

> Yes, Usually I also do that way. But as I still didn't have enough
> clarity about what way to go, if the metafile or something else,
> I begun with something that I could do at that time.

Oh, right. I didn't realise you had not yet come to a final decision.
Personally for your own purposes which include a totally accurate print
preview I would suggest metafiles. Metafiles really are extremely useful for
creating and printing documents. You only need to resort to other methods if
you are doing something really special in the way of graphics. In fact,
regardless of how you produced your document, even if you used the VB
Printer Object in the normal way, the Windows print spooler (unless it is
using XPS spooling) will use metafiles to spool the job, unless of course
your user has turned that feature off in Control Panel for a specific
printer. If metafiles are good enough for the Windows print spooler then
they are good enough for me ;-)

By the way, in my previous message in which I told you how MS Word behaves
when the user creates an A5 document in MS Word and then selects A4 in the
print dialog, I wasn't suggesting that you should do the same (ignoring the
A4 selection and printing the A5 document to the top left corner of the A4
page, at least to a printer which has only one paper tray). In fact you
probably would not want to do so. You might instead decide to pop up a
dialog alerting the user to the apparent mismatch and offering him various
alternatives, perhaps 'centralize on page', 'resize to A4', 'resize
maintaining aspect ratio' (for paper differences where the aspect ratio is
different), 'cancel' or perhaps some other option. It is entirely up to you.
Having said that, no matter what you do you will end up with problems with
some users. If they are daft enough to create a document of one paper size
and then select a different paper size in the final print dialog then they
are daft enough to have paper inserted which does not match the paper
selection they made!

Mike

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k4br15$kr9$1...@dont-email.me...

> By the way, in my previous message in which I told you how MS Word behaves
> when the user creates an A5 document in MS Word and then selects A4 in the
> print dialog, I wasn't suggesting that you should do the same (ignoring
> the A4 selection and printing the A5 document to the top left corner of
> the A4 page, at least to a printer which has only one paper tray). In fact
> you probably would not want to do so. You might instead decide to pop up a
> dialog alerting the user to the apparent mismatch and offering him various
> alternatives, perhaps 'centralize on page', 'resize to A4', 'resize
> maintaining aspect ratio' (for paper differences where the aspect ratio is
> different), 'cancel' or perhaps some other option. It is entirely up to
> you. Having said that, no matter what you do you will end up with problems
> with some users. If they are daft enough to create a document of one paper
> size and then select a different paper size in the final print dialog then
> they are daft enough to have paper inserted which does not match the paper
> selection they made!

Yes, I considered that.
I still didn't make the decision, but thinking that the user only can set
margins, how the page number are displayed (and if they are displayed or
not), the size of the fonts, and just formatting options (like printing
lines or not), he has very little ability (*) to modify the report in regard
to how the pages break, and if he changed the paper size in the last step is
most probably that he did so because he didn't do it in the other step
before, or even because he didn't know that he should or could do it in the
other step before (the page setup icon in the print preview window), so
preparing a new metafile for the new paper size might be the logical thing
to do in this case, I'm thinking. That's what I see that Notepad does (I
checked it now - I'm not saying it uses metafiles, it prints the pages in
the new size and changes the size of the document in the page setup to the
new size, so for further printings the size is already selected).

(*)Yes, changing top and bottom margins and the size of the fonts of course
will change how many lines will fit on each page, but I don't think that the
user will change them to accommodate how the pages break but for other
reasons (like bigger fonts for better reading without glasses, or to shift
the left margin to store the reports properly on a folder), if he changes
them at all.

I considered to offer options like stretching the page from one paper size
to the other or to redo the report for the new paper size (or even to center
it when the new size is bigger, etc) , but I'm thinking that it will most
probably confuse the user (he only wants a report printed, he's thinking
about the data at that time, many users could not understand this "strange"
question).

I try to do what the user intuitively could expect to get with what he's
doing.

Nevertheless, changing the paper size is not something that the user usually
will do. In most of the cases the user has only one paper size (A4), and it
should be configured as the default paper in the control panel and he never
needs to change the paper size.
But if he run the program in a more "corporate" environment, he could have
to deal with paper sizes.

[Mike Williams]

"Eduardo" <m...@mm.com> wrote in message

news:k4cie8$h8l$1...@speranza.aioe.org...
>
> . . . so preparing a new metafile for the new paper size [if the user
> changes the papersize in the print dialog as he performs the print]

> might be the logical thing to do in this case, I'm thinking.

Yes. That's fine. Like I said, it is entirely up to you. There are various
ways of dealing with the situation. Reformatting the document to the new
page size is what NotePad does, MS Word does something else, and MS
Publisher does something else again. Personally I might be inclined to do
none of those things and instead pop up a message box alerting the user to
the fact that the paper size he has chosen in the print dialog is not the
same as the paper size he chose when he created the document (or the paper
size he chose in the Page Setup dialog) and offering him a choice of all the
available reformatting and repagination and positioning and stretching
options, of which there are many. I might even decide to make a number of
little print previews of how the first page of the document would look for
each of the options I presented to him. But if I decided that I did not want
to bother the user with such a choice of options then I would probably chose
to simply reformat and repaginate the document to the new page size,
regardles of the fact that it might mess up the users desired layout as he
saw it when he was createing the document and that it would in fact produce
a document which was nothing like the document he might have seen it in any
print preview he previously looked at. Different things suit different kinds
of document, and it is entirely up to you to choose the best option for the
sort of documents you are creating. None of this has anything particularly
to do with metafiles of course, because you would have to consider exactly
the same things regardless of the method you chose to create the document
and to display the print previews. It's just that metafiles give you more
options and also greatly simplify the creation of extremely accurate print
previews.

Mike

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k4cov8$p9q$1...@dont-email.me...

Yes... perhaps I could pop that window if the user entered the page setup
from the print preview window and changed something. But if he just entered
the print preview and clicked print without changing anything, I would do
what I said of reformatting the page to the new size.
I liked your idea of showing the first page showing the different options
(in a small size). That would give the user a clue about what the program is
asking.

[Eduardo]

"Eduardo" <m...@mm.com> escribió en el mensaje
news:k4cqtg$8c4$1...@speranza.aioe.org...

> I liked your idea of showing the first page showing the different options

Redaction corrected: I liked your idea of displaying the first page in the
different options

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k49eub$js$1...@dont-email.me...

> By the way, here's a link to the code I posted a while ago. It was only
> about three or four months ago, I thought it was longer than that. It's
> just general testbed code but it should give you an idea of how the
> printout and the print preview work in practice. Create the project as
> described in the post and when you run it click the Form. Also try draging
> the Form to various different sizes.
>
> https://groups.google.com/group/microsoft.public.vb.general.discussion
/browse_thread/thread/4d8cc6e4ce0c168c/722b7745322e811d?hl=en-GB&lnk=gst&q=metaDPIX+%3D+25.4#722b7745322e811d

Mike, is there any reason why you used DrawTextEx instead of DrawText in the
sample?

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k46oak$chs$1...@dont-email.me...

> You can easily do those things by displaying a printer dialog though and
> by printing to the returned hDC using standard API printing methods.

I'm intrigued about this hdc, when is this object destroyed?

[Eduardo]

"Eduardo" <m...@mm.com> escribió en el mensaje
news:k4dc1g$fu2$1...@speranza.aioe.org...

I see that you must specify cdlPDReturnDC in the common dialog flags for the
hCD to be created, so I guess that you are the one responsible of destroying
it after you finished using it.

[Eduardo]

"Eduardo" <m...@mm.com> escribi� en el mensaje
news:k4dct3$hdm$1...@speranza.aioe.org...
>
> "Eduardo" <m...@mm.com> escribi� en el mensaje
> news:k4dc1g$fu2$1...@speranza.aioe.org...
>>
>> "Mike Williams" <Mi...@WhiskyAndCoke.com> escribi� en el mensaje

>> news:k46oak$chs$1...@dont-email.me...
>>
>>> You can easily do those things by displaying a printer dialog though and
>>> by printing to the returned hDC using standard API printing methods.
>>
>> I'm intrigued about this hdc, when is this object destroyed?
>
> I see that you must specify cdlPDReturnDC in the common dialog flags for
> the hCD to be created, so I guess that you are the one responsible of
> destroying it after you finished using it.

I searched the web and I couldn't find information about how to use this hDC
created by the common dialog.

The function PlayEnhMetaFile has a RECT as a parameter, but I don't figure
how to paste the different pages (different metafiles) into the correct
pages in the hDC.

[Eduardo]

"Eduardo" <m...@mm.com> escribi� en el mensaje

news:k4dicj$rr9$1...@speranza.aioe.org...

> The function PlayEnhMetaFile has a RECT as a parameter, but I don't figure
> how to paste the different pages (different metafiles) into the correct
> pages in the hDC.

I think I found it, APIs StartDoc, StartPage over the hDC.

[Mike Williams]

"Eduardo" <m...@mm.com> wrote in message

news:k4cues$hin$1...@speranza.aioe.org...

>
> Mike, is there any reason why you used DrawTextEx
> instead of DrawText in the sample?

In this particular example the standard DrawText function would have been
fine. The only reason I used DrawTextEx is simply because it is more
flexible, particularly with regards to its ability to return the the index
of the first character it failed to draw when you draw into a rectangle of a
specific height, and when I started to write the example I was not entirely
sure what I was going to do.

Mike

[Mike Williams]

"Eduardo" <m...@mm.com> wrote in message

news:k4dct3$hdm$1...@speranza.aioe.org...

>
>>> "Eduardo" <m...@mm.com> escribió en el mensaje
>>> news:k4dc1g$fu2$1...@speranza.aioe.org...

>>> I'm intrigued about this [CDL] hdc, when is this object destroyed?

>
> I see that you must specify cdlPDReturnDC in the common dialog
> flags for the hCD to be created, so I guess that you are the one
> responsible of destroying it after you finished using it.

Yes, you need to delete the printer DC returned by the CommonDialog Control
when you have finished with it or you will leak resources. Having said that,
on reflection I think you might be better off using an API dialog for your
purposes because there are some limitations to the CommonDialog Control even
when you are printing to its returned hDC.

Mike

[Mike Williams]

"Eduardo" <m...@mm.com> wrote in message

news:k4dj27$t8n$1...@speranza.aioe.org...

Yep, that's it. Use StartDoc initially and then use as many pairs of
StartPage . . . EndPage as there are pages in your document, finally ending
with an EndDoc.

Mike

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje
news:k4edri$fq9$1...@dont-email.me...

> Yes, you need to delete the printer DC returned by the CommonDialog
> Control when you have finished with it or you will leak resources. Having
> said that, on reflection I think you might be better off using an API
> dialog for your purposes because there are some limitations to the
> CommonDialog Control even when you are printing to its returned hDC.

Yes, I will use an API dialog.

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribi� en el mensaje
news:k4e65j$742$1...@dont-email.me...

>> Mike, is there any reason why you used DrawTextEx
>> instead of DrawText in the sample?
>
> In this particular example the standard DrawText function would have been
> fine. The only reason I used DrawTextEx is simply because it is more
> flexible, particularly with regards to its ability to return the the index
> of the first character it failed to draw when you draw into a rectangle of
> a specific height, and when I started to write the example I was not
> entirely sure what I was going to do.

OK

[Eduardo]

"Mike Williams" <Mi...@WhiskyAndCoke.com> escribió en el mensaje

news:k4eeqo$l66$1...@dont-email.me...

I'm still working with this issue.
The metafile stuff seems to be working wonderfully, although there are some
things that I didn't implement (like to draw images)
Thanks Mike.