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


"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: Clip capture - thanks Mike!
    ... >some things is default vbPixels. ... >>> make sense if the smallest division is Pixel. ... as so it follows that there are 1440 twips in one inch. ... >> by the pixel resolution of the display. ...
    (comp.lang.basic.visual.misc)
  • Re: Form is truncated.....
    ... Most machines run at 96 dpi (15 twips per pixel) but quite a lot run at 120 dpi and some at various other settings. ... All good applications, whether they are VB applications or not, always need to check the display on which they are running and adjust themselves accordingly. ...
    (microsoft.public.vb.general.discussion)
  • Re: Form Disappears
    ... show frmVolume at the fronm of the ZOrder. ... which on standard machines running at 15 twips per pixel is ... this code on a 800 x 600 pixel display (if, as I assume, you've got ...
    (comp.lang.basic.visual.misc)
  • Re: Picture in image control gets cliped "Sometimes" does not stay
    ... the width of the picture in the Image control. ... per logical inch (the equivalent of 15 twips per pixel) whereas others run ... exactly the same "twip size" as the design time twip size client area on ...
    (microsoft.public.vb.general.discussion)
  • Re: Algorithm for "Windows Center" and "Windows Width"
    ... y represents the output display level. ... For 16 bit pixel values, you have a potential range of 65536 values but you have only a display range of 256 values, so some manipulation must be done. ... As an extra challenge for you, I think you will find that performing this calculation for every pixel everytime the user changes the window settings will make your application run very slowly. ... identity (no rescale values or Modality LUT, ...
    (comp.protocols.dicom)