Prev: Using VB6 to respond to web page
Next: VSM 05/2002 Dan Fergus Article - Getting Debug Info from Production Apps
From: Schmidt on 14 Jun 2010 19:31

"Helmut Meukel" <Helmut_Meukel(a)NoProvider.de> schrieb im Newsbeitrag
news:hv654j$9l8$1(a)news.eternal-september.org...
> "Schmidt" <sss(a)online.de> schrieb im Newsbeitrag

> > Uff, may I ask, if this by any chance was used in some
> > "atomic power plant"? ;-)
> >
> > D&R (in the true sense) <g>

> No, normally the program ran in 'automatic mode', which meant it
> just displayed actual values it got from the PLC which did all the
> work.
> In 'manual mode' the user could start/stop pumps und open/close
> valves by clicking on the display. The VB program did however
> only transfer these user actions to the PLC and the PLC processed
> them -- if they were valid. That is it checked if the desired action
> was within the safety bounds of its program.

Ok, I'm relieved... ;-)

> BTW, I programmed this in 1993 in VB3 running on a NT3.51 box.
> About 2001 I upgraded it to VB6 without any substantial change
> and it was used til autumn 2008, when they shut-down the plant.
Yeah, seems that those who talk about "the next Cobol"
really do have a point. ;-)

Olaf


From: Mike Williams on 15 Jun 2010 03:54
"Helmut Meukel" <Helmut_Meukel(a)NoProvider.de> wrote in message
news:hv5s88$n95$1(a)news.eternal-september.org...

> So if the OP is working with different units (twips,
> pixels, himetrics) without correcting positions and
> sizes due to the different dpi settings he is in trouble.

Actually the various logical units aren't in themselves so bad (twips,
inches, centimetres, himetric, etc) because they all bear exactly the same
fixed relationship to each other as do the equivalent real world units. It
is the pixels which cause most of the problems because the relationship
between pixels and logical units depends on the user's current dpi settings.
If you write your code to examine those settings and to properly take such
things into account when positioning and sizing the various elements of your
Form at run time of course then you can mix pixels and logical units at
will, but it is when you do not take those things into account that things
go wrong.

Having said that, you can also have problems (and very often will do) even
if you use /only/ logical units (twips or whatever), unless of course you
write your code to take such things into account. Essentially, VB stores the
design time client area size of your Form and the design time position and
size of all its contained controls using logical units (VB happens to use
twips, but it is the fact that they are logical units that really matters
rather than the fact they are specifically twips). When your compiled exe is
run on the target machine, VB attempts to create a Form that has the "IDE
design time" logical size client area, automatically taking into account the
relationship between pixels and twips (the dpi setting) on the target
machine and also automatically taking into account whatever the border and
caption bar thicknesses happen to be on the target machine.

If VB succeeds in creating such a Form then all is well, because unless your
runtime code specifies otherwise the logical size (twip size, if you prefer
to look at it that way) of the client area of the Form will be exactly the
same as the logical size it was in your IDE when you developed it (although
its pixel size of course will be whatever that logical size happens to
require on the target machine). VB will then place all the contained
controls at their "IDE design time" logical size and position on that Form,
again automatically taking into account the relationship between twips and
pixels on the target machine. The overall result (with just one specific
exception that rarely causes problems and which I won't go into here to
avoid overcomplicating it) will be that the Form and its contained controls
will look exactly the same on the target machine as it looked on your
development machine. The only difference will be that if the number of
"pixels per twip" on the target machine is larger than the number of pixels
per twip on your development machine then the entire form and all its
contents will have a larger pixel size than they did on your development
machine, but otherwise it will look exactly the same, and everything will be
in the correct position (in fact that was the original intention of the "dpi
stuff" in Windows, and as far as the Form we have just discussed is con
cerned VB handles it quite well).

All the above goes quite well when your Form is a fixed size and is fairly
small in relation to the screen. The real problems arise when your Form is
fairly large because VB will on many machines be unable to create a Form
that has the desired logical client area size (as outlined above) and it
will therefore be forced to create a smaller Form that is limited to the
available screen area on the target machine. VB will still calculate the
desired size and position of the contained controls exactly as it did
before, and it will place them at those positions regardless, with the
result being that many of them will either wholly or partially disappear
because the Form is simply not large enough.

There are "resizing controls" available that attempt to solve many of these
problems automatically for you, but they cannot possibly accommodate all
eventualities because only the designer of the VB program itself can
possibly know exactly how he wants his Form to behave under all
circumstances. So, unless your Form is a fairly small fixed size Form then
it really is best to write such code yourself so that it examines the dpi
setting and the screen pixel area on the target machine at run time and set
itself up accordingly.

