By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,742 Members | 1,570 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,742 IT Pros & Developers. It's quick & easy.

bound ole ctrl only displaying path

P: n/a
I'm setting up an Access2003 database with pictures. I put a bound ole
picture ctrl on a form that's source is the table that contains the pictures
and follow ALL the directions for embedding a picture. The ctrl in the form
only displays the filename of the picture. The underlying table, when
opened in table view, shows the word "package" in the field. When I
double-click on either it opens the picture, but I can't get it to display.

Probably an easy question, but wtf am I doing wrong?
tia
Jon
Feb 15 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Why did I bother to write such a detailed response? I'm building a graphic
FAQ as I'm getting tired of answering this same question over and over and
over...<grin>

You must have an application on your computer that can function as OLE
Server for the particular Images types you are embedding in the table. When
a Package object is created, the application that is currently registered to
handle this file extension(jpg, gif whatever) cannot function as an OLE
Server for this image type. Instead, the entire file, plus a small Access
and OLE Header is prepended to a copy of the actual file. When you Activate
this object, by double clicking on it, Access basically performs an
Application.FollowHyperLink call. This launches whatever application is
registered for this file extension and passes it the unwrapped copy of the
original embedded file. I have simplified the process a bit but it is an
accurate statement of what is happening behind the scenes.

So you need to find an application on your computer that can function as an
OLE Server for the desired Image types and is currently registered on your
system to display these specific image types. Viable OLE Server apps include
MS Paint(Bmp, Gif), MS Photo Editor(everything except Tif), Paint Shop
Pro(everything), PhotoShop(everything I think) and so on and so on. A simple
method to associate a specific application with a specific Image type is to:

1) Open a folder containing the Images you want to insert.
2) Right click on a file while holding down the SHift key.
3) From the popup menu select "Open With".
4) Scroll down the Open With Dialog window until you find MS Photo
Editor and select it.
5) Check the Always use this program to open this file type CheckBox
control.
6) Click OK.
Repeat the steps once for each different type of Image file you want to
embedd in your table.
*********************************************
What are the specific Image types you want to embed? What Paint or Drawing
applications do you have available on your system?

To achieve the smallest record sizes, and allow for distribution to other
computers, I would recommend converting every image to BMP and ensure MS
Paint owns the registration for BMP files before they are inserted. Why do I
suggest converting to BMP format? Glad you asked.<grin>

The actual format of the Image data the application inserts into the OLE is
completely and utterly up to the OLE Server app. No other application,
including Access, will process this data. You would think a smart OLE Server
would simply insert say, the original compressed JPEG as is, in order to
save space. After all, the JPG is compressed on disk, why not store it that
way? Well, in all of the time I have spent working with embedded objects, I
have NEVER come across an instance when the application has done anything
but store a fully uncompressed Bitmap in the OLE field. The majority of apps
store the uncompressed Bitmap data as RGB triplets. Not quite a packed DIB
but close.

The OLE bloating issue is further exacerbated by the OLE specification that
a Presentation stream must be included as part of the OLE object. This
Presentation structured storage Stream is comprised of a full size
uncompressed Bitmap of the original file. It is generally wrapped up within
a CF_METAFILEPICT structure. This Presentation Bitmap is required so that
Access can display the image when:

1) The OLE object has not been activated yet so the OLE Server is not active
in Memory and does not have to render the Image

2) The original application that functioned as the OLE Server is not
available on the current system
Let's look at a specific example. In this case we will use a 24bit 800 * 400
Jpeg Image that compresses to 50KB.

Uncompressed Bitmap(RGB triplets, 3 bytes per pixel - 24 Bits)
800 * 3 bytes per pixel = 2400 bytes per row
2400 bytes x 400 rows = 960,000 bytes = 960K

