Re: Picture in image control gets cliped "Sometimes" does not stay

Mike and Jeff,

THANK YOU very much for the detailed information. It was exactly what I
needed. The quick fix for me was to set the Image Stretch property to True.
This solved the cropping problem. Now I just have to tweak the graphic so
that it does not get distorted, which it did a little bit, just like Mike had
warned me about. The detailed info you gave me Mike will go in to my
permanent solutions and fixes folder and will be a great help when I go to
add the routines to keep the lay out looking good.

Jeff the explanation of the boarder influence etc will make much it easier
for me to design and manage my form lay out.

Again, thanks a bunch for the detailed reply's, you guys have been a great
help,

Ralph Malph


"Mike Williams" wrote:


"Ralph Malph" <ralph.malph@xxxxxxxxxxxxx> wrote in message
news:B207ADB6-ECC2-4A8A-A184-BAECFA088BAD@xxxxxxxxxxxxxxxx

I have a VB6 program I am working on. On the main form I have
an Image control I use for displaying the program title and logo
at the top of the form. The width of the form is set to be exactly
the width of the picture in the Image control.

.. . . and how, exactly, are you doing that? The devil is in the detail :-)

When I run the program on the development computer . . . the
form looks fine . . . the overall size of the form is less than
640x480 so at no time should it ever need to be re-sized, cropped,
chopped etc. . . . My problem is that on some PCs all looks as it
was designed, the left and right border ar flush with the left and
right side of the picture . . . on others . . . the right 3rd of the
picture is chopped off. Any ideas as to why this would happen . . .

This will almost certainly be because your code is not properly taking into
acount the differences in the Windows dots per inch (or twips per pixel)
setting on different machines. Most typical machines run at 96 screen pixels
per logical inch (the equivalent of 15 twips per pixel) whereas others run
at 120 screen per logical inch (the equivalent of 12 twips per pixel), and a
few run at any one of a number of other different possible values. When
laying out your Form and its contents you should always add code to examine
the dots per inch (or twips per pixel) setting of the machine on which your
code is currently running and to where necessary make the required
positional adjustments.

For example, when VB loads a Form (unless you add code to force it to do
otherwise) it will always attempt to create it at such a size that its
client area on the machine on which your code is currently running is
exactly the same "twip size" as the design time twip size client area on
your development machine. VB cares only about twips in this respect,
regardless of your various ScaleMode settings. So, if the "twip client area"
of your Form on your IDE machine is for example 7500 x 6000 twips and if
your code is then run on a machine that happens to be set to 96 dpi (15
twips per pixel) then VB will create a Form that has a client width of 500
pixels (7500 / 15) and a client height of 400 pixels (6000 / 15). However,
the same code running on a different machine, one that is for example
running at the 120 dpi (12 twips per pixel) setting VB will create a Form
that has a client size of 625 pixels (7500 / 12) and a client height of 500
pixels (6000 / 12). The only time it will fail to do this is if the pixel
size of the display on which your code is running is not sufficient to
display such a Form, in which case it will make the client area as large as
it can under the circumstances. So, on one machine (with the example values
shown) you get a 500 x 400 pixel client area Form and on a different machine
you get a 625 x 500 pixel client area Form.

Exactly the same reasoning applies both to the "IDE twip position" and the
"IDE twip size" of the Form's contained controls, with VB attempting to
display them at their design time twip values, regardless of how many pixels
that might happen to be on the machine on which your code is currently
running. For large Forms you need to take special care to add code to "fix
things" at run time if necessary (where VB manages to fully resize the
controls but finds it does not have sufficient screen pixel area to fully
resize the Form, resulting is some controls "disappearing off the right and
bottom edges"), but for small Forms (those that are in all cases likely to
end up at a smaller overall pixel size than the pixel size of the smallest
display you are likely to use, such as 800 x 600 or whatever) then you don't
need to worry too much, because VB will automatically adjust the size and
position of both the Form and all its contained controls in accordance with
the above rules, resulting in the Form and its contents looking exactly the
same on all machines, except of course that on some machines a Form might
occupy perhaps half of a 800 x 600 display whereas on other machines it
might occupy about two thirds of the same 800 x 600 pixel display.