One other point to bear in mind is a new dpi setting that is available in
Vista, which has muddied the waters quite a bit (as is often the case with
Micro$oft software) by "holding your hand" more than you really want it to
be held, and in the process often making it more difficult rather than
easier! The new dpi setting actually "lies" to a running program, telling
the program (telling your VB program for example) that the system's dpi
setting is 96 dpi even when it is not, and attempting to accommodate the
differences "under the hood". So, in Vista the user can choose between the
standard 96 dpi setting, or the standard 120 dpi setting (or any one of the
other available standard dpi settings) or he may instead choose the new "lie
about the dpi setting". This new "lie to me" setting is intended for poorly
written software that is not itself aware of the different available dpi
settings and of how they affect things. It often results in really poor low
resolution and blurred screen output and it really is not much use.

The best way of dealing with this new possible "lie to me about the dpi"
setting on the target machine is to turn it off. You don't want to attempt
to turn it off for the entire machine of course, because it is after all a
user setting and you shouldn't really mess with those things without the
user's specific permission (and probably not even with his permission!), so
the best option is to turn it off only as far as your own specific running
VB program is concerned. You can do this with an API call (can't remember
the name of it because I'm on holiday at the moment and I'm just waiting for
the tide to go out!) but it is not the recommended way of doing it (for
various reasons) and it is best to turn it off by embedding an appropriate
"I am dpi aware so do not lie to me about it" manifest in your compiled VB
exe. This will prevent Vista lying to your VB program and so your own
"examine the user's dpi settings and screen pixel area and behave
appropriately" code (which all good programs should have) will work in
exactly the way you expect it to work on all systems, including Vista and
regardless of whether the user is using the new "lie to me" dpi setting.

Mike




From: Mojo on 16 Jun 2010 05:05
Hi BeeJ

Many thanks for the feedback. To be honest, the problem always seems to
occur when a WinXP machine is changed from the default 96 dpi to say 120
dpi.

I didn't even realise that all Vista/7 machines had 120+ by default, as I've
not seen the issues on these.

Rgds



"BeeJ" <beejuice(a)live.com> wrote in message
news:hv5mpf$5u3$1(a)news.eternal-september.org...

"Mojo" <please(a)dont.spam.com> wrote in message
news:1dGdnZXvecWmYYjRnZ2dnUVZ7oCdnZ2d(a)brightview.co.uk...
> 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
>
>
Hmmm ... My Windows Vista Ultimate is set to 120 DPI (always has been) and I
have no issues as you describe with any of the VB6 apps that I created. I
use all available controls and even have some that I created. No problems.
Maybe it is your display adapter/driver? Have you tried on other PCs with
them set to 120 DPI or otherwise?
I do have one app that does have similar issues, but that is a commercial
app produced by Punch software (Home Design).



From: Helmut Meukel on 16 Jun 2010 06:07
Mojo,

you misunderstood BeeJ. He didn't say Vista/7 have 120 dpi by default.
In fact both have 96 dpi as default.
He just said he has his machine set to 120 dpi from the beginning.
Same as with me, I have always set my machines to 120 dpi. I've just
one box out of 6 let with the default 96 dpi (in my case a Vista box).

Helmut.

"Mojo" <please(a)dont.spam.com> schrieb im Newsbeitrag
news:EZqdnYYs4Yd7DoXRnZ2dnUVZ8g-dnZ2d(a)brightview.co.uk...
> Hi BeeJ
>
> Many thanks for the feedback. To be honest, the problem always seems to
> occur when a WinXP machine is changed from the default 96 dpi to say 120
> dpi.
>
> I didn't even realise that all Vista/7 machines had 120+ by default, as I've
> not seen the issues on these.
>
> Rgds
>
>
>
> "BeeJ" <beejuice(a)live.com> wrote in message
> news:hv5mpf$5u3$1(a)news.eternal-september.org...
>
> "Mojo" <please(a)dont.spam.com> wrote in message
> news:1dGdnZXvecWmYYjRnZ2dnUVZ7oCdnZ2d(a)brightview.co.uk...
>> 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
>>
>>
> Hmmm ... My Windows Vista Ultimate is set to 120 DPI (always has been) and I
> have no issues as you describe with any of the VB6 apps that I created. I
> use all available controls and even have some that I created. No problems.
> Maybe it is your display adapter/driver? Have you tried on other PCs with
> them set to 120 DPI or otherwise?
> I do have one app that does have similar issues, but that is a commercial
> app produced by Punch software (Home Design).
>
>
>


First  |  Prev  | 
Pages: 1 2
Prev: Using VB6 to respond to web page
Next: VSM 05/2002 Dan Fergus Article - Getting Debug Info from Production Apps