So a single instance of the uncompressed Image = 960KB
The Presentation Bitmap = another 960KB
-----------------------------------------------------------
So now we have a grand total of 1,920,000KB of Image data that is inserted
into the OLE object field for an original 50KB Jpeg file. There is
additional overhead as well for the other OLE structured storage streams
that comprise the embedded OLE object, plus the private Access header and
the Access OLE header data. But this other data amounts to only a few KB or
less in total.

The absolute worse case can result in another complete uncompressed Bitmap
being stored as well. As the older METAFILEPICT structure is used, some
modern applications prefer initially to work with the newer Enhanced
Metafile(EMF) format and then convert this to a METAFILEPICT. Unfortunately,
there is a bug/feature whereby the GDI API that performs this conversion
process actually embedds a full copy of the original EMF as a Metafile
Comment record within the ouput METAFILEPICT. Why did I bother to mention
this if I'm not sure? I'm sure that I have seen this on at least one
occasion but have been unable to find the original OLE object field data in
question.

Now there are some ways around the OLE bloat issue. The best you can do is
ensure only a single instance of the uncompressed Bitmap is stored.

If you use MS Paint to embed a BMP image, only a single copy of the
uncompressed Image is stored. You still have full Activate/Double Click
functionality so the user can edit the Image in place with MS Paint.

If you only need to display the Image but not allow the user to
Activate/Double Click to edit then you can embed the Image as one of the
STATIC object types. Again, only a single copy of the uncompressed BMP is
stored. You don't much control over this process though as it is up the
application inserted the image.

I always meant to write a simply OLE Server(really an OLE Handler) that
would store the compressed Image and create a low resolution, 8 bit color
Bitmap for the Presentation stream. I have given up on these plans as
Microsoft has announced that the OLE technology is now baked and basically
put into maintentance mode( I read this in the VISTA section on MSDN I
believe). The new version of Access will finally be able to store compressed
Images directly with no bloating.

To that end I have created an OLE Object extraction tool. The next addition
to this project will allow for the extraction of the embedded images and the
automatic conversion and reinsertion of the image into the new Access 12
field type that will house the compressed Image data.

http://www.lebans.com/oletodisk.htm
NEW - Feb 06/2006 ExtractInventoryOLE.zip A2K or higher ONLY! This
version saves the entire contents of a table containing OLE Objects to disk.
Does NOT require the original application that served as the OLE server to
insert the object. Supports all MS Office documents, PDF, All images
inserted by MS Photo Editor, MS Paint, and Paint Shop Pro. Also supports
extraction of PACKAGE class including original Filename. Contains function
to produce a full Inventory of the OLE field including LINKED path and
Filenames. Uses Structured Storage API's to read the actual contents of the
field. Version BETA 1.56

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"Jon Weston" <jo********@hotmail.com> wrote in message
news:aDuIf.3326$B94.1738@pd7tw3no...
I'm setting up an Access2003 database with pictures. I put a bound ole
picture ctrl on a form that's source is the table that contains the
pictures and follow ALL the directions for embedding a picture. The ctrl
in the form only displays the filename of the picture. The underlying
table, when opened in table view, shows the word "package" in the field.
When I double-click on either it opens the picture, but I can't get it to
display.

Probably an easy question, but wtf am I doing wrong?
tia
Jon

Feb 15 '06 #2

P: n/a
Thanks for the excellent reply (and patience), Stephen. I thought I'd run
across this before but could find no answers. I made the changes you
suggested and it's working now. I'd heard about OLE bloat before, but
thanks for the kick in the pants - I think I'll re-examine how I'm storing
these pictures sometime soon. In the meantime, work work work...I'll hit
your site when I can.

"Stephen Lebans" <ForEmailGotoMy.WebSite.-WWWdotlebansdot...@linvalid.com>
wrote in message news:xW********************@ursa-nb00s0.nbnet.nb.ca...
Why did I bother to write such a detailed response? I'm building a graphic
FAQ as I'm getting tired of answering this same question over and over and
over...<grin>

