Prev: ByeByeGDI
Next: Newsgroup Access
From: Mojo on 14 Jun 2010 05:53
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?

Thanks


From: Jeff Caton on 15 Jun 2010 07:42
Maybe you cared too much about DPI or you are resizing your form at
runtime?

I did this in the past in order to keep my app as it was when I designed it.
Now I do the following:

I design my form, I don't do any DPI-dependend changes anymore at runtime.
When the user wants to have huge buttons and texts, he has to deal with it.

Not sure if I understood your situation correctly.
From: Mike Williams on 15 Jun 2010 15:50
"Jeff Caton" <j.caton(a)gmailnotspam.com> wrote in message
news:ezTDY$HDLHA.5324(a)TK2MSFTNGP06.phx.gbl...

> I design my form, I don't do any DPI-dependend changes
> anymore at runtime. When the user wants to have huge
> buttons and texts, he has to deal with it.

Do you advertise this fact in advance to your prospective purchasers, or do
you just take their money and let it take them by surprise? If it is the
latter then shame on you, because you are hiding behind the fact that
consumer rights regarding software are a hundred years behind consumer
rights regarding tangible goods. Perhaps you might like to remind me about
the name of your app, so that I can avoid purchasing it.

Mike



From: Dee Earley on 17 Jun 2010 07:03
On 15/06/2010 20:50, Mike Williams wrote:
> "Jeff Caton"<j.caton(a)gmailnotspam.com> wrote in message
> news:ezTDY$HDLHA.5324(a)TK2MSFTNGP06.phx.gbl...
>
>> I design my form, I don't do any DPI-dependend changes
>> anymore at runtime. When the user wants to have huge
>> buttons and texts, he has to deal with it.
>
> Do you advertise this fact in advance to your prospective purchasers, or do
> you just take their money and let it take them by surprise? If it is the
> latter then shame on you, because you are hiding behind the fact that
> consumer rights regarding software are a hundred years behind consumer
> rights regarding tangible goods. Perhaps you might like to remind me about
> the name of your app, so that I can avoid purchasing it.

Erm, what Jeff is doing is exactly what he's supposed to do.

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.

The only time you need to do anything special for large fonts is when
you're dealing with fixed pixel size objects like images, but even then
just using twips to position around it will "do the right thing".

--
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 10:51
"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.

> 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.

> 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. This often happens when code moves from 96 dpi to 120 dpi, depending
on the logical size of the Form and the logical size of the screen. In such
a case the Form's client area will be a smaller logical size that it was at
design time and unless you have code that repositions its contained controls
then they will all be located at just the same design time logical
coordinates, resulting in those controls near the right and bottom edges
being clipped or totally missing. You need to take the same kind of
precautions regarding dpi changes in your code as you do regarding screen
pixel area changes, and you need to position the Form's controls at design
time so that they fit whatever sized Form they happen to be on. That's okay
when you are dealing with a user sizeable form, because your code will
almost certainly be taking all those things into account and repositioning
various things accordingly anyway (or at least it should be), but it is not
okay when, for example, you are using a fairly large fixed size Form or when
your app does not already include such repositioning code, as is quite
likely in the OP's specific case (Mojo) when he said:

"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."

Without more details of course we cannot be totally sure of what the OP is
actually doing, but it very definitely looks to me as though he might not be
using any code at all to cope with the specific problems I have mentioned
that can be caused by dpi changes, especially as he has said, ". . . the
buttons, scrollbars, etc go awol." For many Form layouts the problem of
"missing buttons" and other things when you change from running the code on
a 96 dpi machine to running it on a 120 dpi machine is in fact a classic
case of failure to add code to account for possible changes to the logical
size of the Form's client area caused by different dpi settings under
certain circumstances, which is why I took umbrage at Jeff's statement that
he does nothing at all about it. For Jeff's specific applications it might
not matter, depending on how his Forms are laid out and how he has coded
them to behave with respect to resizing etc, but the blanket statement "I
don't do ANY dpi-dependent changes anymore at runtime" implies that he feels
it is not necessary to ever do that, which quite simply is not the case.

I agree of course with what you said about not fiddling with the new pixel
size of objects caused by dpi changes, and not attempting to make them the
pixel size they were at a lower dpi setting, because (as I have said on many
occasions here) that is exactly what the dpi stuff was invented for (to
effectively magnify the entire Form and everything on it) but you very
definitely DO need to add code which makes sure that everything still fits
where it is supposed to be and is still fully visible on the Form if the dpi
change results in the logical size of the Form's client area becoming
smaller than it should be for any of the reasons I have outlined, especially
when you are talking about Forms which have been deigned at a fixed size and
which do not include appropriate repositioning code, which the OP might very
well be dealing with judging by the details given in his question.

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 ;-)

Mike





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