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

setting null image.Picture property

P: n/a
I'm working on distributing a database using VS Tools for Office, and
am having trouble with linked images on forms/reports. The image
objects have a default path\file set on the .Picture property, which
becomes invalid when the user installs the database (ie: c:\devpath\
becomes c:\program files\mydbapp, but the .Picture property still
points to c:\devpath\) The problem is that I don't *know* what
installation path the user will select, so I can't hard-code a path
into the property. I technically can't even use "c:\dummy.jpg" because
I don't know the user has a drive c:\.

The forms/reports themselves work fine in print preview, as the
image.Picture property is set via VBA code to show the correct image
for that record. But when opening the database and opening the
forms/reports with linked image objects *in design view*, I get a
series of "can't open the file" errors. Errors when opening in design
view I can live with, since print preview works. But errors during
startup are not acceptable. I suspect it's the design-view errors
appearing during startup for some reason, so I think once one problem
is fixed, the other will be fixed as well.

I've read that some people recommend creating image objects with
Picture="(none)" or "", but Access 2003-SP2 won't let me do that. It
forces me to choose an image file, so I load in a dummy/default image
that ends up being replaced in VBA. (ie: c:\devpath\dummy.jpg)

I've tried updating the image.picture property for each object On-Open
so it points to a valid path, but that doesn't work; I still get "can't
open the file" errors. My guess is that design-view doesn't trigger
on-open.

I've tried updating the link to a valid devpath\filename then removing
the path from the .Picture property (since the helpfiles indicate the
Path is optional for the .Picture property). It seems to work, and it
appears as if only the filename is saved. I can then open/close/design
the report w/o any problems. But if I close the database, rename my
devpath directory, and open the database, it says it can't find the
images when I go back to that same report in design view. If I open the
report in design view and fix the first image so it references the new
path (leaving the others so they just reference the filename), then
*all* images on the report in design view show the default/dummy image
properly. Very odd. Is there a report property to define a "default
directory" for searching for images w/o paths?

I've also tried using system variables, code, and a custom function in
the .Picture box, with no success. ie: currentproject.path &
"\dummy.jpg" or %windir%\dummy.jpg or DefaultDir()
It seems like the .Picture property can only contain a uninterpreted
string.

Is there a way to set an image object so its .Picture property is
null/(None)/""?
Is there a way to type code into the .Picture property?
Is there some other solution to this quandary?

May 8 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Answering my own question...

I decided to work on the problem some more. Here is my solution.

For each Linked image in each form/report, set it as Embedded, and
..Picture=c:\dummy.jpg, which is a 256byte 1x1 pixel image. (I didn't
bother optimizing by setting color depth, etc... 256byte is good enough
for now.)

Then in VBA, immediately before setting the .Picture property to load
the correct image for the record, set .PictureType=1, which I
understand to be "linked".

In theory this switches the report/form to use a linked reference to
whatever file I want, but the saved report design contains an embedded
dummy image to avoid the "file not found" problem I encountered during
startup and design-view.

Since it is embedded, the file c:\dummy.jpg can be deleted and the
c:\devpath directory can be renamed w/o any problems. I tested it, and
all error messages are gone. Yay!

Will my solution cause any problems with a slow bloat over time? Am I
properly only "linking" to images, or will Access use the saved
"embedded" setting to absorb the image data over time? If that happens
it's definitely a problem, as my image archive for this project is
about 40MB at this point. I ran through one of the reports in
print-preview that accesses most of the images, and I didn't notice any
bloat in the db FE. It looks like a working solution.

Even though I answered the question myself, I welcome any and all
input/comments/corrections.

May 8 '06 #2

P: n/a
It won't bloat unless you store the images in the database as OLE
objects OR you allow changes to the forms to be saved in any view (see
AllowDesignChanges property for the forms).

If you are binding these images to the controls at run-time, anyway,
I'd suggest using a CurrentProject.Path call to provide the Path string
to the image folder to eliminate your path change problems after the
app is installed on the client machine.

May 10 '06 #3

P: n/a
<NA******@gmail.com> wrote
Will my solution cause any problems with a slow bloat over time? Am I
properly only "linking" to images, or will Access use the saved
"embedded" setting to absorb the image data over time? If that happens
it's definitely a problem, as my image archive for this project is
about 40MB at this point. I ran through one of the reports in
print-preview that accesses most of the images, and I didn't notice any
bloat in the db FE. It looks like a working solution.

Even though I answered the question myself, I welcome any and all
input/comments/corrections.


The sample imaging databases at http://accdevel.tripod.com illustrate three
approaches to handling images in Access, and the download includes an
article discussing considerations in choosing an approach. Two of the
approaches do not use OLE Objects and, thus, avoid the database bloat, and
some other problems, associated with images in OLE Objects.

If you are printing the images in reports, to avoid memory leakage, you
should also see MVP Stephen Lebans' http://www.lebans.com/printfailures.htm.
PrintFailure.zip is an Access97 MDB containing a report that fails during
the Access formatting process prior to being spooled to the Printer Driver.
This MDB also contains code showing how to convert the contents of the Image
control to a Bitmap file prior to printing. This helps alleviate the "Out of
Memory" error that can popup when printing image intensive reports.

Larry Linson
Microsoft Access MVP
May 10 '06 #4

P: n/a
Jamey and Larry: Thanks for the replies. I found both helpful.

I am using image objects to manage the pictures, not OLE objects. Nor
do I allow form-view design changes.
I am using dynamic path detection to display pictures. The problem was
with the "default" image that has to be saved with the image object.
All seems well now, with the solution I outlined above.

I have noticed a lot of memory use during printing (~300MB) of my
larger reports, but the system I'm working with has enough memory to
handle it. If it becomes a problem, I may use Lebans' solution.

A new problem (already solved): When my database is deployed using the
Access 2003 runtime, none of the jpg images would display. Only bmp
images worked. The reason is that the runtime doesn't include any
Office graphics filters. Thanks, MS! I considered converting images
to bmp in realtime, but decided to use code that can display jpg files
w/o using Office graphics filters.

Solution:
http://www.lebans.com/loadjpeggif.htm
http://www.lebans.com/DownloadFiles/...r33GDiPlus.zip

I reviewed the code, installed the class module and 2 other required
modules, and updated my own image-redraw code to use the new method in
about an hour. Sweet.

I tested it, and images are drawn properly in the reports/forms using
the 2003 runtime and 2003 full install w/o any problems. I haven't
checked to see how memory useage has changed. (possibly lower now that
the Office graphics filters aren't used)

Therefore, a big thanks goes out to Stephen Lebans as well. :)

May 10 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.