Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
I still doubt GDI+ has anything to do with it. As far as I know GDI+ does not hold a reference to anything in a VB project. VB will shut down when all running code has terminated and all objects are unloaded (circular references are almost always a culprit). GDI+ is not an object. This may be appropriate to post in the VB discussion forums if you'd like others to help troubleshoot and brainstorm.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
georgekar, can you be more specific with the temp file not erased ?
because VB6 IDE always had that habit of not erasing temp file, it is a bug per say but MS never fixed it, it doesn't crash anything... they just forget to make a delete temp file on exist IDE.
btw, on my side, never had any GDI+ problem on Win8, I made a commercial product wich is run on hundred of computer, nobody reported any problem or suspicious crash. can you be more specific about the problem ? maybe I can help you troubleshoot. Is it a EXE problem or a IDE problem, can you make a "small" sample that reproduce the problem even intermitently ? If it's a IDE problem, are you sure you installed Vb6 properly, on Win8 there is some precaution to do to install Vb6, it is more easier on Win7... just realize this might not be the right thread for this but I'm open to more detail if you need help
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Lavolpe am a great admirer of his work now use your LaVolpeAlphaImg2 control.
How do I select a region on the control to cut and save.
Thank you and sorry for my English "google"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Here's a quick and easy way to do what I think you are asking for.
1) Add a picturebox to your form. Set these properties: Visible=False, BorderStyle=0, ScaleMode=Pixels
You can place the picturebox anywhere you want, out of the way. You may want to make it visible until you are satisfied that what is being captured is correct, then make it invisible forever.
2) Draw the image to the picturebox USING THE SAME scale, zoom, angle, etc that you were using in your screenshot... I'll call that picturebox PicCanvas
Code:
Dim X as Long, Y as long, Cx as Long, Cy As Long
Dim tPic As stdPicture
X = ? ' << set this to your selection rectangle's left edge (in pixels)
Y = ? ' << set this to your selection rectangle's top edge (in pixels)
Cx = ? ' << set this to your selection rectangle's width (in pixels)
Cy = ? ' << set this to your selection rectangle's height (in pixels)
With PicCanvas
.AutoRedraw = False
.Move .Left, .Top, [alphaimage control width], [alphaimage control height]
' ^^ The picbox must be exactly the same size as the alphaimage control
.AutoRedraw = True
' draw the image exactly the same way you drew it to the alpha image control...
AlphaImage1.Picture.Render .hDc, [fill in the parameters]
Set tPic = .Image
.Cls
.PaintPicture tPic, 0, 0, Cx, Cy, X, Y, Cx, Cy
Set tPic = Nothing
.Move .Left, .Top, ScaleX(Cx, vbPixels, Me.ScaleMode), ScaleY(Cy, vbPixels, Me.ScaleMode)
End With
Now you can see the result. May have to add this line for testing: PicCanvas.Refresh
If you are satisfied with the result, you can use VB's SavePicture command to save the .Image property of PicCanvas
Edited: I had some problems with VB PaintPicture if the selection rectangle overlapped the target area on the same picturebox. I've updated the code above to fix that problem (blue text)
Last edited by LaVolpe; Sep 4th, 2015 at 10:45 AM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Part of the problem is the Render call. You are using the control's dimensions when you should be using the control's Picture.Width,Height. Below I've changed the code a bit to use With, End With so you can see where you should be using the properties of the image and the properties of the control.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by LaVolpe
Part of the problem is the Render call. You are using the control's dimensions when you should be using the control's Picture.Width,Height. Below I've changed the code a bit to use With, End With so you can see where you should be using the properties of the image and the properties of the control.
See if that is better. If not, please post back with a snapshot so we can start fresh.
As I said previously, users need not only picture presentation but also picture Editor. you have to work harder to write a editor so that you won't leave your Graphic knowledge in dust.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Jonney, suggesting I write an editor? Sorry buddy, not interested. Plenty of them about but not enough alpha-supported image controls exist for VB which is why I developed this one and why I'll put out one more rewrite this year & that will likely be the last major revision. I'll support it for awhile, and may even enhance it from time to time. But an image editor won't be coming from me.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
The following is your previous code, just modified slightly to ensure scalmodes match
Code:
Dim x As Long, y As Long, Cx As Long, Cy As Long
Dim zoomOffset As Double, tPic As StdPicture
x = Shape1.Left + Me.DrawWidth - AlphaImgCtl1.Left ' get area inside the shape
y = Shape1.Top + Me.DrawWidth - AlphaImgCtl1.Top
Cx = Shape1.Width - Me.DrawWidth * 2
Cy = Shape1.Height - Me.DrawWidth * 2
zoomOffset = pnZoom.Tag / 100
With picCanvas
.ScaleMode = Shape1.Container.ScaleMode
.AutoRedraw = False
.Move .Left, .Top, AlphaImgCtl1.Width, AlphaImgCtl1.Height
.AutoRedraw = True
With AlphaImgCtl1.Picture
.Render picCanvas.hdc, (.Width - (.Width * zoomOffset)) \ 2 + AlphaImgCtl1.XOffset * zoomOffset, _
(.Height - (.Height * zoomOffset)) \ 2 + AlphaImgCtl1.YOffset * zoomOffset, _
.Width * zoomOffset, .Height * zoomOffset, , , , , AlphaImgCtl1.Rotation, _
AlphaImgCtl1.Effects.AttributesHandle, , AlphaImgCtl1.Effects.EffectsHandle(AlphaImgCtl1.Effect)
End With
Set tPic = .Image
.Cls
.PaintPicture tPic, 0, 0, Cx, Cy, x, y, Cx, Cy
Set tPic = Nothing
.Move .Left, .Top, ScaleX(Cx, .ScaleMode, .Container.ScaleMode), ScaleY(Cy, .ScaleMode, .Container.ScaleMode)
End With
It is important that the same Render parameters for the alpha image control is used above that you used in the control's PrePaint event. So if you are also adjusting the X,Y coordinates when rendering to the control, you need to adjust them in the code above too.
Edited: Ensure the scalemode that picCanvas is using is the same scalemode that Shape1's container is using. I added code for that, but any tweaks you need to make are likely due to mismatching scale modes.
Last edited by LaVolpe; Sep 5th, 2015 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)
Lavolpe, excuse my insistence, but it's because I have to deliver a job and all that's missing it in my project.
I am enclosing part of the project for you to analyze and see if you can'm WHAT wanting.
Thanks again for the help LaVolpe.zip
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Sorry. I have a thing, call it quirky, helping others make money off of my code. I've given you lots of help. I trust you can spend the time to troubleshoot that last issue.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Sorry, but I have expressed myself wrong when he said "work" was referencing "school work", do not know what the term used in your language, and if you can help me I will be very grateful, including its control along with the link of this forumIt is attached as a reference in my "school work".
But still I am very grateful with all your help so far and I take once again to congratulate his wisdom.
Ricardo Vieira Pulo (17 years - eighth computer technology class)
(São Paulo Brazil)
translation - google
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
I tried to explain this at least two times. If you want the correct result, your Render parameters must be the same in both the PrePaint and CmdCut events. They are not the same. If you fix that, maybe your problem can be resolved.
P.S. I could not load your project, could only look at the code. I do not have your version of the alpha image control, nor do I have the threed ocx. No biggie. I think your problem is related to the different rendering calls; thereby producing different results.
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 LaVolpe
Sorry. I have a thing, call it quirky, helping others make money off of my code. I've given you lots of help. I trust you can spend the time to troubleshoot that last issue.
about that... I always wondered why you don't have a "donation" button. I know I offered it to you in past but I would be very honored to offer you a web page host. All you have to do buy the domain (about 10$ per year) and I would web host your domain and you would have full control over the web page. I really apreciate your control, it's the least I could do. I would be glad to "donate" myself to you.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Hi, firstly thank you for your amazing code.
I am facing a issue when printing an image.
The code uses the same routines to draw either in the screen or in printer.
It uses the vb scale methods of own each object (picturebox or printer) to define de position given in millimeters.
However the render method of AIC just prints near the right position when I use the same coordinates used in the picturebox and add a magical offset (27 pixels horizontal and 43 pixels vertical)
More over the image was trimmed in the rendering.
The image was loaded from a byte array read from a data base field.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Looking at your screenshot. The picturebox rendering is correct? Obviously the Printer version is not. It appears the printer may be slightly scaling the rendering. I say that because 1-pixel edges when scaled can be lost or thinned out when scaling. Though you are not scaling the rendering, just assigning the X,Y printer coordinates.
I assume the printer's scalemode is pixels. You may want to check the results of your X,Y calculations and see if rounding may be an issue. Don't know if it will help or fix the problem, but try passing whole number vs fractions, i.e.,
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Finally I found a workaround for the printing issue.
To avoid that trimming of image happens, I created a picturebox 2 pixels wider (in both dimensions horizontal e vertical) than the image, then rendered the transparent GDIpImage with an offset of 1px and after i rendered in the printer DC.
On regards to position problem, I figured out that there is a difference between screen and printer. Coordinates in pixels used for the printer have to be increased in 4% to be correctly positioned. I still do not know the reason, but now is printing very fine.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Hello LaVolpe.
I didn't really understand the reason behind the size limitation to screen size when the selection of the Aspect is something other than lvicActualSize. Can you give some details?
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Don't have a great reason, but I'll give it to you. You cannot physically view more than the screen size. Very large images require large amounts of memory.
The control was not written with the idea that it could be used as a view port. There are limitations on the size of any image backed by a DIB or bitmap. Those limitations are not public from Microsoft as far as I know, but to avoid potential errors I simply took the easy way out, expecting this to a be a problem for a very small percentage of typical users.
In my rewrite of this control (still not close to publishing it yet), this is one topic I still haven't found a great solution for. I personally don't like the limitation. I am close to finalizing a solution that won't be perfect but would remove the limitation. The solution is basically to use GDI+ (which has its own methods of handling large images) and rendering on demand the viewable portion of the image. This solution could negate AutoRedraw for very large images because of the DIB size limitation imposed by Windows. I would expect rendering to be significantly slower in these cases, especially if AutoRedraw is not applicable and/or image appearance is changed during rendering: scaling, rotation, mirroring, gray scaling, etc. Very large images may not be able to be saved, without scaling, to other image formats where the format itself restricts max dimensions. All being said, if GDI+ balks at loading very large images, all bets are off.
In any case, I do always foresee a max data size of 2 GB as a permanent limitation.
Last edited by LaVolpe; Dec 13th, 2015 at 06:06 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Hello LaVolpe.
I am facing the following problem: in IDE (debug-time) I can load a picture to an Alpha Image Control from the picture property of a Standard Image Control, however when is in run-time (compiled) the error 481 - Invalid Picture is raised.
Code:
Set AlphaImgCtl1.Picture = LaVolpeAlphaImg.AICGlobals.LoadPictureGDIplus(Image1.Picture)
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
I'll take a look, but not likely in the next day or two. I am always interested in errors and bug reports.
In the mean-time, try passing the handle: Image1.Picture.Handle
Edited. A quick look, I was able to replicate the problem twice in a row. Then problem went away without doing a thing. I think I have it narrowed down, but will have to perform more tests. If I do figure it out (and I will), you will have to make the change to your copy of the control & recompile it. If this is the only issue and if passing only picture objects that contain bitmaps or jpegs, would recommend passing by handle vs the picture object. That way you won't have to modify the code, recompile, & redistribute the ocx.
Follow-up. To patch the bug:
Method: modCommon.pvProcessStdPicSource
Add this: bSaveMemCopy = True
Where:
Code:
...
If IPic.KeepOriginalData Then
....
Else
bSaveMemCopy = True ' << insert here
IPic.SaveAsFile ByVal ObjPtr(IStream), bSaveMemCopy, lResult
End If
...
Last edited by LaVolpe; Dec 14th, 2015 at 11:27 AM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Hello LaVolpe,
Can you check into the code of PhotoDemon - The open source photo editor. It supports very large image size. It is open source so you could study its source cod and implement interesting features in the new version.
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Originally Posted by yogiyang
Can you check into the code of PhotoDemon - The open source photo editor. It supports very large image size. It is open source so you could study its source cod and implement interesting features in the new version.
Very familiar with that project and the author. Not interested. My control is not designed as a photo editor, never will be. It is designed as a viewer. The goal was to expose the control to the user via properties and events so that the user can draw onto the control to customize the image all they want. That was always a shortcoming to VB's controls. The picturebox was the closest we came to custom drawing images.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Thank you for your -always- quick reply and for the answer.
I look forward for the new version of your control.
Very large images may not be able to be saved, without scaling, to other image formats where the format itself restricts max dimensions. All being said, if GDI+ balks at loading very large images, all bets are off.
What you describe couldn't happen even with this version of the control with a very large image size if Aspect is lvicActualSize ?
(I didn't test this since I don't know exactly how large has to be the very large image in order to cause problems).
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
What you describe couldn't happen even with this version of the control with a very large image size if Aspect is lvicActualSize ?
Yes it is possible. TIF for example is not uncommon to contain very high res images at 600 DPI or higher. VB will not allow a control to be sized greater than 16383 pixels. Translated down from 600 to 96 DPI (normal), that's rounded up to 2625 pixels, though the image dimensions would be 16406. Without DPI awareness, the control will attempt to load the image treating it as 16406, at current screen DPI, regardless of its actual setting. The lvicActualSize setting requests the same size as its dimensions & failure will occur. If AutoRedraw is requested, not sure if the O/S would allow, say a 16406x16406 bitmap, to be created. Memory-wise at 32 bpp image, over 1 GB of memory needed.
Granted that 2625 pixels scaled from 96 to 600 DPI is 16406, but is 2625 realistic? How about half that at 1200 DPI? Same result.
Again, it is possible. Likely? No. But to be a more bullet-proof control; this is an issue I'm attempting to find a good, usable, solution for. The best I've come up with so I don't have to create my own 'view port' is to rely on GDI+. If it can load it, then it can likely display it. The size of the image control is limited by VB, but that limit is larger than the screen so no real issue there.
Last edited by LaVolpe; Dec 14th, 2015 at 02:53 PM.
Insomnia is just a byproduct of, "It can't be done"
Re: [vb6]Alpha Image Control v2 - Final Update (15 Jan 2012)
Hi LaVolpe.
In a step forward, I dealed with the following issue, again it only occurs in run-time, in the debug-time within the IDE is just fine.
There is a quality loss in run-time when we load a picture from a IPictureDisp or StdPicture directly from its pointer.
If we load passing the handle porperty, instead, it works and the image is recovered perfectly.
However it does not apply for metafiles (.emf or .wmf), an error is raised when we try to load from the handle, either in run-time or debug-time.