Prev: ByeByeGDI
Next: Newsgroup Access
From: Dee Earley on 17 Jun 2010 11:54
On 17/06/2010 15:51, Mike Williams wrote:
> "Dee Earley"<dee.earley(a)icode.co.uk> wrote in message
> news:eTcqPzgDLHA.1368(a)TK2MSFTNGP06.phx.gbl...
>
>> Erm, what Jeff is doing is exactly what he's supposed to do.
>
> No it's not! What he actually said was, "I don't do ANY dpi-dependent
> changes anymore at runtime" and he went on to say, "When the user wants to
> have huge buttons and texts, he has to deal with it".
>
> That statement implies that he does nothing at all in any of his
> applications with respect to the changes caused by different dpi settings on
> different machines. In some cases it is okay not to bother with it of
> course, but in other cases it is very definitely NOT okay. Jeff did not
> specify how he laid out his Forms or about what other coding they contain
> and so we cannot tell whether he is dealing with it properly, and so YOU
> cannot say that he is doing the right thing by doing nothing.

I don't see how any method of laying out controls at design time can
create different results if left unchanged by code.
"I don't do any dpi dependant changes" implied to me that he doesn't do
any form/control resizes, etc, but I see how I could have misread that

>> If a user sets large fonts, then everything will become
>> bigger (by default). If you then force everything back
>> to a pixel size, it's going against their wishes
>
> I never said anything in this thread about forcing everything back to a
> pixel size, Dee. You're just making things up! I did mention resizing
> controls in another /different/ thread, but I specifically said that you
> should NOT use them.

I didn't say you did.
You implying that letting the language do its stuff leads me to beleive
that you thinkg you MUST write DPI handling code, which as you've just
said in this post is not the case.

>> The only time you need to do anything special for
>> large fonts is when you're dealing with fixed pixel
>> size objects like images
>
> Wrong. Don't forget that we are talking about dpi changes here. A dpi change
> causes the relationship between twips and pixels to change, and so objects
> which at design time fitted entirely within a specific logical size of Form
> will fail to fit if the LOGICAL size of the client area of the Form changes
> as a result of the dpi change, which will be the case if VB cannot create a
> Form of the required logical size client area because there do not happen to
> be sufficient pixels on the display to accommodate the new overall size of
> Form.
<SNIP>

I hadn't taken window size clipping into account as I rarely create
"large" fixed dialogs, and everythign else is resizable, and I fully
agree with all that.

> Oh, and another thing, there very definitely ARE other things you need to
> add code to deal with in respect of dpi changes in certain circumstances,
> none of which you have mentioned when you argued with what I said and when
> you agreed with Jeff's statement that he should do NOTHING to deal with DPI
> dependent changes, and so I presume you do not know about them. Post again
> if you need more help ;-)

I'd be happy to know what they are if I missed anything, but I fixed all
my DPI problems many years ago and now know better :)

--
Dee Earley (dee.earley(a)icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)
From: Mike Williams on 17 Jun 2010 16:10
"Dee Earley" <dee.earley(a)icode.co.uk> wrote in message
news:%23SLhSWjDLHA.5476(a)TK2MSFTNGP06.phx.gbl...

> I don't see how any method of laying out controls
> at design time can create different results if left
> unchanged by code.

Yes you do. You're making things up again :-)

In fact in this very same message of yours to which I am responding now you
agreed with my statement regarding that matter when you said, "I hadn't
taken window size clipping into account as I rarely create large fixed
dialogs, and everythign else is resizable, and I fully agree with all that".
So, your agreement therefore contradicts you initial statement in your
response as it clearly indicates that you DO see how a method of laying out
controls at desing time can create different results if unchanged by code
:-)

> You implying that letting the language do its stuff leads
> me to beleive that you thinkg you MUST write DPI handling
> code, which as you've just said in this post is not the case.

No I didn't. You're making things up again :-) I said that you should write
dpi handling code suitable for whatever specific app you are writing. As an
example, and as you surely must agree in view of your recent acceptance of
my other statement as mentioned above, you clearly and definitelty should
write dpi handling code if you are creating large fixed size Forms with
various controls positioned at design time, especially if some of those
controls are positioned near the right or bottom edges (as is possibly what
the OP is doing). You need to do that in order to take account of the fact
that in some cases some of those controls will not fit onto the Form when it
is run at dpi settings greater than those on your design machine.

