Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
Yes, more or less. If rotation is used or Aspect was not ActualSize, then you could get different results. Also note that you do not need to Refresh if the control and its container are not hidden
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
26 Nov 2011, version 2.1.29: Bug reports welcomed, enhancement requests will be considered
Well... your component is Excellent, no doubt... and I hope you'll consider my formal enhancement request below:
I'm not trying to turn your component into a Graphical Program. I'm trying to use it to replace the Vb6 PictureBox wich can't read PNG. I made some game in past that use the Vb6 Picture Box and some Bitblt call to add a small picture over a bigger picture. (I use 2 bitblt call and a mask to make it transparent)
I would like my game to be converted to use png instead of bmp.
It seem that everything I tried failed and I was wondering if adding a bitblt function that would use as input source a GDIpImage and as dest the component itself.
something like:
Code:
Public Function BitBltDc(ByVal plngPosX As Long, ByVal plngPosY As Long, ByVal plngWidth As Long, ByVal plngHeight As Long, ByVal phwnSrcDC As Long, ByVal plngSrcPosX As Long, ByVal plngSrcPosY As Long, ByVal dwRop As Long) As Long
Dim lngRetValue As Long
Dim lngDestDc As Long
Dim booWasSet As Boolean
booWasSet = False
If m_DC Is Nothing Then
Set m_DC = New cDeviceContext
booWasSet = True
End If
m_DC.UpdateDC True ' put 24bpp bitmap into DC & usercontrol to that DC
lngDestDc = m_DC.DC ' DC we use to paint on
lngRetValue = BitBlt(lngDestDc, plngPosX, plngPosY, plngWidth, plngHeight, phwnSrcDC, plngSrcPosX, plngSrcPosY, dwRop)
If (booWasSet <> False) Then
Set m_DC = Nothing
End If
BitBltDc = lngRetValue
End Function
I tried this, with and without refresh... the call to Bitblt is returning 1 (meaning it worked) but nothing appear on the image.
and voila, I plea guilty because I reeeeaaaaally would like you to help me out on this because I failed to make it work.
If you don't want to integreate this kind of function inside your component, I would understand, but some pointers to show me where I failed would be nice.
Bitblt is the only FAST drawing method that would solve all my problem (speed) using your component.
and the reason why I can't use separate image and overlay them like you did with the Clock Exemple, it's because I need to DRAG the image when I overlay too much component over, draging become slow. With Bitblt, the other image would be part of the current image and there will be no speed loss.
plzzzz!
btw, do you got a donation link ?
added:
Thanks for your answer... I rarely use stretch and never used rotation yet... but it's good to know...
dang I waited 2 hours for your answer and it was there but it was on a "new page" and I didn't saw it... pressing refresh every 5 minutes! lool...
Last edited by VbNetMatrix; Jan 4th, 2012 at 01:57 AM.
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
The GDIpImage class (the control's .Picture property) has a Render method. That method is very similar to BitBlt, StretchBlt and VB's PaintPicture: AlphaImgCtlx.Picture.Render... It appears your code sample is modifying my control & since I won't support that, my advice stops right here.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
Hi Lavolpe.
I have the most respect for your work and your code. I'm sorry if I offended you.
I read your rules in the begin of forum and although you "will not support custom change"
I know you have arbitration privilege to accept or not modification or suggestion enhancement request.
What I merely show in that code is that I learned enough with your component to understand better what kind of modification "could" be done if that was your wish.
but I understand your relunctancy to do so.
.Render seem to be the solution to my problem though...
just wish I learned about it 25 post ago...
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
sugestion enhancement:
When control aspect is scaled and you change the WIDTH or HEIGHT (not both) of the control,
would be nice if the other side (HEIGHT or WIDTH) would be changed too.
The control image is scaled properly, there is no bug, but when we scale we are ofen left to change the other size of the control to manually adapt to the actual size of the image.
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
The objGDIpImage.Render
require a DC (didn't find the full explanation of the syntax) but I assume it's the Source Dc...
since my other source is also another Lavolpe Component... I'm still stuck
Not having a Dc for your component by choice, I understand, you made it clear why you choosed to NOT add the DC public. and it make perfectly sense too.
but I need to .render (bitblt) 1 Lavolpe Component over another Lavolpe Component.
and because you're the Guru of that component, I'm asking kindly for your help ...
any Idea "HOW" I can do what I'm required to do ?
just some pointer would be nice...
Last edited by VbNetMatrix; Jan 4th, 2012 at 02:43 PM.
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
Regarding setting the width or height & have the other change automatically. Nope. What if someone does want a non-proportional sizing? Then they would have no way of doing that.
.Render in a BitBlt manner can be done at least 2 ways.
1. Extract the goldfish png from the animation sample project
:: add that project to the alpha image control project & open its main form
:: display the custom property page for the control that has the goldfish
:: right click on the displayed image in that property page & choose to export the image to file
:: close that project & done
2. Start a new project. Add 1 alpha image control, 1 command button, 2 pictureboxes, 1 timer
3. Rename Picture2 to: picBuff
4. Add the Goldfish png to the AIC
5. Copy & paste this code
Code:
Option Explicit
Private tileCx As Long
Private tileCy As Long
Private Const tileCount As Long = 20
Private tileIndex As Long
Private Sub Command1_Click()
tileIndex = 0
Timer1.Interval = 50: Timer1.Enabled = True
End Sub
Private Sub Form_Load()
Me.ScaleMode = vbPixels
Timer1.Enabled = False
With AlphaImgCtl1 ' the goldfish png is 20 horizontal frames
.Visible = False
tileCx = .Picture.Width \ tileCount
tileCy = .Picture.Height
End With
With picBuff
.Visible = False
.BorderStyle = 0
.AutoRedraw = True
.BackColor = vbBlue
.Move 0, 0, tileCx, tileCy
End With
With Picture1
.BorderStyle = 0
.Move 10, 10, tileCx, tileCy
End With
With Command1
.Move 10, Picture1.Top + Picture1.Height + 10, tileCx, 35
.Caption = "Start Animation"
End With
End Sub
Private Sub Timer1_Timer()
picBuff.Line (0, 0)-(picBuff.ScaleWidth, picBuff.ScaleHeight), picBuff.BackColor, BF
AlphaImgCtl1.Picture.Render picBuff.hDC, , , tileCx, tileCy, _
tileCx * tileIndex, , tileCx, tileCy, , , , , lvicNearestNeighbor
Picture1.PaintPicture picBuff.Image, 0, 0
tileIndex = tileIndex + 1
If tileIndex = tileCount Then tileIndex = 0
End Sub
2. Similar, but we'll use the SegmentImage method to break the image up into 20 images. This doesn't actually modify the image, just the way it is used. This option only works if your image can be viewed as several tiles, all the same size, combined to a single image
Code:
Option Explicit
Private Const tileCount As Long = 20
Private Sub Command1_Click()
AlphaImgCtl1.ImageIndex = 1
Timer1.Interval = 50: Timer1.Enabled = True
End Sub
Private Sub Form_Load()
Me.ScaleMode = vbPixels
Timer1.Enabled = False
With AlphaImgCtl1
' the goldfish png is 20 horizontal frames
.SegmentImage 1, tileCount
.AutoSize = lvicSingleAngle
.Refresh
.AutoSize = lvicNoAutoSize ' else control size will be checked every frame
Set .Container = Picture1
.Move 0, 0
.Visible = True
End With
picBuff.Visible = False ' not used in this example
With Picture1
.BorderStyle = 0
.Move 10, 10, AlphaImgCtl1.Picture.Width, AlphaImgCtl1.Picture.Height
.BackColor = vbBlue
End With
With Command1
.Move 10, Picture1.Top + Picture1.Height + 10, AlphaImgCtl1.Picture.Width, 35
.Caption = "Start Animation"
End With
End Sub
Private Sub Timer1_Timer()
AlphaImgCtl1.ImageIndex = AlphaImgCtl1.ImageIndex + 1
End Sub
Edited: A 3rd method that combines the 2 above
Note that the AIC won't be used, but one needs to be on the form. In this example we are using a GDIpImage class directly
Code:
Option Explicit
Private Const tileCount As Long = 20
Private m_Image As GDIpImage
Private Sub Command1_Click()
m_Image.ImageIndex = 1
Timer1.Interval = 50: Timer1.Enabled = True
End Sub
Private Sub Form_Load()
Me.ScaleMode = vbPixels
Timer1.Enabled = False
Set m_Image = LoadPictureGDIplus("C:\goldfish.png") ' change filename as needed
' the goldfish png is 20 horizontal frames
m_Image.SegmentImage tileCount, 1
With picBuff
.Visible = False
.BorderStyle = 0
.AutoRedraw = True
.BackColor = vbBlue
.Move 0, 0, m_Image.Width, m_Image.Height
End With
With Picture1
.BorderStyle = 0
.Move 10, 10, m_Image.Width, m_Image.Height
End With
With Command1
.Move 10, Picture1.Top + Picture1.Height + 10, m_Image.Width, 35
.Caption = "Start Animation"
End With
End Sub
Private Sub Timer1_Timer()
picBuff.Line (0, 0)-(picBuff.ScaleWidth, picBuff.ScaleHeight), picBuff.BackColor, BF
m_Image.Render picBuff.hDC
Picture1.PaintPicture picBuff.Image, 0, 0
m_Image.ImageIndex = m_Image.ImageIndex + 1
End Sub
Last edited by LaVolpe; Jan 4th, 2012 at 04:38 PM.
Reason: added another option
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
WouHou!
nice coding... I'm in love now....
Regarding setting the width or height & have the other change automatically. Nope. What if someone does want a non-proportional sizing? Then they would have no way of doing that.
Since the part that are not exposed to the image remain "transparent" with nothing inside... I'm not quite sure why someone would need that. But your logic can be applied to almost anything... "what if someone want it"
That raise this question: Got any idea how I could get the real "size" of the image once I stretched one side in SCALE mode ?
and THANKS YOU very much for that bit of code, I'll try it as soon as possible... (now I have to go for some errand so I'll be less demanding
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
Originally Posted by VbNetMatrix
That raise this question: Got any idea how I could get the real "size" of the image once I stretched one side in SCALE mode?
Kinda out of luck there. Within the control the m_Size.Width & m_Size.Height are the scaled sizes the control uses to render the image. Those values are not exposed to the user.
The values also may not be exactly as one would expect. For example. If the AutoSize & Aspect properties are zero and the control is smaller than the image, then the m_Size.Width & m_Size.Height will be the actual image size. However, the image is clipped by the smaller control and whether or not AlignCenter is True/False, Rotation is used or not, the size of the visible non-clipped portion of the image can be different. The coordinates where the image is rendered also are not exposed. They are dependent on rotation, the optional XOffset & YOffset properties, AlignCenter property, and the scaled image
You can estimate the size of the image by using the global GetScaledImageSize function. Calculating the scaled size is complicated. The control's sptGetScaledSizes function is where it all happens.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
Originally Posted by vbNetMatrix
about post 348: I think I found what cause the problem with the size...
I changed the size of the picture while the form was hidden and the size of the component change only after the refresh (Show) of the picture...
is that normal behavior ?
Originally Posted by LaVolpe
Maybe ... a bit of tap dancing
The Show event of the usercontrol activates when it is first shown. Well on hidden forms or if the control's visible property is false, then that event won't trigger. The sizing routines of the control occur in the Shown event....
The change to the Refresh method I suggested will NOT be included in the next update. This sizing issue should be automatic, not up to the user to "fix" by a call to Refresh. I see where the problem is and will patch it.
Last edited by LaVolpe; Jan 5th, 2012 at 09:42 AM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
cool, perfect...
I really like the big help you provided in the last few days...
it was nice of you because it was a little bit outside of the normal requirement for your control.
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
Control updated today. See post #1 for more info. Significant changes:
- added ability to load icons associated to system file objects
- added a unicode-capable 'browse for folder' dialog class
- fixed minor resizing issue noted in previous few replies above
- updated the SavePictureGDIp & LoadPictureGDIp RTF files
Edited. Patched again 8 January, 1 day later.
When I added associated icon capability, I didn't include that ability for dragged/pasted files onto the property page. Done.
Last edited by LaVolpe; Jan 8th, 2012 at 08:25 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
Hot patch until next update is released. If using one of the generic folder icons provided from the property page at design-time, it is possible that the 32x32 & 48x48 sizes will be saved in PNG format. The alpha image control & Vista+ can read PNG formats in icons, but XP and lower cannot. Also, the 16x16 icon for an "opened" folder is not returned. Suggest making these corrections:
What? The property page: ppgCustom
Where? LoadSampleImage
Actions made to only ppgCustom.LoadSampleImage
1) Find & delete this line: MIS.Image(8 + icSize).IconEmbeddedAsPNG = True
2) Find & delete this line: MIS.Image(8).IconEmbeddedAsPNG = True
3) Find this line: If cboLoadType.ListIndex = 2 Then
4) Add these 3 lines directly after that line:
5) Find this line: AI.IconType = AI.IconType Or lvicAssocIconOpened
6) Add this after that line: AI.DesiredSize = lvicSHIL_Small_16
Done
Senior-moment here. I added the UnicodeBrowseFolders class to the project but forgot to make it public so you can use it from within your code. So, open that class in IDE. In the property sheet, find the Instancing property & change its value to 5 - MultiUse
Edited: Apologize for the inconvenience. Supporting associated icons required significant code modifications throughout and there is a chance, other minor bugs may pop up due to those modifications.
Last edited by LaVolpe; Jan 9th, 2012 at 02:11 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control (PNG, AniGIFs, TIFF, & more) [26 Nov 2011]
good work finding theses out Lavolpe.
thanks
kontolimansyah: thanks. I wanted to include my Autofix program but EXE are not allowed would have been of good use for Lavolpe Hot Patch though... would be simpler...
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
NOTICE :: NOTICE :: NOTICE
Version 2 of the control came to an end & final update posted today. No new enhancements will be added to version 2 -- ever. Bug fixes may be applied as they are discovered. Support for version 2 will eventually cease.
Version 3 of the control will replace version 2 and will be DPI-aware. This will result in how images are loaded and displayed on a PC based on DPI settings (XP and above). In the case of icons/cursors, it may also result in which sized icon is displayed, based on current DPI settings. Externally, how you use this control will not change very much. Internally, a logical coordinate space will be used for all measurements and storage of properties, unlike the physical coordinate space now used. Like VB, this control will use twips internally. Externally to control users, pixels will still be used. DPI awareness will also be a customizable property. To properly support DPI-awareness, binary compatibility will be broken; hence a new version.
When version 3 is available, I'll start a new thread for that control and I'll link the two threads to each other. For the most part, I will stop responding on this thread at that time. Since the functionality of the two versions will be nearly the same, any questions pertaining to one version will apply to the other version, so only Version 3's thread will be used.
To all, thank you for your inputs and suggestions. I think over the past year and a half, a very nice control has been produced.... On to Version 3 and no immediate release date is known.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by Cube8
Can you explain which parts of the interface will change, that will cause binary compatibility to break?
Primarily, it will be saved settings. Version 3 will be expecting saved values in twips vs. pixels. That means it won't be backward compatible any longer; though binary compatibility really isn't broken at that point. Nevertheless, knowing this, I have the freedom to modify the control any way I want, and that will break binary compatibility. Internally, much of the code will need to account for DPI. Many of the internal functions will now be using single precision vs. long when dealing with GDI+ functions. Converting version 2 to use DPI and keep compatibility (binary or backwards) will be just too much in my opinion. Those are probably the major points; there are more.
Insomnia is just a byproduct of, "It can't be done"
Actually, increasing the DPI setting, while keeping the same resolution, makes everything bigger and the object dimensions are calculated differently...
Actually, increasing the DPI setting, while keeping the same resolution, makes everything bigger and the object dimensions are calculated differently...
Correct. To put into perspective for this control....
The logic behind DPI is simply scaling. The higher resolution monitors we have nowadays, applications built under normal DPI of 96 may look tiny on the big screens. So XP started user-optioned DPI settings. Vista continued this option but added DPI virtualization. Windows 7 went one step further and can automatically implement DPI scaling and virtualization.
Standard DPI settings are:
Normal is 96 or a 1:1 ratio, 1x scaling of the object's dimensions
1.25x scaling is 120 DPI
1.5x scaling is 144 DPI
1.75x scaling is 168 DPI
2x scaling is 192 DPI
Scaling factor = (DPI / 96)
A bit off topic: DPI virtualization is nasty in my opinion and your app looks worse under it. It can be disabled automatically by telling Vista/Win7+ that your app is DPI-aware via a manifest. It can also be disabled manually by the user. Under DPI virtualization, your app is lied to an told that the user DPI is 96. Your app works just fine, so you think. But before it is displayed to the user, Windows will stretch the entire app by the DPI scaling factor and display that. To get an idea of what your 96 DPI app would look like at a DPI of 144, virtualized. Simply screen capture your app and stretch that capture by 150%.
Loading Images. Most modern image formats can store resolution/DPI information the image was created in. When an image is loaded, the DPI of the image is not important. The source DPI, along with the screen DPI, is used when rendering.
FYI: GDI+ will report current screen DPI as the image's source DPI if the image does not contain that info.
Rendering Images. A standard formula that uses both source/image DPI and destination/screen DPI is:
DPI forces one to consider dimensions in two coordinate spaces: logical and physical. The physical dimensions are the actual image dimensions at the DPI the image was created in. The logical dimensions are calculated based on the destination and/or source DPI values. Typically, you'll find images with non-normal DPI created from scanned pictures and also metafiles are known to be other than 96 DPI.
Real world examples follow:
1) JPG. Physical size is 2100x2250 at 300 DPI
Rendered size in some DPI aware applications at 96 DPI: 672x720
You'll notice the size is about 1/3rd the physical size. Just plug in the values into the formula provided.
Same JPG displayed at various screen DPI settings:
@ 96 DPI: 672 x 720
@120 DPI: 840 x 900
@144 DPI: 1008 x 1080
2) WMF. Physical size is 1542x1877 at 1000 DPI
Rendered size in most applications at 96 DPI: 148x180
You'll notice the size is about 1/10th the physical size
Same WMF displayed at various screen DPI settings:
@ 96 DPI: 148 x 180
@120 DPI: 185 x 225
@144 DPI: 222 x 270
With the above two examples, if you notice, all rendered sizes are smaller than actual size. However, the quality will be very good because the image is being scaled down. The WMF is a vector format so it will scale well, regardless what direction scaling takes.
Notes about above examples:
a) VB does not render images this way. The exceptions are metafiles. If you load, into a VB image control, a jpg or bitmap containing source DPI info, the loaded image will be the physical size, not the logical size. However, for metafiles, the opposite is true. Why treat one image format different from the others? Rhetorical question. Maybe it is a vector vs. raster thing?
b) Using the source/image DPI will probably be default in the updated control. Microsoft Word uses this option, but VB does not. Let's say you scanned a 3x5 inch photo at 300 DPI resulting in an image 900x1500 pixels. Do you display an image on a 96 DPI monitor at 900x1500 (result is about 9x15 inches viewed) or do you use our formula and display it at 288x480 (result is 3x5 inches viewed)? I am leaning in the favor of how Word would display the image vs how VB would. After all, the source image is 3x5 not 9x15.
I'd say a majority of images out there are created without any DPI information stored. This is a decision maker. What value do you use for the imageDPI parameter of our function if option chosen to honor the source DPI? Well, GDI+ returns the screen DPI as the image DPI. This option, in effect, keeps the image the same size regardless of the screen's DPI settings because the two DPI settings cancel each other out in the formula. The image will never be scaled due to DPI. Another option is to default to 96 DPI when the image DPI information is missing. This option ensures image is scaled with various screen DPI settings. The control will handle it this way. If image loaded on a 96 DPI screen setting and no source DPI exists, the image will be considered 96 DPI as long as it is in the control. If it were loaded on a 120 DPI screen, then it would be considered 120. This DPI setting will travel with the control and the image will not be modified.
For this example, we'll use a 256x256 image that was created with unknown image DPI, substituting the unknown with default 96 DPI (the screen setting at time it was loaded at).
2) PNG. Physical size is 256x256 displayed at various screen DPI settings
@ 96 DPI: 256 x 256
@120 DPI: 320 x 320
@144 DPI: 384 x 384
With the above example, if you notice, all rendered sizes above the source DPI are larger than actual size. Image quality will not be as good since we are scaling upwards. Lower quality images obviously results in lower quality scaling.
What's the big deal?. You may ask why I feel this is important. Good question. VB is DPI aware for the most part. Any application you build at normal DPI will be scaled larger, including controls, under higher DPI. VB automatically scales many controls, including VB-created usercontrols and there are some exceptions. So, in 96 DPI, you have my Alpha Image Control on a form and it is displaying a nice 256x256 image at full size, no scaling/stretching. What happens when you turn your screen's DPI to 120? VB will resize the image control to 320x320 and also scale/position your other VB controls by 125%. The image rendered in my control is still at 256x256 because it is not DPI aware. If it were DPI aware, the image would be scaled to 320x320 also. It may not look ideal being scaled up, but every other thing in your application is scaled up 125% except the image. Which is worse? That being said, when I modify the control, the DPI awareness can be customized.
Note: DPI may not be a player when the alpha image control's Aspect property results in stretching/scaling the image. This is because VB resizes the controls and the Aspect property stretches/scales the image to the control's size.
In summary. Applications you build at 96 DPI, most likely will be displayed at higher DPI on systems today. This is partly due to much larger screens, users wanting tiny apps looking bigger, and newer operating systems changing DPI automatically. Any custom built control should be DPI aware in my opinion.
Last edited by LaVolpe; Jan 24th, 2012 at 08:41 AM.
Reason: typos
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
that was a very well done explanation on the subject. Thanks Lavolpe, it made me understand the context on the necessity of DPI awareness and what it would change in the control behavior.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
For the users of this control -- good news. I will be able to maintain binary compatibility after all.
The next update which will be v3.0.0 will be DPI-aware by default. For backwards compatibility, any previously compiled version of the control will still work with the new version; however, that previous version will not be DPI aware. This simply means that for existing compiled applications using the old version of the control, will continue to work as they always have worked when the new version replaces the old version.
Recap. Odds are significantly increasing that your app will be scaled due to user-defined or O/S-opted DPI settings. This control will be designed to automatically scale its contained image with the system DPI and will also have options to allow you to override default behavior.
Image DPI scale. The intent of using this DPI is to scale the image so that it is the same size as the source image. If a 3x5 inch image was scanned in 300,600,1200 DPI, it will appear as 3x5 inches on the screen at any DPI even though the physical size of the image may be 3,6,12 times that. Screen DPI scale. The intent is to keep your images the same size relative to the screen they are displayed on. If an image is approximately 1/10th of your screen size, it will remain 1/10th of your screen at any screen DPI setting
The new version will handle DPI this way. 4 DPI options will be available
lvicNoDPIAwareness: No scaling, same as v2.x.x
scaledImageSize = physicalSize
lvicAutoDPIAwareness: (Default) Both screen and embedded image DPI used for scaling.
The above options can result in the same image being displayed in 4 different sizes if the screen and the embedded image DPI are other than 96 DPI.
Example: JPG image at 600 pixels wide created in 300 DPI and displayed on a 120 DPI screen
lvicNoDPIAwareness: width = (600 * 1) / 1 = 600 [same physical size on all DPI screens]
lvicAutoDPIAwareness: width = (600 * 120) / 300 = 240
lvicIgnoreEmbeddedDPI: width = (600 * 120) / 96 = 750
lvicUseOnlyEmbeddedDPI: width = (600 * 96) / 300 = 192 [same physical size on all DPI screens]
*[same physical size on all DPI screens] = image size is not scaled with your other controls when DPI changes
There is an issue if you opt for lvicNoDPIAwareness or lvicUseOnlyEmbeddedDPI which ignores screen DPI. Let's say you develop your app in a 120 DPI screen. When app is displayed on a 96 DPI screen, VB scales the control smaller for the lower screen DPI. This means your images, ignoring screen DPI, will probably be clipped by the resized control. To prevent this, may need to add yet another option to always scale when screen DPI is smaller than development DPI. Maybe something like this....
lvicDPIscalingForbidden: When design-time screen DPI is higher than current screen DPI, the following overrides will be automatic unless lvicDPIscalingForbidden is selected
If lvicNoDPIAwareness is desired: scaledImageSize = (physicalSize * screenDPI) / 96
If lvicUseOnlyEmbeddedDPI is desired: scaledImageSize = (physicalSize * screenDPI) / imageDPI
If lvicAutoDPIAwareness is desired: no change in logic
If lvicIgnoreEmbeddedDPI is desired: no change in logic
Another option that will be considered is to allow you to dictate your own screen and/or image DPI values which will override actual values. This option will allow you to scale images relative to some other device, say a 600 DPI printer for example. I can foresee this being used in some sort of print-preview type of display.
Note: When the Aspect property of the control is other than 'ActualSize', the image is being scaled/stretched to the control. VB will resize the control based on DPI and the image will then be scaled/stretched to that adjusted control size. Version 2.x.x of the control behaves the same way. The overall effect is that DPI awareness does not apply in this situation, other than VB scaling the control dimensions based on screen DPI.
How to make v2.x.x DPI-aware when Aspect is 'ActualSize'? This can be faked using the following logic
a) No optional XOffset or YOffset settings
b) Set Aspect to ActualSize
c) Set AutoSize to SingleAngle
-- previous 2 steps ensure control is sized to actual image size
d) Set AutoSize to NoAutoSize
e) Set Aspect to Scaled
f) Do not manually modify the size of control hereafter
Now when VB resizes the control based on screen DPI, your image will scale proportionally with your other controls
Last edited by LaVolpe; Jan 25th, 2012 at 10:38 AM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Hi Lavolpe,
I've stumbled upon a strange bug involving resize (stretch) and interpolation: Nearest Neigbourg.
at some point, the control is resized but not the content of the control. Meaning we got 1 pixel with a full Alpha channel. It seem to occur only when the control is wider then HALF the screen size.
I thought you would be interested in seeing it into action.
I made a small image and loaded it in a Lavolpe control and also in an image control,
then, by clicking the button, it decrease both control.
The bug is not random but it appear only on specific size wich I failed to recognize any pattern.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by VbNetMatrix
I thought you would be interested in seeing it into action.
Always interested in bug reports. Good timing too. The DPI-version of the control is nearly completed. I'll be taking a look-see.
Follow up #1. I'll look at this a bit more, but am already thinking it may be out of my hands.
1) If you run your sample project again. Whenever the widths appear different, force a repaint. For example, move another window on top of yours & then move it off your form.
2) You will notice that the control painted as expected on the repaint
3) Internally, I looked at 4 routines to see if possibly there were any calculation errors that would result in 1 less pixel being painted. But there isn't any errors. When it gets to the last line of code that actually draws the image, the dimensions to be drawn are correct.
Follow up #2. I am going to play with another idea to see if results are more reliable.
Ideas: Not the answer you are looking for, but in these cases where you are trying to use the control as a border/line by stretching an image, you may choose to use a VB image control instead. Even though the AIC may not be ideal for all situations, it is flexible enough for anyone to draw anything they want into a standard bitmap & load that into the AIC. You can stretch the image to a normal bitmap/DIB via StretchBlt and load that into the Alpha Image Control.
Last edited by LaVolpe; Jan 28th, 2012 at 10:24 AM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
I know a Vb Image control could do it, but I would prefer using PNG !
I also though about a possible cause...
I noticed that when VB use screen resolution it use SINGLE type, even if the screen size is in fact a LONG value. This might be because internally it's converting to twips.
if then SO, if your control use LONG instead of SINGLE for the size. it might lose resolutions when internally converted to twips ?
I know it's a long shot...
If you could tell me where to look inside the code, I could make some test. I have no intention of modifying your control, I just want to check out if the bug could be there. Knowing the 4 functions you mentionned in previous post, I might be enable to spot something you missed (no hard feeling intended)
I'm a decent programist, but your control is just too wide project to be looked at in an easy way and I currently don't have the time to process the whole package, I'm in the middle of university class. So, if you could just point out the function you were looking, I might have some luck.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by VbNetMatrix
I know it's a long shot...
That's not it. I checked the render command. The size of the stretch is correct. I checked in 3 different places. It also would not explain why it would paint correctly simply by covering up the form with another window and uncovering it.
Rounding with single vs long may be a player if you were reducing the size by a fraction of a TwipsPerPixelX but not by a whole TwipsPerPixelX. A whole TwipsPerPixelX is a single pixel. The screen is pixels, regardless of scale mode.
I thought maybe it had to do with drawing directly to the screen. But using FastRedraw property (off screen buffer), same results. It is a GDI+ thing or another bug with VB and windowless controls, and I'm convinced of it now. If you want to double check things yourself, look at this line in the Usercontrol_Paint event. m_Size.Width is the stretch width
Note: If you wish to use a VB image control instead, for this particular case, you can still do that and continue to use a PNG file. You would load the png into a GDIpImage class, then save it to an initialized stdPicture object which would then be set to your VB image control.
Last edited by LaVolpe; Jan 29th, 2012 at 12:08 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
I'll check it out promptly, in the mean while, if you have time I would apreciate some code for the img control to load object with a png picture. graphic programming is not my high point...
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by VbNetMatrix
I'll check it out promptly, in the mean while, if you have time I would apreciate some code for the img control to load object with a png picture. graphic programming is not my high point...
Image control cannot contain PNG, but a PNG can be converted to bitmap which image control can do...
Code:
Dim tGDIpImg As GDIpImage, tStdPic As stdPicture
Set tGDIpImg = LoadPictureGDIplus(yourFileName)
Set tStdPic = New stdPicture
If SavePictureGDIplus(tGDIpImg, tStdPic, lvicSaveAsBitmap) Then Image1.Picture = tStdPic
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
thanks a lot for the code... very appreciated.
While debugging and searching for the problem, I realized that something (enhancement) would be verrrrry nice to have in your control.
So I'm making this very nasty little demand for enhancement request:
When using the LOAD from the control at design time, it "could" be nice if the name of the file were saved into the control for later reference. not the full path, but just the "original" file name it would be a property that would be mostly useless, unless you're debuggin (or developping) I got 2 images almost identical and at some point I was wondering wich one caused the problem and I couldn't remember wich one I loaded last... I have to restart all the test from the begining... *grin*
well.. it is asked... doesn't cost me to try! I can however see many practical use of that information.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
a little off topic, but for thoses who had in past a similar problem as we previously discussed with the "TOp vs Top" property... I found a verrrrry nice and easy way to fix this kind of problem.
at first I was wondering why changing the property name didn't work when saving... so I look inside VbExe code... (did I said that out loud?!... and I found out that Vb does a lowercase comparaison when deciding if property should be saved or not...
so making a short story how to fix a problem like TOp vs Top, I'll give you an exemple and apply to your case.
Exemple:
property or any VbName: "MyVbNamE" you want to change it to "MyVbName"
VERY IMPORTANT: DO ALL THE STEP. Otherwise you risk having a "CONFLIT NAME DETECTED on next projet opening. If that happen, follow the step to fix it. (below)"
1. Change MyVbNamE to MyVbName and HIT SAVE
2. Change MyVbName to MyVbNameX and HIT SAVE
X being any letter you want to add... doesn't matter
3. Change it back from MyVbNameX to MyVbName and HIT SAVE
now, exit the project, open it again and Voila!
for thoses who WONDER why not only 2 step... that's because of the way Vb Save the project... if you don't do all 3 step, he will only save it at 2 place inside the file and you risk having a "conflit name detected" wich is easy to fix by doing the process all over again, but it's pretty annoying.
in the case though when re-opening the project, you receive a msg saying:
--> Conflit name detected, "MyVbName" will be used. <--
it mean you didn'T properly follow the 3 step. That's a bummer... now you'll have to start your project from scratch, it's ruined... just kidding.... you can RETRY the method previously discuss, it should fix the problem... if not... continue reading.
that bugged me at first... but I found out why. This happen only if you modify a CLASS name (not property) or a Form Name or other major class element without following the EXACT 3 step I described above.
This is because Vb store theses name in 2 places (duh) and to fix this, you'll need to manually change the second name wich is the SAME but with a different case... funny, Vb does a Lowercase comparaison when saving but is case sensitive when loading... another Microsoft funny joke
so to fix it, easy: look inside the Vbp file if it's a class name or a form name, change the case of the name. Something like:
Module=mod_MyVbNamE; MyFile.bas
look also in the frm file, there is 2 declaration there:
in the first few line you got something like:
Begin VB.Form MyVbNamE
and later one BEFORE the module coding, you'll get:
Attribute VB_Name = "MyVbName"
just make both name the same.
but really... the 3 easy step are more fun unless you like playing with your file OUTSIDE Vb... wich is often not a good idea.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Thanx for the bug report. Solution shown below & will include in next update
1. Bug: Mirroring losing 1 or 2 pixels. A calculation error & not sure why I did it the way I did. I'll have to see if this patch breaks when rendering with rotation and/or GDI+ v1.1 effects, or if it was a even/odd image size issue.
In the cGDIpImage class' Render & RenderSkewed functions, you will see 2 places in each routine where the width & height are being adjusted when mirroring. Change them to remove the subtraction of the 1&. Easy enough to locate, look for testing of srcWidth & srcHeight < 0
Code:
' example
If srcWidth < 0& Then srcX = imgCx - srcX - 1&
If srcHeight < 0& Then srcY = imgCy - srcY - 1&
2. Regarding your filename suggestion. It's a bit more complicated than that. The control doesn't know the filename, ever. The property page extracts the file data and creates an image from that & passes the parsed image to the control. The control only receives a byte array, never a file name. Why? Simply put, the property page can accept files, drag/drop & pasted data too which can be URLs, clipboard items, Base64 text & other things that are not files. Additionally, the control would need to be modified even further to save it to a property bag, retrieve it, and display it via a property. The file name is only useful possibly for debugging.
If your main concern is for debugging in IDE, I'd recommend this
Object: ppgCustom
Routine: cmdBrowse_Click
Modification: In the sections for Case 0,1,2 add a Debug.Print statement after the browser returns
However, the above won't apply once the control is compiled as Debug statements are not compiled
Last edited by LaVolpe; Feb 9th, 2012 at 01:10 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
thanks Lavolpe for the Bug fix, I'll apply immediately and await the next version for official Fix.
as for the FileName, I understand perfectly I didn't looked at the code before making the request.
a debug.print won't help though. Sometime I'm playing with a version of a file and then only a few days later I change it to something else and I lose track of wich file I used after a few changes... as they are almost identical, it cause me to doubt sometime... I'll have to be more carefull about documenting each time I change the file
thanks for having answered my request though. I apreciate.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
refering to post #392,
I tried it... work... but it set the transparency to WHITE Color... any way I can change that behavior to adopt "background" color of the control (I used a picture box instead of an image control)
Both control (image box and picture box) have the same behavior.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by VbNetMatrix
refering to post #392,
I tried it... work... but it set the transparency to WHITE Color... any way I can change that behavior to adopt "background" color of the control
Yes, supply a SAVESTRUCT as the final parameter to SavePictureGDIplus
Code:
Dim tGDIpImg As GDIpImage, tStdPic As stdPicture, SS As SAVESTRUCT
Set tGDIpImg = LoadPictureGDIplus(yourFileName)
Set tStdPic = New stdPicture
SS.RSS.FillColorARGB = ConvertRGBtoARGB(Picture1.BackColor)
SS.RSS.FillColorUsed = True
If SavePictureGDIplus(tGDIpImg, tStdPic, lvicSaveAsBitmap, SS) Then Picture1.Picture = tStdPic
The SAVESTRUCT allows you to pretty much override any "normal" behavior while saving
Last edited by LaVolpe; Feb 11th, 2012 at 12:32 PM.
Insomnia is just a byproduct of, "It can't be done"