You must have an application on your computer that can function as OLE
Server for the particular Images types you are embedding in the table.
When a Package object is created, the application that is currently
registered to handle this file extension(jpg, gif whatever) cannot
function as an OLE Server for this image type. Instead, the entire file,
plus a small Access and OLE Header is prepended to a copy of the actual
file. When you Activate this object, by double clicking on it, Access
basically performs an Application.FollowHyperLink call. This launches
whatever application is registered for this file extension and passes it
the unwrapped copy of the original embedded file. I have simplified the
process a bit but it is an accurate statement of what is happening behind
the scenes.

So you need to find an application on your computer that can function as
an OLE Server for the desired Image types and is currently registered on
your system to display these specific image types. Viable OLE Server apps
include MS Paint(Bmp, Gif), MS Photo Editor(everything except Tif), Paint
Shop Pro(everything), PhotoShop(everything I think) and so on and so on. A
simple method to associate a specific application with a specific Image
type is to:

1) Open a folder containing the Images you want to insert.
2) Right click on a file while holding down the SHift key.
3) From the popup menu select "Open With".
4) Scroll down the Open With Dialog window until you find MS Photo
Editor and select it.
5) Check the Always use this program to open this file type CheckBox
control.
6) Click OK.
Repeat the steps once for each different type of Image file you want to
embedd in your table.
*********************************************
What are the specific Image types you want to embed? What Paint or Drawing
applications do you have available on your system?

To achieve the smallest record sizes, and allow for distribution to other
computers, I would recommend converting every image to BMP and ensure MS
Paint owns the registration for BMP files before they are inserted. Why do
I suggest converting to BMP format? Glad you asked.<grin>

The actual format of the Image data the application inserts into the OLE
is completely and utterly up to the OLE Server app. No other application,
including Access, will process this data. You would think a smart OLE
Server would simply insert say, the original compressed JPEG as is, in
order to save space. After all, the JPG is compressed on disk, why not
store it that way? Well, in all of the time I have spent working with
embedded objects, I have NEVER come across an instance when the
application has done anything but store a fully uncompressed Bitmap in the
OLE field. The majority of apps store the uncompressed Bitmap data as RGB
triplets. Not quite a packed DIB but close.

The OLE bloating issue is further exacerbated by the OLE specification
that a Presentation stream must be included as part of the OLE object.
This Presentation structured storage Stream is comprised of a full size
uncompressed Bitmap of the original file. It is generally wrapped up
within a CF_METAFILEPICT structure. This Presentation Bitmap is required
so that Access can display the image when:

1) The OLE object has not been activated yet so the OLE Server is not
active in Memory and does not have to render the Image

2) The original application that functioned as the OLE Server is not
available on the current system
Let's look at a specific example. In this case we will use a 24bit 800 *
400 Jpeg Image that compresses to 50KB.

Uncompressed Bitmap(RGB triplets, 3 bytes per pixel - 24 Bits)
800 * 3 bytes per pixel = 2400 bytes per row
2400 bytes x 400 rows = 960,000 bytes = 960K

So a single instance of the uncompressed Image = 960KB
The Presentation Bitmap = another 960KB
-----------------------------------------------------------
So now we have a grand total of 1,920,000KB of Image data that is inserted
into the OLE object field for an original 50KB Jpeg file. There is
additional overhead as well for the other OLE structured storage streams
that comprise the embedded OLE object, plus the private Access header and
the Access OLE header data. But this other data amounts to only a few KB
or less in total.

The absolute worse case can result in another complete uncompressed Bitmap
being stored as well. As the older METAFILEPICT structure is used, some
modern applications prefer initially to work with the newer Enhanced
Metafile(EMF) format and then convert this to a METAFILEPICT.
Unfortunately, there is a bug/feature whereby the GDI API that performs
this conversion process actually embedds a full copy of the original EMF
as a Metafile Comment record within the ouput METAFILEPICT. Why did I
bother to mention this if I'm not sure? I'm sure that I have seen this on
at least one occasion but have been unable to find the original OLE object
field data in question.

