Lebans Holdings 1999 Ltd.

 Home Up Feedback Contents Search What's New Files & Tips 

Image FAQ
Home
Up
HScroller
RowNumber
CustomScrollBar
MemViewer
EnumFonts
FontColorDialog
OLEtoDisk
CommandBars
WindowToBitmap
ListTablesInMDB
PrintFailures
Utilities
CallBackBrowser
Image FAQ
SaveRelationshipView
AddSQLComments

RETIRED! September 2009

I have officially retired from all things Access. Please do not send Email requesting support as I will not respond.

 

Keep all of your questions to the Newsgroups where everyone will benefit!

 

 

April 14, 2003

I am just starting to produce an Image Handling FAQ. Over the next few weeks will start pasting info onto this page and then begin the process of formatting the document.

Image Transparency Issues in Access

Convert all Images to Bitmap in Reports at runtime to alleviate "Out of Memory" error issue

Cannot Display OLE Images in Access2003

 

 

Image Transparency Issues in Access

I've been working on a solution to fix a couple of issues with Access
Image controls. These issues include:

1) Loading Jpeg, Bitmap, Gif, EMF and WMF files in Access RUNTIME
installs that do not have access to the Office graphics filters. The
current 2 year old solution I posted on my Web site works for Forms but
there is no way to load an Image into an Image control on a Report and
then try to size it without producing unuseable results.

2) Sizing Image controls at runtime for Forms and Reports, using the
SIzeMode property. In A97 only Image controls containing Bitmap files
could be resized at runtime as the Access resizing code was not calling
the SetStretchBltMode properly before the call to StretchDIBits or
StretchBlt. In A2K or higher the issue is reversed and Bitmap files
cannot be resized at runtime but everything else can.

3) Supporting transparency in transparent Gifs and properly coded
Metafiles with no backgrounds. The current solution on my site works but
is a hack at best.

4) Embedded Images in Image controls, other than Bitmap images, result
in a doubled file size. This is due to the fact that all non Bitmap
files are actually stored as Enhanced Metafiles. Well the GDI embedds a
complete WMF as the first record within the EMF as a GDI_COMMENT record
when you request an EMF via the Clipboard interface, as Access does.
This WMF is not used and is the same size as the parent EMF. Result -
doubled file size for nothing!

' If the file extension is in uppercase then the Office Graphics filters
' will be used to load the image. If the file extension is in lowercase
' then Access does not use the Office Graphics filters. This applies
' to Bitmap and Enhanced Metafiles.
' For Bitmaps you want Access to use the Office Graphics filters
' but for EMF's you do not.
' Notice the opposite results for the handling of Bitmap for EMF Images.
' Uppercase EMF = Office Graphics filter - Poor results for EMF's containing full color bitmaps
' Lowercase emf = bypass Office Graphics filters - Normal results
' Uppercase BMP = Office Graphics filter - Normal results
' Lowercase bmp = bypass Office Graphics filters - Poor results for BMP's containing full color bitmaps
' It does not matter the letter case of the Image's file extension on your hard drive. Access looks at the
' filename you enter via the GUI or programmatically for the Picture property of the Image control.

 

 

 

 

 

A2K on Win2K
I've been working on a solution to fix a couple of issues with Access
Image controls. These issues include:

1) Loading Jpeg, Bitmap, Gif, EMF and WMF files in Access RUNTIME
installs that do not have access to the Office graphics filters. The
current 2 year old solution I posted on my Web site works for Forms but
there is no way to load an Image into an Image control on a Report and
then try to size it without producing unuseable results.

2) Sizing Image controls at runtime for Forms and Reports, using the
SIzeMode property. In A97 only Image controls containing Bitmap files
could be resized at runtime as the Access resizing code was not calling
the SetStretchBltMode properly before the call to StretchDIBits or
StretchBlt. In A2K or higher the issue is reversed and Bitmap files
cannot be resized at runtime but everything else can.

3) Supporting transparency in transparent Gifs and properly coded
Metafiles with no backgrounds. The current solution on my site works but
is a hack at best.

4) Embedded Images in Image controls, other than Bitmap images, result
in a doubled file size. This is due to the fact that all non Bitmap
files are actually stored as Enhanced Metafiles. Well the GDI embedds a
complete WMF as the first record within the EMF as a GDI_COMMENT record
when you request an EMF via the Clipboard interface, as Access does.
This WMF is not used and is the same size as the parent EMF. Result -
doubled file size for nothing!

