1) it act as container control
2) use of memory to store the picture
3) editing of picture is possible in picture box
4) having auto size property
5) not having stretch property
Image Control:
1) it is not act as container control
2) not use of memory to store the picture
3) editing of picture is not possible in picture box
4) Not having auto size property
5) Having stretch property
Main Difference:
The Image control is a lightweight control that has no device context (or hDC) or it's own. The Picturebox does have a device context and hDC and is a true "window" from the point of view of the Windows operating system (and can directly use "hWnd" parameter API calls).
Due to this difference, an Image control can display a gif file loaded into the picture property with a transparent background, while a picturebox does not. The Picturebox, however, doesn't "flicker" when moved at runtime like an Image control does. This difference also has implications for layering -- a lighweight control (like the Image control) can only be z-ordered (layered) over another lighweight control --but never over a true window like the Picturebox control. The Image control is also "lightweight" in terms of it's memory footprint (versus the
Picturebox control which is "heavier" even without the extra memory backbuffer that is reserved with its AutoRedraw property set to True) --although with the amount of memory available in most modern computers, this doesn't usually make this much of a difference, but it might come into play with large control arrays containing large graphics that would force paging out to virtual memory (which, in turn, could effect the speed of game graphics).
An Image control has Stretch property, a Picturebox control does not.
Picturebox control has an AutoSize property, an Image control does not.
However code workarounds can substitute for these two missing properties in either/both.
Both controls use a StdPicture object to store graphics and so Picture.Render and LoadPicture/SavePicture will work with both (but PaintPicture only works with the Picturebox control).
A Picturebox control is a container control, an Image control is not.
A Picturebox control also has a whole bunch of properties that an Image Control does not - BackColor, FillColor, FillStyle, etc.
The long and short of it [IMHO] is that the PictureBox control is the more generally useful of the two controls and used in conjunction with PaintPicture or the Bitblt/Stretchblt/AlphaBlend APIs can do just about anything you could want with graphics.
DirectX surfaces may be slight faster way of manipulating graphics, but when using Direct Memory Access (DMA) pixel manipulation techniques with Picturebox control graphics --it can be relatively quick..and works even with older non-Directx compatible video cards/systems.
Picture Box Vs Image Box in VB
picture box:
1) it act as container control
2) use of memory to store the picture
3) editing of picture is possible in picture box
4) having auto size property
5) not having stretch property
Image Control:
1) it is not act as container control
2) not use of memory to store the picture
3) editing of picture is not possible in picture box
4) Not having auto size property
5) Having stretch property
Main Difference:
The Image control is a lightweight control that has no device context (or hDC) or it's own. The Picturebox does have a device context and hDC and is a true "window" from the point of view of the Windows operating system (and can directly use "hWnd" parameter API calls).
Due to this difference, an Image control can display a gif file loaded into the picture property with a transparent background, while a picturebox does not. The Picturebox, however, doesn't "flicker" when moved at runtime like an Image control does. This difference also has implications for layering -- a lighweight control (like the Image control) can only be z-ordered (layered) over another lighweight control --but never over a true window like the Picturebox control. The Image control is also "lightweight" in terms of it's memory footprint (versus the
Picturebox control which is "heavier" even without the extra memory backbuffer that is reserved with its AutoRedraw property set to True) --although with the amount of memory available in most modern computers, this doesn't usually make this much of a difference, but it might come into play with large control arrays containing large graphics that would force paging out to virtual memory (which, in turn, could effect the speed of game graphics).
An Image control has Stretch property, a Picturebox control does not.
Picturebox control has an AutoSize property, an Image control does not.
However code workarounds can substitute for these two missing properties in either/both.
Both controls use a StdPicture object to store graphics and so Picture.Render and LoadPicture/SavePicture will work with both (but PaintPicture only works with the Picturebox control).
A Picturebox control is a container control, an Image control is not.
A Picturebox control also has a whole bunch of properties that an Image Control does not - BackColor, FillColor, FillStyle, etc.
The long and short of it [IMHO] is that the PictureBox control is the more generally useful of the two controls and used in conjunction with PaintPicture or the Bitblt/Stretchblt/AlphaBlend APIs can do just about anything you could want with graphics.
DirectX surfaces may be slight faster way of manipulating graphics, but when using Direct Memory Access (DMA) pixel manipulation techniques with Picturebox control graphics --it can be relatively quick..and works even with older non-Directx compatible video cards/systems.