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:xWxIf.30205$VV4.308879@ursa-nb00s0.nbnet.nb.ca...[color=blue]
> 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" <jon.weston@hotmail.com> wrote in message
> news:aDuIf.3326$B94.1738@pd7tw3no...[color=green]
>> 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
>>[/color]
>
>[/color]
bound ole ctrl only displaying path 