Anyhow, when I had my solution finished a couple of days ago I ran into
an issue. For those cases where you may want to save the contents of an
Image control to disk, I create an EMF so that all of the issues
detailed above are resolved. For hours I could not understand why the
EMF's I created could be viewed in all other Office apps except Access.
After trying everything I could think of, and I thought of a lot, I
finally accepted the fact that there was absolutely nothing wrong with
the files themselves. I started looking at the file names. Sure enough,
the answer was there. The Office Graphics filters in A2K or higher, will
fail to properly display, Enhanced Metafiles that have the extension in
all capitals instead of lower case. Thus Image.EMF will fail but
Image.emf works fine.
Next I try BMP files and sure enough, the same thing but in reverse.
Uppercase BMP extensions load and resize fine but lowercase bmp files
fail to display properly when resized.

To me it looks like the Office graphics filters are not being used by
Access for EMF and Bitmap images with extensions in lowercase. This is
good for the EMF files but not for the Bitmap files. I'm getting tired
of this issue but I will document it and publish on my site shortly.

FInally, the solution I came up with to fix the 4 issues listed above is
to:
1) Load the image into a StdPicture object.
2) Use the Render method of the StdPicture object to draw the image into
an Enhanced Metafile
3) Shove the bits of the EMF into directly into the Image control's
PictureData property.

Will post the solution to my site in the next day or two.

Stupidest non documented bug/feature I have ever seen!
:-(

If someone could point me to some detailed documentation on the complete
settings for all possible registry entries for the Office Graphics
filters I would really appreciate it. There must be a way to setup these
MS Office filters to have them work properly with Access. If nothing
else then I could simply enable and disable for individual file formats
as required.
:-(

Rant off..tired now and going to bed!

'******* Code End *********

 

Peter I learned over the weekend that I am an idiot.<grin>
For years I have been using GetDeviceCaps with LOGPIXELSY/LOGPIXELSX to
get the dpi resolution of the screen Device Context. Well it was wrong!
I used the correct method in all ofmy code that references a Printers DC
but not the screen DC. Now I Have to go back and fix all of my code that
uses this logic!
Explained below:


' Calculate the current Screen resolution.
' I used to simply call GetDeviceCaps with
' LOGPIXELSY/LOGPIXELSX. Unfortunately this does not yield accurate
results
' with Metafiles. LOGPIXELSY will return the value of 96dpi or 120dpi
' depending on the current Windows setting for Small Fonts or Large
Fonts.
' Thanks to Feng Yuan's book "Windows Graphics Programming" for
' explaining the correct method to ascertain screen resolution.

' Let's grab the current size and resolution of our Screen DC.
sngHORZRES = apiGetDeviceCaps(hDCref, HORZRES)
sngVERTRES = apiGetDeviceCaps(hDCref, VERTRES)
sngHORZSIZE = apiGetDeviceCaps(hDCref, HORZSIZE)
sngVERTSIZE = apiGetDeviceCaps(hDCref, VERTSIZE)

' Convert millimeters to inches
sngConvertX = (sngHORZSIZE * 0.1) / 2.54
sngConvertY = (sngVERTSIZE * 0.1) / 2.54
' Convert to DPI
sngConvertX = sngHORZRES / sngConvertX
sngConvertY = sngVERTRES / sngConvertY
Xdpi = sngConvertX
Ydpi = sngConvertY

 

Convert all Images to Bitmap in Reports at runtime to alleviate "Out of Memory" error issue

From: Stephen Lebans (StephenLebans@mvps.org)
Subject: Re: Reports with potentially 1000's of images
View: Complete Thread (5 articles)

Original Format

Newsgroups: microsoft.public.access.reports
Date: 2002-11-13 13:16:03 PST
Hi Steve, I would add two other items.
1) Turn of the "Importing Image" dialog window via the registry keys as
outlined here:
 http://www.mvps.org/access/api/api0038.htm
Make sure you do it for all Image types that you using that contain the
key.


2) Change all of the Images to Bitmaps at runtime. I have been able to
print previously unprintable reports by doing this last step. Here's a
previous post of mine on the subject.


From: Stephen Lebans (StephenLebans@mvps.org)
Subject: Re: Images in Reports
View: Complete Thread (18 articles)
Original Format
Newsgroups: microsoft.public.access.reports
Date: 2002-09-16 18:46:39 PST


Bruce I finally got a chance to test your method last night. It helped
but only with the actual printing and not the Print Preview itself.
 I was able to print the failed Report directly to the printer or to a
