Prev: Array storage order???
Next: File Extensions and Directory Writes
From: Nobody on 10 Mar 2010 08:02
"Webbiz" <nospam(a)noway.com> wrote in message
news:21mep5h4i9surhklf0s3i8s3mj7q230ark(a)4ax.com...
> I went this route and it seems to be working.
>
> If sChar <> "" Then
> hFont = CreateFont(18, 0, 0, 0, 400, 0, 0, 0, 0, 0, 0, 0, 0,
> "Arial")
> hOldFont = SelectObject(pic.hdc, hFont)
> iRet = SetTextColor(pic.hdc, rgb(255, 255, 255))
> iRet = TextOut(pic.hdc, -4, 6, sChar, 1)
> iRet = DeleteObject(hFont)
> End If
>
>
> I don't know if what I did might have consequences depending on screen
> resolutions on other systems and such. On my system the font size was
> perfect within the size of the diamonds drawn, white and lightly bold.
> I hard coded the x,y of TextOut in respects to my FDDiamond
> coordinates.
>
> Do you see anything out of whack in this?

I forgot about DrawText() API function until Mike posted it. That function
has more options in how to print a text, but I don't think you need it here.
For example, you could use DT_WORDBREAK to print a text that wraps around to
the next line if it doesn't fit in the rectangle width you specified, so
this can be used to simulate a label, or use
DT_END_ELLIPSIS/DT_PATH_ELLIPSIS to shorten a long string when needed and
add ellipses "...". For the later, the shell also provides PathCompactPath()
to shorten long paths. You will probably find a use of these functions in
your program at some point.




From: Webbiz on 10 Mar 2010 16:03
On Wed, 10 Mar 2010 08:02:29 -0500, "Nobody" <nobody(a)nobody.com>
wrote:

>"Webbiz" <nospam(a)noway.com> wrote in message
>news:21mep5h4i9surhklf0s3i8s3mj7q230ark(a)4ax.com...
>> I went this route and it seems to be working.
>>
>> If sChar <> "" Then
>> hFont = CreateFont(18, 0, 0, 0, 400, 0, 0, 0, 0, 0, 0, 0, 0,
>> "Arial")
>> hOldFont = SelectObject(pic.hdc, hFont)
>> iRet = SetTextColor(pic.hdc, rgb(255, 255, 255))
>> iRet = TextOut(pic.hdc, -4, 6, sChar, 1)
>> iRet = DeleteObject(hFont)
>> End If
>>
>>
>> I don't know if what I did might have consequences depending on screen
>> resolutions on other systems and such. On my system the font size was
>> perfect within the size of the diamonds drawn, white and lightly bold.
>> I hard coded the x,y of TextOut in respects to my FDDiamond
>> coordinates.
>>
>> Do you see anything out of whack in this?
>
>I forgot about DrawText() API function until Mike posted it. That function
>has more options in how to print a text, but I don't think you need it here.
>For example, you could use DT_WORDBREAK to print a text that wraps around to
>the next line if it doesn't fit in the rectangle width you specified, so
>this can be used to simulate a label, or use
>DT_END_ELLIPSIS/DT_PATH_ELLIPSIS to shorten a long string when needed and
>add ellipses "...". For the later, the shell also provides PathCompactPath()
>to shorten long paths. You will probably find a use of these functions in
>your program at some point.
>
>
>


Thanks. Fortunately my need is just to print a single char in a
diamond that will not change size. No need to change font or color or
anything, so I should be good to go on all systems.

Thanks Nobody and Mike W.

:)
Webbiz
From: Mike Williams on 12 Mar 2010 03:48
"Webbiz" <nospam(a)noway.com> wrote in message
news:bnvip5h0srqfcvt84fvlmf4ktdvf2r2q5h(a)4ax.com...

> I actually coded this on my Windows 7 Professional
> machine. Yes, if I get any feedback from users of any
> display issues (already released it yesterday), I'll install
> it on the other machines here using Vista and change
> up the dpi and such as you suggest.

All machines from Win95 onwards and right up to Vista and Windows 7 are
capable of running at different DPI settings and so you really should test
your program at various DPI settings whatever machine you used as your
development machine and whatever machine your users are using. This
"possible problems at different DPI settings" is a general Windows thing,
not something specific to Vista, and you really should make sure that your
app behaves properly at the various different dpi settings. The easiest way
to do that with any certainty is to actually run the same compiled exe at
those different machine settings (or at the very least at the two main
settings of 96 dpi and 120 dpi) and see how it behaves, so that you can
amend your code to fix any problems that might appear. You can perform those
tests on any machine, and it is something you should be doing anyway, even
before Vista was produced, because it is a "Win 95 onwards" thing. If you
are performing these main tests on a Vista or Windows 7 machine though then
you should make sure that there IS a tick in the box against "Use Windows XP
Style DPI Scaling" when you change to a new DPI setting for your tests,
because you initially want to find out how your app behaves when it is not
using the new Vista "lie to me about the dpi" stuff. If there are any
problems on these tests then you will need to add code to your app to solve
them.

