Expanding, opening or zooming on a picture on a form.

[dwcrockford]

I have a form designed which displays a different picture depending on which record is displayed on the form. It is set up as in the main table (in this instance, "Performances") as an attachment in the table (pdf), and is displayed on the "Performances" form. It displays correctly, and changes as the records change.

Other than double-clicking the image, and selecting "open attachment" from the popup window, is there a way (code, form generation?) to set it to single-click, and open a larger view of the image without opening the attachment in the external pdf viewing program.

I'm willing to create a stand-alone form that would open displaying a larger embedded image, and assigning another "click to close" or even a button to closed the "expanded view" window/form.

Suggestions on how to do this properly (and with limited access knowledge) is appreciated.

Daryl

 

[HiTechCoach]

daryl,

What version of Access are you using?

 

[dwcrockford]

Access 2013, and my temporary work-around (suitable, but maybe not the ideal) is I created a separate form with a larger version of the image, and my "on click" command on the original form opened the second form. (my second option above). It seems to work, but I am certain there was a better way.

 

[Micron]

Access 2013, and my temporary work-around (suitable, but maybe not the ideal) is I created a separate form with a larger version of the image, and my "on click" command on the original form opened the second form. (my second option above). It seems to work, but I am certain there was a better way.

First, I would caution you against putting attachments in a table because the database can quickly approach size limits at worst, and really slow down at best. Access is not as well-suited for this as is SQL Server. It's usually somewhat more problematic if you want to store larger images with larger file sizes as well.

Assuming your main form uses a smaller image control ("thumbnail image") due to space limitations, I think your best option is to open another form using the click or double click event for the small image control on your main form. I suggest a table with image description (unless perhaps they are all images of people) and path fields, and one more field to tie it to the record of the main form (EmplID?) so you can show the correct thumbnail. On the second form you can have a much larger image control that is coded to display the image you need (on the form open event) by passing the path value of the thumbnail to the second form's image control. The first thing I'd do on this click event is determine if the second form is already open, otherwise you will either get an error message on the attempt or (less likely) the form will activate with the wrong image (the open event will not re-fire if the form is already open). To test for this, I use something like

If CurrentProject.Allforms("frmName").IsLoaded Then
  Docmd.Close acform,"frmName"
  Maybe do other stuff or just re-open
  Docmd.Open acform, "frmName",,,,,,"PathToImageFile" 'text at end is using the OpenArgs parameter to pass the image path
End If

I'm assuming you created pdf files to hold the image, which does have benefits, but keeping the image in a network folder and using the path has other benefits as noted above. Note that this method means your image is not embedded in the image control as you stated.

 

[HiTechCoach]

Daryl,

Thanks for the update.

open a larger view of the image without opening the attachment in the external pdf viewing program

I am confused. Images (jpg/png/bmp/gif) should no be oping in a PDF viewer. Normally only PDF files open with a PDF viewer. If this is really happening then you make have a file classification issue for image types (jpg/png/bmp/gif).

Which PDF viewer are you using? If you are using one of the Adobe readers then you may want to check the setting sot hat it does not open the PDF in a separate window.


It sounds like you are storing image (jpg/png/bmp/gif) or PDF fields in an attachment field data type. I have run into many issues with this with desktop databases. I find it much better to store only the path to the file. The attachment data type requires lots of VBA coding to do any type of automation.

The Web Browser Control (WBC) makes a great file viewer. Starting with Access 2010 there is a new (built-in) native WBC. I use it for showing file of many types. It can be bound to a field in a table. You may be able to use this on your form. I have never tried to use it with the attachment data type since I avoid that data type.

 

[HiTechCoach]

First, I would caution you against putting attachments in a table because the database can quickly approach size limits at worst, and really slow down at best. Access is not as well-suited for this as is SQL Server. It's usually somewhat more problematic if you want to store larger images with larger file sizes as well.

This was really important with the older JET (.mdb) database format unless you used VBA coded to store the files as a BLOB.

With JET databases (.mdb) the OLE data type often used to store files int he data did cause considerable Bloat. I used code to store then as a BLOB with very little bloat. While it is true that the new ACE database format (accdb) stores files internally with little bloat, there is still the 2 GIG total file size limit to single database (.accdb) file. This still limits the number of files you can store before the database is full.

I have does some experimenting using two back ends. Splitting out the attachment field into a separate back end. This attachment back end has a single table for attachments. with only 2 fields. A primary key and a attachment data type field. This has to work very well. When I stress test the attachment back end database by loading a lot of files to push it past the 2 GIG limit it does not crash the main back end with all the other tables of data. This is the only safe way I have found to use the attachment field for a large amount of files attached.

I do store files in my back end. It is a very limited number of files, like a few logos and some others stuff used by the application.

I agree with Micron that you should avoid storing any data related files in the database in an attachment field.

 

[dwcrockford]