disk printer file so that's great! Don't get me wrong, it's still a good
thing because at least you can print the report!

Unfortunately Acess still runs out of resources when you page back and
forth through Print Preview.
I plan to spend some time onthis issue shortly.
Here is the code I use to convert any Jpeg, Gif, or Metafile into a BMP.
Rather than using one of my API solutions I have cheated and set a
Reference to Standard OLE Types type library in order to get at the
SAVETODISK method. But no ActiveX controls are required


Private Sub Detail_Print(Cancel As Integer, PrintCount As Integer)

Private ctr As Long

ctr = ctr + 1

Select Case ctr
    Case 1
     Me.Image10.Picture = CreateBitmapFile("C:\A.jpg")

    Case 2
    Me.Image10.Picture = CreateBitmapFile("C:\b.jpg")

    Case 3
    Me.Image10.Picture = CreateBitmapFile("C:\c.jpg")
    ctr = 0

    Case Else
    ctr = 0

End Select

End Sub

Private Sub Report_Open(Cancel As Integer)
ctr = 0
End Sub


Private Function CreateBitmapFile(fname As String) As String

Dim obj As Object

Set obj = LoadPicture(fname)
If Not IsNull(obj) Then

SavePicture obj, "C:\SL11-52"
DoEvents
End If


CreateBitmapFile = "C:\SL11-52"
Set obj = Nothing

End Function

 

 

Cannot Display OLE Images in Office 2003

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&newwindow=1&safe=off&frame=right&th=bea8d70a21dbf25d&seekm=44070b6aad018c4386e8cfcfa648c0e4%40news.teranews.com#link3

All messages from thread
Message 1 in thread

From: CAndersen (Kimba) (KimbaWLion_aol.com@127.0.0.1)
Subject: Extracting Images from Word 2003 Documents
 

 
 
View this article only

Newsgroups: microsoft.public.word.drawing.graphics
Date: 2004-03-17 09:38:11 PST
 

This post is basically just to document the solution I achieved for
the lack of Microsoft Photo Editor in Office 2003. I will admit it's
worthless if you don't have a previous version of Office available.

All my documentation projects involve a _lot_ of screen captures. Now,
I suppose I'm lazy for not setting up proper graphics folders and
indexes and all that for all the screen captures, but I find the
documents themselves provide all the organization of the images that I
need.

The major drawback to this occurs when an image needs to be edited.
Once an image is in a Word document, Word will not hand it off to
another application (via copy/cut and paste) in its original form.
Lettering becomes blurred and distorted. And even the seemingly
logical solution of saving the file in HTML format, where images are
saved as separate files, does not produce usable results.

The only application that Word will hand the image to without
distortion is Microsoft Photo Editor. But Microsoft Photo Editor is
not part of Office 2003.

Ever since this image handling peculiarity showed up with Word 97, the
method I've used is: copy the image from the Word document, paste it
into Microsoft Photo Editor, then copy it from there and paste it into
Paint Shop Pro. Edit it, and from Paint Shop Pro copy and paste it
back into Word. (My edits generally involve things that can't be done
in Photo Editor.)

So, the answer is to install Photo Editor from a previous version of
Office. In my case, my previous version was Office XP.

Using the Custom installation option in Setup for the old version of
Office, make sure that _everything_ is marked "Not Available", except
for Photo Editor. Run the installation.

This will, however, install some other shared files that will cause
problems with Office 2003. For example, after installing Photo Editor,
Outlook 2003 threw many errors. 

So, the next step is to use the Office 2003 installation CD to run the
Repair Office Installation function.

Everything seems to be running fine now. I can get undistorted images
out of Word via a stopover in Photo Editor, and Word and Outlook are
running without errors.

I don't understand why it's not possible to copy and paste an image
from Word to my graphics software without distortion, I just know it
is. And, for now, there's still a workaround, although Microsoft's
discontinuance of Photo Editor does not bode well for the future.

-- 
Email address munged. You can figure it out.

Post a follow-up to this message

Message 2 in thread

From: Suzanne S. Barnhill (sbarnhill@mvps.org)
Subject: Re: Extracting Images from Word 2003 Documents
 

 
 
View this article only

Newsgroups: microsoft.public.word.drawing.graphics
Date: 2004-03-17 16:37:00 PST
 

I did this in a vain attempt to regain some thumbnails. What I've found is
that now Office Update keeps prompting me to update Office XP. <sigh>

