COURSE of the MONTH

printing tifs form access

Hi,

I'd like to automatically print lots of tifs form my access database. The file and pathnames are stored in the database. I've spent the last night in trying OLE automation with wang image but I failed.

Can someone give me code snip?

(I don't wan to buy leadtools or something like that) It should be possible wihout third party tools: Double click on a OLE field opens imaging and you can print. But this is manual; and we have thousands of tifs....

Who is Participating?

If you do want to store the images or links to the images in Access, there are two ways.

The first has been used several times and is know to work. You can even take parts of the routine and have a directory with the files and scan through the directory with an OLE field on a form and swap out the source of the field and bring in each image one by one. If they want to print the image, then print the form. Since it only has no records, you will just get the form with the picture. You could even add a field which shows the file name.

The other would be to load the addresses in an imagelist control and then allow the user to move through a treeview and pull up the image they want. Print the form. We have done this for a limited number of images. Depending on the use of the application, if the app were open all the time, then the few minutes to load the links to the images up front is not a problem.

This is the code that I have been using and have given to several other members on EE recently. Use it if you can but other members have been able to use it as a template and convert it for their own use, even with VB6.

Jim

This shows you how to automatically append all files with a particular extension from a specified folder on the hard disk into a table. This routine is good for loading OLE objects, such as .gif, .jpg, .doc, .xls, or .bmp files that are associated with an OLE Server, into a Microsoft Access database.

Method to Import OLE Object Files

1. Create the following new table in Design view. Save it as tblLoadOLE:

2. Using the AutoForm: Columnar Wizard, create a new form based on the
tblLoadOLE table. Save it as frmLoadOLE. Because of the way that Access stores OLE objects, it is not possible to get to them directly in a table. They must be loaded through an Access form and Access will perform the behind the scene processing. I'm not sure whether this can be done with a VB6 form but since VB6 and Access 2000 share a common bond, I don't see why not.

3. Open the frmLoadOLE form in Design view.

4. Create three unbound text box controls in the form header section of
the form:

I don't want to make it sound simple but once you understand the process, it seems quite simple.

Rather than storing the file and pathnames in your database, store the the images in the database as oleobjects with either embedded images or linked images. One way puts all the images in the database. The other requires that they be kept separate. If you have the drive space, then embedding the images is faster and depending on how the drive is partitioned and blocked, take less space than the files themselves.

Next create a form which uses the table or a query to the table for a record source. When you pull down the oleobject from the fields list, Access understands what it is and sets up the correct type of box. Depending on the image size, you can one under another with a title or, I haven't gone this far in playing with this, have multiple images side by side.

Open the form and then either Print from the menu bar or issue a DoCmd.PrintOut. Prepare for a large block of time unless you have a super fast computer and printer. The images will print like continuous forms. So you might want to make the sizes so that you can get as many on the page as you want.

There really is no code snippet provided that you do the whole task from within Access.

No third party tools, no double click to open the image to print. You could even add a field in the table which breaks helps catalog the images by groups so that you pick and choose what you want to print.

Not knowing more about your app, this all the advice that I can give at the moment. One of my clients is actually using this to store and print his catalog images.

I didn't mark this an answer because I wasn't absolutely sure what you wanted. I just know that this works without any programming. Did I miss the boat?

Jim

0

mehlAuthor Commented: 1999-11-19

Hi Jim,

I don't have the possibility to save the TIFs with OLE in the database. the Images are produced from a scanning system. I only get lists of filenames out of this system. And we do have a lot (>> 100.000) images.

One way I thought of was dynamically building up the OLE entries after the selection of the images to be printed. (they are selected by date or number) But I didn't managed the setup of OLE entries from VBA.

So the code snippet I need is the setup of an OLE entry when I do have the filename.

I go with JimD: Not only do Access put it's own OLE wrapper around the object. It also stores images in some sort of bitmap/DIB format that makes your 100KB JPG picture increase the database size by 1MB easily. mehl does not store the images in the database though, so this time this problem is not relevant.

JimM: You have got to get those sleeping routines back in business ;-)

Just to temp you guys: We have recently developed a form that stores the images in a BLOB field as bits and bytes instead of as a OLE object. This means that a 100KB file will take 100KB of room in the database. If the file size will benefit from compressing, we compress it before inserting. When you want to view an image it is "downloaded" on demand and then shown in an unbound OLD control on the form. This combines the best of the two worlds. All info kept in the database and no monstreous increase in storage capacity needed. You will need the same space, at least, if you want to store the file in a directory. This also means that when using SQL Server our users does not need file access to the server anymore, IP port 1433 is enough. The network departments in the company are very happy!

So your using GetChunk/AppendChunk to read/write the BLOB to a temp file on demand and then use it with an unbound OLE or image control?

Sounds like a nice solution for some problems I've come across. In fact, while exploring the MSKB the other day, I came up with an article that has all the code to do it (read/write BLOBS) and was quite surprised and here your've already gone and done it!

However I still think in some cases it's good to have the file out there as 3rd party tools can then have access to it without firing up Access everytime. Of course that leads to other problems as well (like security).

Yes, we use the chunk methods. You can make it download all in ones, or little bits that combines to the resulting file. This is nice on slow connections when it is necessary to show some kind of progress before the user starts calling or switches of his/her computer.