There are of course some things that under some circumstances need
additional consideration. Your Image Control (the one you are having
problems with) is one example. If its Stretch property is set to True (so
that it maintains its design time twip size and so that it stretches the
contained bitmap accordingly) then VB will set the pixel size of the Image
Control in accordance with the dots per inch (twips per pixel) setting of
the machine on which your code is running in exactly the same way as it does
for the Form and for other contained Controls, so if the Image exactly fills
the client width of the Form on a machine running at 96 dpi then it will do
the same on another machine running at 120 dpi (unless of course the
resultant Form size would be too large to fit onto the display, as explained
above). However, if the Image Control's Stretch property is set to False (so
that it maintains its pixel size at the exact same size as the pixel size of
the picture it contains) then the pixel width of the Image Control will no
longer have the same relationship to the pixel width of the Form's client
area on a 120 dpi machine that it had on a 96 dpi machine.

Overall, you should always add code to check the actual client area size of
your Form *after it has been fully loaded and displayed* to make sure
everything is as you desire, and to make the necessary positional and / or
size adjustments if it is not. In the specific case of your Image control
(the one you are using as a "top logo") if you wish picture to always
exactly fill the client width of the Form then one way (although there are
others, depending on exactly what you want), is to set its Stretch property
to True and to add code to set its Width to the same as the ScaleWidth of
the Form *after the Form has loaded and fully resized*. When using this
method you also need to take account of the overall resolution and you need
to use an image of such an original pixel size that it will not look
"blocky" when it gets stretched to the desired size.

Personally for all development work I would advise you to set your own
development machine to whatever setting most of your customers normally use
(for that one specific project). This will in most cases be 96 dpi (15 twips
per pixel), which is by far the most widely used setting. although in some
special circumstances for certain types of customer it might be something
else. Anyway, create and design your app with your machine set to the
reference setting (probably 96 dpi) but regularly test it by creating and
saving the exe to your desktop (or wherever) and then switching your own
machine to some other setting (120 dpi for example) and run the saved exe to
see how it behaves. This will often pick up all sorts of problems that you
might not otherwise notice.

Coming back to your original problem, if what I have covered so far does not
help you then post again with full details of what you are doing, both in
the IDE and in code, regarding setting the size or position of your Form and
of the Image Control and I'll try to be a bit more specific.

Having said all this, there are third party "resizing controls" out there
that purport to automatically take care of all this stuff for you. I've
never used any of them myself, but from a knowledge of what they need to do
I would imagine that those that are simple to use will often fail to carry
out the job properly under many specific circumstances and those that are
capable of solving all of the problems will require so much in the way of
"user settings" that you might as well just perform the task yourself in
code in the first place.

By the way, you can easily check the dpi setting at runtime using either of
the following:

MsgBox Me.ScaleY(1, vbInches, vbPixels) & " dots per inch."
MsgBox Me.ScaleY(1, vbPixels, vbTwips) & " twips per pixel."

Mike












.

Relevant Pages

  • Re: Some label controls appear black on some computers
    ... In fact VB specifically uses twips. ... In most cases a smaller pixel size also means a smaller logical size, but that is not always the case and it actually depends on the relationship between twips and pixels on the target machine as well as on its actual pixel size, and the relationship between twips and pixels can be different on different machines depending on their dpi settings. ... So, generally, your VB code should always check the logical size of the available screen area on the target machine and it should adjust the position of the Form's controls if the available logical screen area on the target machine is not large enough to accommodate the design time logical size of your Form's client area, after taking into account the thickness of all of the Form's borders. ... Does it happen ONLY to Labels where you change the size in code, or does it also happen to other Labels? ...
    (microsoft.public.vb.general.discussion)
  • Re: ColorIndex of the current application
    ... I'll leave the SendMessage idea for you but I had a quick go with GetPixel, ... can get the pixel directly from the desktop. ... simple but of course will only work if the fill control is visible on the ... toolbar window, which if it works, does not require the control to be ...
    (microsoft.public.excel.programming)
  • Re: Picture in image control gets cliped "Sometimes" does not stay flu
    ... the width of the picture in the Image control. ... This will almost certainly be because your code is not properly taking into acount the differences in the Windows dots per inch (or twips per pixel) setting on different machines. ... The only time it will fail to do this is if the pixel size of the display on which your code is running is not sufficient to display such a Form, in which case it will make the client area as large as it can under the circumstances. ...
    (microsoft.public.vb.general.discussion)
  • Re: When I change the DPI setting to 125% of Normal font size.
    ... The magical algorithms that convert Dialog Box Units to pixel positions have to be ... Now I have dynamically set the window position. ... bind the ID to a control variable. ... systems display settings to be fit in the application window. ...
    (microsoft.public.vc.mfc)
  • Re: Custom Zoom & Performance
    ... I have a need to do this on a pixel level. ... Nothing strange about that, that's how a zoom ... Now why I would want this per-pixel control over a scaling feature is not ... the scaled pixel ...
    (microsoft.public.dotnet.framework.drawing)
Loading