--
Suzanne S. Barnhill
Microsoft MVP (Word)
Words into Type
Fairhope, Alabama USA
Word MVP FAQ site: http://www.word.mvps.org
Email cannot be acknowledged; please post all follow-ups to the newsgroup so
all may benefit.

"CAndersen (Kimba)" <KimbaWLion_aol.com@127.0.0.1> wrote in message
news:44070b6aad018c4386e8cfcfa648c0e4@news.teranews.com...
> This post is basically just to document the solution I achieved for
> the lack of Microsoft Photo Editor in Office 2003. I will admit it's
> worthless if you don't have a previous version of Office available.
>
> All my documentation projects involve a _lot_ of screen captures. Now,
> I suppose I'm lazy for not setting up proper graphics folders and
> indexes and all that for all the screen captures, but I find the
> documents themselves provide all the organization of the images that I
> need.
>
> The major drawback to this occurs when an image needs to be edited.
> Once an image is in a Word document, Word will not hand it off to
> another application (via copy/cut and paste) in its original form.
> Lettering becomes blurred and distorted. And even the seemingly
> logical solution of saving the file in HTML format, where images are
> saved as separate files, does not produce usable results.
>
> The only application that Word will hand the image to without
> distortion is Microsoft Photo Editor. But Microsoft Photo Editor is
> not part of Office 2003.
>
> Ever since this image handling peculiarity showed up with Word 97, the
> method I've used is: copy the image from the Word document, paste it
> into Microsoft Photo Editor, then copy it from there and paste it into
> Paint Shop Pro. Edit it, and from Paint Shop Pro copy and paste it
> back into Word. (My edits generally involve things that can't be done
> in Photo Editor.)
>
> So, the answer is to install Photo Editor from a previous version of
> Office. In my case, my previous version was Office XP.
>
> Using the Custom installation option in Setup for the old version of
> Office, make sure that _everything_ is marked "Not Available", except
> for Photo Editor. Run the installation.
>
> This will, however, install some other shared files that will cause
> problems with Office 2003. For example, after installing Photo Editor,
> Outlook 2003 threw many errors.
>
> So, the next step is to use the Office 2003 installation CD to run the
> Repair Office Installation function.
>
> Everything seems to be running fine now. I can get undistorted images
> out of Word via a stopover in Photo Editor, and Word and Outlook are
> running without errors.
>
> I don't understand why it's not possible to copy and paste an image
> from Word to my graphics software without distortion, I just know it
> is. And, for now, there's still a workaround, although Microsoft's
> discontinuance of Photo Editor does not bode well for the future.
>
> --
> Email address munged. You can figure it out.

Post a follow-up to this message

Message 3 in thread

From: CAndersen (Kimba) (KimbaWLion_aol.com@127.0.0.1)
Subject: Re: Extracting Images from Word 2003 Documents
 

 
 
View this article only

Newsgroups: microsoft.public.word.drawing.graphics
Date: 2004-03-18 06:51:37 PST
 

On Wed, 17 Mar 2004 18:16:32 -0600, "Suzanne S. Barnhill"
<sbarnhill@mvps.org> wrote:

>I did this in a vain attempt to regain some thumbnails. What I've found is
>that now Office Update keeps prompting me to update Office XP. <sigh>

I'm sorry to hear that. I have not run into that problem.

However, Outlook did start throwing errors again after I posted. 
I found this (incredible) fix:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm=081601c309fd%242ac4c3e0%24a001280a%40phx.gbl&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26safe%3Doff%26q%3Derror%2B8007007F%2B-%2Bthe%2BFIX!%26btnG%3DGoogle%2BSearch
(in case that breaks when I post it, here's a shorter link:
http://makeashorterlink.com/?M27B623C7
but I don't know when that short version will expire.)

I don't know if that fix will relate to your problem or not.
Component checker found that I had two different versions of
oledb32.dll on my computer, and that was confusing things.
So far, after doing the prescribed manual replacement of oledb32.dll,
Outlook is happy and I can still extract images from Word.

Post a follow-up to this message


 

 

 

 
 

May 23, 2004 Product Update
 
 
Rich Text ActiveX control. Version 1.8

Click Here!

 

Mar 15, 2005 Product Update
 
MouseHook  Replaces the MouseWheel DLL subclassing solution. Turns On/Off the MouseWheel with one line of code. No DLL registration required. Now supports Logitech mice!

Click Here! 

 

 

 
Back Home Up Next 
Stephen Lebans Copyright 2009

Last Modified : 09/11/09 12:03 AM