Thank you both; and I actually understand what your are saying. In this particular database, it is for a community choir, and there evolves a bit of a file location issue when using the File Location link option in the database.

The database will be stored on a portable harddrive. As the type of organization (non-profit) changes people regularly, there is not one single person (computer) that will be the sole location of the database. Therefore, as people plug in the portable hard drive on their own computer, the drive letter changes according to their system setup (on my personal computer, it defines it as "J:"

I have not found a solution in linking images (or other files) relative to the database location - all tutorials, examples I have found specify that the file location link MUST be the FULL PATH of the file (right from the drive letter).

Does anyone have a solution to this little downfall that would make the file location relative to the database (in a subfolder). It can easily be done in html design, but have not found a solution to this.

It is for this reason I have needed to embed the file into the database itself even though I am aware that it will bloat the DB - especially as things are added. In the meantime, I am downsizing the images (.jpgs) for the on-screen viewing portion, but would eventually like to link the full-size pdf (print quality) as well.

D

 

[Micron]

Does anyone have a solution to this little downfall that would make the file location relative to the database (in a subfolder). It can easily be done in html design, but have not found a solution to this.

There is probably more than one possible solution. What immediately comes to mind is the Application.CurrentProject.Path property. You could copy the first character (C or J) that this returns and concatenate the rest of the path where the pictures are located, up to the last backslash but not including an image file name. What you do with this depends on your preference. You could assign it to a global variable, but I usually use a table of parameters (tblParams) since I usually end up with a bunch of them. I use a simple sql statement or DLookup to retrieve the parameter value when needed.

E.g.
svDrive = Left(Application.CurrentProject.Path,1) & ":\database\pictures\"
svSql = "UPDATE tblParams SET tblParams.FilePath = svDrive
Docmd.RunSql svSql

I assume you realize you could not use this code verbatim without declaring my variables in the procedure. If it did work as written without you doing that, you need to stop and research why this is bad (Option Explicit).

I suppose another way to handle your random drive letter problem might be to give the portable drive an alias name and use the UNC path, which is usually a fixed value, but I don't know how to set them up - I only know how to use them. Which makes me wonder: if you have any plans to split this database (which is always the preferred choice) your linked table references will fail every time the drive letter differs from the last linked value when you try to access one of them. Not a huge problem - I and probably many others have a routine to relink tables based on changing drive letters. Each table name in tblLinkedTables has the back end path. In your case, you'd need a DriveLetter field and do the same as with the pictures and over-write the drive letter. Most likely, your code would have to do these two operations first upon opening the database. You would not be able to have any references in the startup options that used a drive letter.

 

[HiTechCoach]

Micron has the correct idea but you do not have to use an update query. The idea of getting the path to the the back end and looking for a folder there for teh files is berst way..

I do store store the path not files with out the full path.

I would urge you to split your database now if it is not already. This will make updating it later very simple.

When the front end opens it can look in the same folder for the back end and them automatically relink the tables using Application.CurrentProject.Path.

The same idea can be used for the path to the files.

I have an example that shows how to store the path so you can easily move the files. It would take very liitle code changes to make it work using Application.CurrentProject.Path. See below

Document Links 2 (Click Here)

This is an update to the basic example of how to store the path to a file and also be able to view the file. You can browse using the standards windows common dialog to select the file. You can view the file using the application defined with the Windows File Associations. It uses the ShelExec API to open the file. It does not use the .Followhyperlink method.
This example is a continuous form that could easily be used as a sub form to attach multiple documents to a record.
***** Because it doesn't use the hyperlink data type, this new version stores the path in a way that allows the folder to be easily moved.

 

[Micron]

Boyd, I didn't download the file, but did look at the description. If this solution presents a common file dialog to choose a file or folder dialog to choose a folder, I'm not sure that serves Daryl's need. I thought that was to look at a larger image of an image he already has pulled into a form (abeit as a pdf, it seems) but perhaps I misunderstood. The reason for storing the image folder path in a table was because his main form likely has a recordsource which includes (or should, going forward) the path for the "thumbnail" image, so it's more efficient to use that. If it weren't for the volatile drive letter, it would not have to be updated at all, but I'd still store it in a field so I could use it in a form's recordsource. I agree that it's not necessary (especially if you use a global variable for the path, as I mentioned) but it's less efficient to keep calling it, plus I am one of those who believe global variables should be avoided if possible - unless perhaps in certain cases they are declared as Static. So I'm not sure what you're suggesting the db does with the Application.CurrentProject.Path value once it constructs it (for images). As for using that path to relink the tables as well, I agree if the back end is in the same folder, but I suspect Daryl is more inclined to use a subfolder for images since he alludes to knowing how to accomplish this with html.

Perhaps the use of pdf files to show these images is why you're suggesting a file dialog, but I would abandon the pdf route and only use images by passing their paths to an image control on a form.