The other thing I mentioned, the "system lies to your program about the dpi"
stuff, is an /additional/ thing that currently applies only to Vista and to
Windows 7 and in order to stop any Vista or Win7 machine doing that (so you
don't need to worry about it) you should use a manifest to indicate to the
system that your app is "DPI Aware". I mentioned the new Vista and Windows 7
"lie about the dpi" thing not because it will be a problem for you (because
you can easily stop it doing that simply by using an appropriate manifest).
The main reason I mentioned it was simply to alert you to the problem and to
tell you how to sort it out because I thought that otherwise you might not
bother with the manifest, and so I wanted you to test your program on a
Vista (or Windows 7) machine as it stands, without the manifest, at the "lie
to me about the dpi" setting (the setting I mentioned where you set it to
120 dpi or greater and you remove the tick from the little box against "Use
Windows XP Style DPI Scaling"). That test can be performed on either a Vista
or a Windows 7 machine, and I mention it really for "illustration purposes"
because if your app shows a problem at that specific setting (no tick in the
box) then you can fix that specific problem merely by including the
appropriate "App is already DPI Aware" manifest.

You still need to first perform the main DPI tests mentioned in the first
paragraph of this response though (the different DPI settings where this IS
a tick in the "Use Windows XP DPI Scaling" box or where you are performing
the test on XP and earlier, where there is no box to tick) because any
problems that show up under those tests will need to be fixed in your code.
Those tests can be performed on any machine from Win95 onwards (although it
would obviously be better to perform them on a current machine such as XP or
Vista or Windows 7).

I know it sounds like a lot of messing about, but the tests themselves don't
take very long and they really are worth doing if you want your app to
behave properly on all the machines it is likely to come across.

Mike




From: Webbiz on 12 Mar 2010 14:31
On Fri, 12 Mar 2010 08:48:17 -0000, "Mike Williams"
<Mike(a)WhiskyAndCoke.com> wrote:

>"Webbiz" <nospam(a)noway.com> wrote in message
>news:bnvip5h0srqfcvt84fvlmf4ktdvf2r2q5h(a)4ax.com...
>
>> I actually coded this on my Windows 7 Professional
>> machine. Yes, if I get any feedback from users of any
>> display issues (already released it yesterday), I'll install
>> it on the other machines here using Vista and change
>> up the dpi and such as you suggest.
>
>All machines from Win95 onwards and right up to Vista and Windows 7 are
>capable of running at different DPI settings and so you really should test
>your program at various DPI settings whatever machine you used as your
>development machine and whatever machine your users are using. This
>"possible problems at different DPI settings" is a general Windows thing,
>not something specific to Vista, and you really should make sure that your
>app behaves properly at the various different dpi settings. The easiest way
>to do that with any certainty is to actually run the same compiled exe at
>those different machine settings (or at the very least at the two main
>settings of 96 dpi and 120 dpi) and see how it behaves, so that you can
>amend your code to fix any problems that might appear. You can perform those
>tests on any machine, and it is something you should be doing anyway, even
>before Vista was produced, because it is a "Win 95 onwards" thing. If you
>are performing these main tests on a Vista or Windows 7 machine though then
>you should make sure that there IS a tick in the box against "Use Windows XP
>Style DPI Scaling" when you change to a new DPI setting for your tests,
>because you initially want to find out how your app behaves when it is not
>using the new Vista "lie to me about the dpi" stuff. If there are any
>problems on these tests then you will need to add code to your app to solve
>them.
>
>The other thing I mentioned, the "system lies to your program about the dpi"
>stuff, is an /additional/ thing that currently applies only to Vista and to
>Windows 7 and in order to stop any Vista or Win7 machine doing that (so you
>don't need to worry about it) you should use a manifest to indicate to the
>system that your app is "DPI Aware". I mentioned the new Vista and Windows 7
>"lie about the dpi" thing not because it will be a problem for you (because
>you can easily stop it doing that simply by using an appropriate manifest).
>The main reason I mentioned it was simply to alert you to the problem and to
>tell you how to sort it out because I thought that otherwise you might not
>bother with the manifest, and so I wanted you to test your program on a
>Vista (or Windows 7) machine as it stands, without the manifest, at the "lie
>to me about the dpi" setting (the setting I mentioned where you set it to
>120 dpi or greater and you remove the tick from the little box against "Use
>Windows XP Style DPI Scaling"). That test can be performed on either a Vista
>or a Windows 7 machine, and I mention it really for "illustration purposes"
>because if your app shows a problem at that specific setting (no tick in the
>box) then you can fix that specific problem merely by including the
>appropriate "App is already DPI Aware" manifest.
>
>You still need to first perform the main DPI tests mentioned in the first
>paragraph of this response though (the different DPI settings where this IS
>a tick in the "Use Windows XP DPI Scaling" box or where you are performing
>the test on XP and earlier, where there is no box to tick) because any
>problems that show up under those tests will need to be fixed in your code.
>Those tests can be performed on any machine from Win95 onwards (although it
>would obviously be better to perform them on a current machine such as XP or
>Vista or Windows 7).
>
>I know it sounds like a lot of messing about, but the tests themselves don't
>take very long and they really are worth doing if you want your app to
>behave properly on all the machines it is likely to come across.
>
>Mike
>
>
>


I did the test at 126 dpi with and without the check in the box.

The drawings and graphics appear to be operating fine. They just got
bigger.

I'm puzzled as to what I could possibly do in my code to make things
not relative to each other when resizing the DPI.

Thanks.

Webbiz
From: Mike Williams on 12 Mar 2010 18:49

"Webbiz" <nospam(a)noway.com> wrote in message
news:qg5lp5d379m0majrv6eb4n0a3gko7vfq0e(a)4ax.com...

> I did the test at 126 dpi with and without the check
> in the box. The drawings and graphics appear to be
> operating fine. They just got bigger.

Yep. That's what's supposed to happen, and it's more or less automatic on
small VB Forms without needing any repositioning code because in many
respects VB is already dpi aware. The problems arise when you have a larger
fixed size Form that cannot expand its client area to its full 120 dpi size
on a 120 dpi machine because of a lack of screen real estate even though its
contained controls will still fully expand their size and position (and also
with user sizeable Forms of course) and when you are not positioning the
various elements on your Form in code in accordance with the current size of
its client area and the current size of the various elements. You are
obviously already doing that, at least in the important areas, which is why
your own Form is apparently okay at the various settings. It's always worth
checking though and you'll be surprised at how many apps go wrong at 120 dpi
or higher.

> I'm puzzled as to what I could possibly do in my code
> to make things not relative to each other when resizing
> the DPI.

It's not what you can do, but rather what you might fail to do. In your case
you are obviously already doing the required things. There are still the
Vista and Windows 7 special dpi scaling problems to account for though,
which can cause problems with your Form display even when you are already
doing all the right things in your code (the problems I mentioned that can
occur when the user's machine is set to 120 dpi with no tick in the box
against "Use Windows XP Style DPI Scaling". Those problems are due to the
new Vista special scaling not actually working properly for certain things.
I'm not sure whether they have fixed those problems in Windows 7 because I
don't have a copy, but they are a problem in Vista and if they have not been
fixed then they will be a problem in Windows 7 as well. In your own case it
would appear that you are not using anything on your Form in a way that will
show those problems (or that they have been fixed in Windows 7).

A few different things are affected by the problem but I'll give you one
specific example and you can try it out yourself. Suppose your development
machine is running at the standard 96 dpi and you have a standard ListBox or
a ComboBox on your Form which is using the standard MS Sans Serif font and
in which you are displaying lots of items for the user to select from and
suppose that you have set its size at design time so that it neatly displays
all items without any of them being "cut off" at the right side, and with
perhaps even a little bit of extra space "for comfort". If you run such a
compiled exe on a machine running at the same 96 dpi settings then it will
obviously work okay. If you then run it on a 120 dpi XP machine (or a 120
dpi Vista machine where there /is/ a tick in the "Use Windows XP Style DPI
Scaling" box) then it will still look okay, because the ListBox or ComboBox
will expand to 1.25 times its original design time pixel size and the size
of the font will expand by the same amount (or at least by a similar amount)
and everything will still probably fit as before, with the items in the
Combo still all being fully visible and not cut off at the right edge. The
whole ComboBox and its contents will effectively be a larger copy of the
original. However, if you run that compiled exe on a Vista 120 dpi machine
where there is /no tick/ in the "Use Windows XP Style DPI Scaling" box then
the ComboBox will still expand by the same amount as it did on the other 120
dpi machine, but the font will expand by a much larger amount, looking
obviously too big and usually resulting in many of the items being "cut off"
at the right side. Similar things happen in some other controls, often
resulting in text overflowing the width of a Label Control and in text in
some other controls wrapping when it did not wrap before. This is not a
problem if you instead use True Type fonts by the way, but then the special
Vista scaling method makes the text look quite blurred and your customers
will think they suddenly need glasses! As I mentioned earlier, there is a
very easy way to fix those problems and that is to use a manifest in which
you declare your app to be "dpi aware", which will prevent Vista from using
its "special scaling" system and your app will then work just as well as it
did on XP at 120 dpi.

As I've mentioned, these are definitelty problems in Vista and I suspect
they may also be problems in Windows 7 if MS hasn't got around to fixing
them. It might be worth trying that little test on your own Window7 and
Vista systems just to convince yourself that in such cases (in fact in all
cases) it really is worth embedding a suitable manifest into your app.

Mike




First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Array storage order???
Next: File Extensions and Directory Writes