> [In response to Mike's statement that there are also other things you
> need to deal with in respect of dpi changes in certain circumstances]
>
> I'd be happy to know what they are if I missed anything, but I fixed
> all my DPI problems many years ago and now know better :)

Well if you've fixed all your problems then that's fine, but one of the
other dpi things you need to take into account under certain circumstances,
and something that has not yet been mentioned, is the fact that the widths
of the various Controls are capable of changing their pixel size pretty much
exactly in accordance with the dpi change in relationship between twips and
pixels (to within about a single pixel overall), whereas in general strings
of text are not capable of doing it so accurately. That's because as far as
VB and GDI32 is concerned both the point size of a font and the width of
each individual character in a font is restricted to a whole pixel value,
and will be rounded up or down accordingly.

In some cases the actual point size of a "design time point size " font is
greater at 120 dpi than it is at 96 dpi, and so it has a larger logical
size. This will usually cause most of the characters in that font to have a
greater logical width on the 120 dpi machine than they do on the 96 dpi
machine, and in certain circumstances this needs to be taken into account.

In other cases of course the point size is less on the 120 dpi machine than
it is on the 96 dpi machine, depending on the actual point size in question,
and you would think that in such a case it would not matter, but even in
such cases (where the point size is smaller on the 120 dpi machine) many of
its characters can still have a greater logical width, again because they
are each restricted to whole pixel value widths. For example, the "design
time standard" 8 point MS Sans Serif font actually produces a point size of
8.25 points on a 96 dpi machine and a point size of only 7.8 points on a 120
dpi machine, meaning that the font point size itself has a smaller logical
height. However, because the "whole pixel" restriction applies to the width
of each individual character as well as to the point size then many of its
characters still have a larger logical width. I've just performed a quick
test on my own machine (testing the actual logical width of each character
in the "8 point design time MS Sans serif font and even though the point
size has a smaller logical height there are about 38 characters in that font
which have a larger logical width.

These things often do not pose a problem if most of your controls (Command
Buttons, Label Controls, etc) are generally quite a bit wider than the text
or caption they contain, but if the width of the control is close to the
caption width then it can cause problems. Even if the control is a Label and
has its Autosize property set to True there can still be problems in certain
circumstances.

Now I'm not saying that these problems will affect all programs of course
(much depends on the layout of the Form and its controls) but I have seen
quite a few programs where a caption, even a single word caption, is too
wide for a control, resulting in the last character of the caption wrapping
in a very unsightly way, and I've seen Labels that cut off the last
character and other Labels (even Autosize labels) which are close to other
controls and in wich the last character or two of the Label disappears
underneath the control it is next to. All sorts of things can happen that
can quite noticeably detract from the overall quality of the look and feel
of the Form.

Now I am not saying that /every/ program automatically needs to have dpi
code written for it, and it is up to the author to decide whether it is
necessary in any particular case, but I am saying that in many cases such
code very definitelty does need to be written and it is very definitely NOT
the general case that you should not bother with it.

Mike




From: Mark McGinty on 30 Jun 2010 13:29

"Mojo" <please(a)dont.spam.com> wrote in message
news:uDI68d6CLHA.5584(a)TK2MSFTNGP06.phx.gbl...
> Hi All
>
> I have created a multiple form app (only shows 1 form at a time though!)
> and
> it looks and works fine on most Win2000 - 7 machines.
>
> However, if a machine has been set up for any other dpi than the default
> setting of 96dpi (eg 120dpi) then my app has a huge grey appendedge to it
> and all of the buttons, scrollbars, etc go awol.
>
> I have to be a genius with the old mouse and click into nothingness to get
> the app to quit or do a Ctrl+Alt+Del job. I have to do this as the app is
> completely unusable yet all other apps seem fine.
>
> Did I miss something in programming pre-school???
>
> Is there no way I can just have my app at a desired set size irrespective
> of
> the dpi?

Does your code convert between TWIPS and pixels, and then resize/reposition
anything based upon those conversions? TWIPS map to actual physical size,
whereas a pixel is a hardware-specific unit that could theoretically be any
size...

If it were my project I'd change my DPI, set strategic breakpoints and step
through the position/size manipulation code to find out where it's going
awry.


-MM



> Thanks
>
>


First  |  Prev  | 
Pages: 1 2
Prev: ByeByeGDI
Next: Newsgroup Access