Common Dialog Control doesnt allow orientation from Landscape to Portrait programmatically
Daniel
I am having a big problem with the Common Dialog control being used in
a Windows app developed using VB6 SP6 running on XP and 98.
When trying to print using the common dialog and set the common
dialog's orientation property I have noticed that it doesnt seem to
allow you to set it from Landscape to portrait from within code. I
mean you can set the Orientation property from 2 to 1 and see it has
changed in the code but as soon as the ShowPrinter method is called it
has gone back to Landscape which was the default setting on the
printer originally. Portrait to Landscape works fine but for some
reason it just wont allow the other way around. I am trying to set the
orientation before the dialog is displayed to the user after I have
already determined what the orientation is for the doc they are
printing.
I use
cdPrint.Orientation = cdlPortrait
cdprint.ShowPrinter
but when it gets displayed using the ShowPrinter call it always takes
the default printers setting and fails to modify it before its
displayed in the Common Dialog unless the default setting for the
printer was portrait and then it allows the change to landscape using
cdPrint.Orientation = cdlLandscape
cdprint.ShowPrinter
I have tried to get around it by using the Printer object but found
that it does not hold a real time reference to the actual printer,
meaning that changes to the Printer object dont seem to be immediately
seen in the default windows printer.
I have both Printer.TrackDefault and cdPrint.PrinterDefault set to
true, the changes seem to work fine only going from Portrait to
Landscape but not Landscape to Portrait.
If anyone has experienced this problem before or may have a clue about
it then I would be thankful for any help as I have spent quite awhile
on this now and it just seems to be a bug I dont know how to get
around.
Please Help me...
Ken Halter
> Hi there,
> I am having a big problem with the Common Dialog control being used in
You may have better luck with this component. The Printer Common Dialog
isn't very "VB Friendly".
HOW TO: Raise and Control Print Dialog Boxes from Visual Basic
http://support.microsoft.com/default.aspx?scid=kb;en-us;322710
--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..
Michael Mattias
news:82a1f472.04042...@posting.google.com...
> I am having a big problem with the Common Dialog control being used in
. [...]
> I use
> cdPrint.Orientation = cdlPortrait
> cdprint.ShowPrinter
> If anyone has experienced this problem before or may have a clue about
> it then I would be thankful for any help as I have spent quite awhile
> on this now and it just seems to be a bug I dont know how to get
> around.
I know (because I do it) that adjusting the portait/landscape settings on
the common dialog/printer works just fine when the calls are made directly
to the Windows API with a "competing compiler product." ... so I would not
spend a lot of time looking for a Windows problem.
Not sure that helps, but maybe it will prevent you from looking for love in
all the wrong places.
MCM
Ken Halter
> I know (because I do it) that adjusting the portait/landscape settings on
> the common dialog/printer works just fine when the calls are made directly
> to the Windows API with a "competing compiler product." ... so I would not
No need to use a "competing compiler product.". After all, this group is
for VB "Classic". Any answers that involve using a "competing compiler
product." don't belong here.
CommonDialog/Direct
http://www.vbaccelerator.com/home/VB/Code/Libraries/Common_Dialogs/Common_Dialog_Direct/article.asp
> spend a lot of time looking for a Windows problem.
>
> Not sure that helps, but maybe it will prevent you from looking for love in
> all the wrong places.
The poster's not in the wrong place... looks more like you are.
> MCM
Michael Mattias
news:eRjt1uS...@tk2msftngp13.phx.gbl...
> Michael Mattias wrote:
> > I know (because I do it) that adjusting the portait/landscape settings
on
> > the common dialog/printer works just fine when the calls are made
directly
> > to the Windows API with a "competing compiler product." ... so I would
not
> No need to use a "competing compiler product.". After all, this group is
> for VB "Classic". Any answers that involve using a "competing compiler
> product." don't belong here.
So tell the OP - who asked the question in non-VB newgroups, OK? (I never
read VB newsgroups, since I am not a VB programmer).
Sheesh.
Here I think I'm doing the guy a favor, and suddenly I am 'impure' because I
didn't edit his (erroneous!) "newsgroup list" when I hit "'reply?"
So what should this thread tell me about the general intelligence level of
MS-VB "developers?"
MCM
Ken Halter
> So tell the OP - who asked the question in non-VB newgroups, OK? (I never
> read VB newsgroups, since I am not a VB programmer).
>
> Sheesh.
>
> Here I think I'm doing the guy a favor, and suddenly I am 'impure' because I
> didn't edit his (erroneous!) "newsgroup list" when I hit "'reply?"
What favor? No code, no "competing compiler" recommendations, nothing.
What favor?
> So what should this thread tell me about the general intelligence level of
> MS-VB "developers?"
I'm not sure if you can lump all 'MS-VB "developers?"' into one group
because one person is having trouble with the Printer CommonDialog...
but, if it makes you feel "better", go right ahead.
fwiw, there's only one "non-visual" group in his crosspost list so
chances are that mostly VB programmers are going to see his post.
It's true that he was mistaken when selecting 'comp.lang.basic.misc' as
a group that dealt with VB (I guess... I've never been to any comp.lang
groups) but the 'favor' you provided was no help at all to anyone using
any language. Not as far as I could tell anyway..
dnagel
From what I remember, your original assertion that VB does not SET the
value for you when chosen from the common dialog is correct.
I believe you need to set the values yourself after the call to the
dialog, but before the code to print to the printer...
heres a quickie sample... Add a CommonDialog to a new form ...
Option Explicit
Private Sub Form_Load()
On Error GoTo CancelError:
MsgBox "Printer Orientation = " & _
IIf(Printer.Orientation = vbPRORPortrait, "Portrait", "Landscape")
With CommonDialog1
.CancelError = True
.ShowPrinter
Printer.Orientation = .Orientation
' or
' Printer.Orientation = vbPRORLandscape
End With
MsgBox "Printer Orientation = " & _
IIf(Printer.Orientation = vbPRORPortrait, "Portrait", "Landscape")
Exit Sub
CancelError:
'User canceled print dialog
MsgBox "Canceled Printing"
End Sub
hth,
D.
Ken Halter
> ok, now for a bit of help...
Way to start the post there... too bad the OP probably won't make it
down this far.
George Copeland
news:eRjt1uS...@tk2msftngp13.phx.gbl...
> No need to use a "competing compiler product.". After all, this group is
> for VB "Classic". Any answers that involve using a "competing compiler
> product." don't belong here.
I have been seeing a lot of people say that dot net questions are not
welcome in the comp.lang.basic.visual newsgroup. I have been posting in
this newsgroup for *years*, and I don't recall anybody being voted in as
moderator. Personally, I will try to help with *any* question having to do
with *any version* of VB, as well as any general Basic question. I hope
that is ok with all the self-appointed moderators.
> The poster's not in the wrong place... looks more like you are.
I on the other hand appreciate anyone who tries to post something useful. I
hope that is ok with you, too.
Ken Halter
>
> I have been seeing a lot of people say that dot net questions are not
> welcome in the comp.lang.basic.visual newsgroup. I have been posting in
> this newsgroup for *years*, and I don't recall anybody being voted in as
> moderator. Personally, I will try to help with *any* question having to do
> with *any version* of VB, as well as any general Basic question. I hope
> that is ok with all the self-appointed moderators.
Just try to avoid crossposting to the Microsoft groups... or at least
crosspost to the appropriate groups.
There are specific groups to support people using specific Microsoft
technologies. B# questions don't belong in a VB group.
> I on the other hand appreciate anyone who tries to post something useful. I
> hope that is ok with you, too.
Do what you want. If posting to the MS groups, don't be surprised if you
don't get .Net answers in a non .Net group. Heck... post questions about
how to raise dogs here... I don't care. Don't be surprised when you
don't get answers or are redirected to an appropriate group.
When people post code samples that run fine in VB6 to someone looking
for B# code, they're wasting their time and the poster's time. But, you
do what you want George.. I don't hang out in the cramp.lung groups
myself so I have no idea if they're organized or not (sounds like not)
George Copeland
> Just try to avoid crossposting to the Microsoft groups... or at least
> crosspost to the appropriate groups.
It is easy for even experienced usenet users to get crosswise with regulars
in a newsgroup. For myself, I try not to be part of the problem and ignore
any non-spam crossposting issue.
> There are specific groups to support people using specific Microsoft
> technologies. B# questions don't belong in a VB group.
Perhaps. However, I have noticed that some of the hottest app developers I
have ever seen are regulars in comp.lang.basic.visual. I myself have run
all sorts of problems past them.
> Do what you want.
Thanks for your permission. Have a nice day.
J French
<vb...@DELETETHIStechie.com> wrote:
<snip>
>I have been seeing a lot of people say that dot net questions are not
>welcome in the comp.lang.basic.visual newsgroup. I have been posting in
>this newsgroup for *years*, and I don't recall anybody being voted in as
>moderator. Personally, I will try to help with *any* question having to do
>with *any version* of VB, as well as any general Basic question. I hope
>that is ok with all the self-appointed moderators.
I would think through the consequences of doing this, very, very
carefully
It is often hard to tell whether a question is about 'Classic' or .NET
- and it is really annoying to give the OP an answer for 'Classic',
just to have them come back saying: 'by the way I'm using ...'
Right now, if I even have the faintest suspicion that the poster is
using .NET, I simply ignore the post.