Now there are some ways around the OLE bloat issue. The best you can do is
ensure only a single instance of the uncompressed Bitmap is stored.

If you use MS Paint to embed a BMP image, only a single copy of the
uncompressed Image is stored. You still have full Activate/Double Click
functionality so the user can edit the Image in place with MS Paint.

If you only need to display the Image but not allow the user to
Activate/Double Click to edit then you can embed the Image as one of the
STATIC object types. Again, only a single copy of the uncompressed BMP is
stored. You don't much control over this process though as it is up the
application inserted the image.

I always meant to write a simply OLE Server(really an OLE Handler) that
would store the compressed Image and create a low resolution, 8 bit color
Bitmap for the Presentation stream. I have given up on these plans as
Microsoft has announced that the OLE technology is now baked and basically
put into maintentance mode( I read this in the VISTA section on MSDN I
believe). The new version of Access will finally be able to store
compressed Images directly with no bloating.

To that end I have created an OLE Object extraction tool. The next
addition to this project will allow for the extraction of the embedded
images and the automatic conversion and reinsertion of the image into the
new Access 12 field type that will house the compressed Image data.

http://www.lebans.com/oletodisk.htm
NEW - Feb 06/2006 ExtractInventoryOLE.zip A2K or higher ONLY! This
version saves the entire contents of a table containing OLE Objects to
disk. Does NOT require the original application that served as the OLE
server to insert the object. Supports all MS Office documents, PDF, All
images inserted by MS Photo Editor, MS Paint, and Paint Shop Pro. Also
supports extraction of PACKAGE class including original Filename. Contains
function to produce a full Inventory of the OLE field including LINKED
path and Filenames. Uses Structured Storage API's to read the actual
contents of the field. Version BETA 1.56

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"Jon Weston" <jo********@hotmail.com> wrote in message
news:aDuIf.3326$B94.1738@pd7tw3no...
I'm setting up an Access2003 database with pictures. I put a bound ole
picture ctrl on a form that's source is the table that contains the
pictures and follow ALL the directions for embedding a picture. The ctrl
in the form only displays the filename of the picture. The underlying
table, when opened in table view, shows the word "package" in the field.
When I double-click on either it opens the picture, but I can't get it to
display.

Probably an easy question, but wtf am I doing wrong?
tia
Jon


Feb 15 '06 #3

P: n/a
Stephen,

I was having a similar issue, but at least my embedded pictures were
showing. My problem was that I reached the 2 gig file limit with 700
photos inserted, and I wanted to insert more.
I experimented with removing the embedded jpg, and inserting a bmp
instead. I discovered that the embedded jpg was about 2.8 meg, and the
embedded bmp was only 1.4 meg. That gave me a significant saving in
space. The funny part is that the bmp is only 700k. It looks like the
bmp is still being stored twice. I'm miles in front, but like to store
only a single instance of the bmp if that's possible.
I'm using Access XP and Access 2k3, both on WinXP Pro.

Thanks,
BarryG

Feb 19 '06 #4

P: n/a
As I stated in my earlier post, Microsoft Paint MUST own the file
registration for "BMP" BEFORE you reinsert the Bitmap images. You may even
have to reboot after resetting the registration for BMP or at the very
least, restart Access.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
<co******************@yahoo.com.au> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...
Stephen,

I was having a similar issue, but at least my embedded pictures were
showing. My problem was that I reached the 2 gig file limit with 700
photos inserted, and I wanted to insert more.
I experimented with removing the embedded jpg, and inserting a bmp
instead. I discovered that the embedded jpg was about 2.8 meg, and the
embedded bmp was only 1.4 meg. That gave me a significant saving in
space. The funny part is that the bmp is only 700k. It looks like the
bmp is still being stored twice. I'm miles in front, but like to store
only a single instance of the bmp if that's possible.
I'm using Access XP and Access 2k3, both on WinXP Pro.

Thanks,
BarryG

Feb 19 '06 #5

P: n/a