We have been using the same approach for years to store and retrieve system files that we needed along with the application (fonts, dlls etc.) Now we just used this approach on the photo form. Our problem is that we have users located on different networks, and they do not all have the same network drivers mapped and some of them does not even have file access to the servers where the files where located.

Your last couple of comments about my participation in this question haven't set well with me. I always try to be a bit more diplomatic in my response to other's comments. These are remarks that don't belong in a discussion. They are best, in my opinion, made outside. Want to meet me in the alley? :-)

I agree a bit with JimD: If we copy/paste articles from MS then it is smart to include a couple of lines more from the top. Those that hold the article ref etc. This way the questioner, and others, can look it up and find linked articles etc. if they want to. The comment from JimD seems to be quite diplomatic to me, but I have had my cup of coffee today so I am "on the happy side" ;-)

This article shows you how to automatically append all files with a particular extension from a specified folder on the hard disk into a table. This routine is good for loading OLE objects, such as .gif, .jpg, .doc, .xls, or .bmp files that are associated with an OLE Server, into a Microsoft Access database.

This article assumes that you are familiar with Visual Basic for Applications and with creating Microsoft Access applications using the programming tools provided with Microsoft Access. For more information about Visual Basic for Applications, please refer to your version of the "Building Applications with Microsoft Access" manual.

NOTE: To associate a graphic file with an OLE Server, open it with an OLE Server package such as Microsoft Imager or Microsoft Paint, and save the file.

For information about working programmatically with an OLE object in a form in Microsoft Access version 2.0, please see the following article in the Microsoft Knowledge Base:

ARTICLE-ID: Q114214
TITLE : ACC2: How to Programmatically Embed or Link an Object in a
Form

MORE INFORMATION
"

Here comes the part that was in JimMs comment. Note that JimM has made some extra comments in the text to fill in missing info...

Hell, I can't be expected to be 'Little Miss Sunshine' everyday. And I guess that is what I deserve for assimilating all that Access knowledge out there and then writing a easy to follow, well thought out explanation or tutorial all the other times.

Everybody in this site grabs snippets of code, remarks, etc. from any place that they can find it and don't always attribute the source of their information. I've even seen direct lifts by other experts from comments that I have used to answer previous questions being offered as comments and answers to newer questions. I never complain. I'm flattered that I'm being copied.

However, I feel that a lift of a portion of Microsoft's knowledge base is open to anyone if they know where to find it. To me, it is better than pointing someone to the article as a comment or answer. At least this way, everybody can see what is being talked about and what the feedback means. I wouldn't say I'm too lazy but my modem isn't fast enough to let me jump around from this page to that page and still keep what I read straight in my head when I come back. So I appreciate seeing everything in one thread. Scrolling back and forth is not too bad.

Besides, I feel that I have a right to edit any public document like that anyway that I want. I didn't include the rest of the article because, in my opinion, there was nothing germaine left.

It is interesting that knowledge is necessarily about 'knowing' as much as it is about 'finding'. The problem with most knowledge bases, either paper like a dictionary or encyclopedia, or electronicm is knowing what to ask or how to look it up.

I've spent many hours trying to find out more about toolbars and shortcuts to no avail, when I should have been searching for commandbars.

Point well taken, Trygve. I'll try to remember that but don't fuss too badily if I don't. :-)

This particular article has some personal significance in that I know the gentleman who wrote it and came up with the code that was the basis for the article. He's a product support person for Microsoft and came up with the code in response to a question on the MS Access forum on Compuserve about 5 years ago.

The reason for my posting though is that I feel I need to make a comment about your statement of:

"Besides, I feel that I have a right to edit any public document like that anyway that I want. I didn't include the rest of the article because, in my opinion, there was nothing germaine left."

Almost all MKSB articles are copyrighted and do include a terms of use statement at the bottom. So for you to say that you have the right to do anything you want with a public document is incorrect.

Again, I'm not trying to start anything here, but just want to say that it bears mentioning. We had a long discussion on Compuserve about the legality of posting parts or even whole MSKB articles. The conclusion was that the safest bet was to post a reference and let the member know how to get it via E-Mail, or to post the article in its entirety (without doing so violates Micorsofts terms of use clause).

Thanks for the clarification. I'm probably wrong but I seem to remember something from Microsoft about being able to use any information found in the Knowledge Bank for any purposes. A copyright by itself does not prevent someone from making a derivitive of the information copyrighted or to use portions of the material for educational purposes. All of the language manuals from Microsoft say that they are copyrighted with All Rights Reserved. There is also a notice "No part of this document may be reproduced or transmitted in any form or by any mean, electronic or mechanical, for any purpose, without the express written premission of Microsoft Corporation."

When the first products from Microsoft came out, we had a big discussion about this in BIX and concluded that if MS intended to uphold this 'legal' statement that no one would ever be able to use the manuals to write code and all code that was written using any code samples from said manuals could be taken away from a programmer in court.

Of course it would be stupid for Microsoft to try to enforce such an issue and most legal minds say that it is un-enforceable.

I'll probably continue to take portions of information that I find from various MS sources and develop derivitive works from them for educational purposes, ie. EE, until I get a notice from MS's lawyers that they recognize me as a sufficient threat to MS and order me to cease and desist.

I'm not a rebel but there is a line in the sand that I will fight over.