Stephen Lebans wrote:
As I stated in my earlier post, Microsoft Paint MUST own the file
registration for "BMP" BEFORE you reinsert the Bitmap images. You may even
have to reboot after resetting the registration for BMP or at the very
least, restart Access.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.


Stephen,

I've just tried it again with a brand new database on a different
machine. Paint is registered as the owner of bmp files.
I have a field in my table which is type OLE object. I right click,
insert from file, navigate to the coffebean.bmp file (16.6k) in windows
dir and insert it. In it goes, and the display in the table view says
"Bitmap Image"
If I then right click that field, and select copy, then go to the
desktop, and select paste, the scrap file on the desktop is 38.5k. It
looks like 2 copies of the bmp has been stored, plus the ole overhead.
Is this not a valid test to see how much is being stored?

Barry.

Feb 22 '06 #6

P: n/a
No it's not. I believe when you drag and and drop from the OLE field via the
Explorer it will always create a Presentation stream within the OLE
structured Storage..

Create an event on your form containing the Bound OLE Frame control, for
example CommandButton Click event. Move to the record containing the BMP.
Set a breakpoint in the event on any line of code. Set a Watch on your OLE
Frame control. Now look at the Value property for this control. The byte
size of this property is the size of the data stored to the field.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
<co******************@yahoo.com.au> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

Stephen Lebans wrote:
As I stated in my earlier post, Microsoft Paint MUST own the file
registration for "BMP" BEFORE you reinsert the Bitmap images. You may
even
have to reboot after resetting the registration for BMP or at the very
least, restart Access.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.


Stephen,

I've just tried it again with a brand new database on a different
machine. Paint is registered as the owner of bmp files.
I have a field in my table which is type OLE object. I right click,
insert from file, navigate to the coffebean.bmp file (16.6k) in windows
dir and insert it. In it goes, and the display in the table view says
"Bitmap Image"
If I then right click that field, and select copy, then go to the
desktop, and select paste, the scrap file on the desktop is 38.5k. It
looks like 2 copies of the bmp has been stored, plus the ole overhead.
Is this not a valid test to see how much is being stored?

Barry.

Feb 22 '06 #7

P: n/a

Stephen Lebans wrote:
No it's not. I believe when you drag and and drop from the OLE field via the
Explorer it will always create a Presentation stream within the OLE
structured Storage..

Create an event on your form containing the Bound OLE Frame control, for
example CommandButton Click event. Move to the record containing the BMP.
Set a breakpoint in the event on any line of code. Set a Watch on your OLE
Frame control. Now look at the Value property for this control. The byte
size of this property is the size of the data stored to the field.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.


Stephen,

You are correct.
I've done as you suggested, and this confirms that the Coffee Bean.bmp
from the windows dir, which is 17062 bytes on the disk, is stored as
17177 bytes in the table.
Thanks for setting me straight. I've learned a bit more.

BarryG

Feb 23 '06 #8

P: n/a
bob


An easy way to check the size of your image data is with a query like the following:

SELECT Id, LenB([ImageField]) AS Expr1
FROM tblImages;

--
__________________________________________________ _____
http://www.ammara.com/dbpix/access.html
DBPix 2.0: Add pictures to Access, Easily & Efficiently
co******************@yahoo.com.au wrote:

Stephen Lebans wrote:
No it's not. I believe when you drag and and drop from the OLE field via the
Explorer it will always create a Presentation stream within the OLE
structured Storage..

Create an event on your form containing the Bound OLE Frame control, for
example CommandButton Click event. Move to the record containing the BMP.
Set a breakpoint in the event on any line of code. Set a Watch on your OLE
Frame control. Now look at the Value property for this control. The byte
size of this property is the size of the data stored to the field.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.


Stephen,

You are correct.
I've done as you suggested, and this confirms that the Coffee Bean.bmp
from the windows dir, which is 17062 bytes on the disk, is stored as
17177 bytes in the table.
Thanks for setting me straight. I've learned a bit more.

BarryG


Feb 23 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.