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....
mehlAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
JimMorganConnect With a Mentor Commented:
mehl:

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:

       Table: tblLoadOLE
       ------------------------
       Field Name: OLEID
          Data Type: AutoNumber
       Field Name: OLEPath
          Data Type: Text
          Field Size: 255
       Field Name: OLEFile
          Data Type: OLE Object

       Table Properties: tblLoadOLE
       ----------------------------
       PrimaryKey: OLEID

 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:

       Form: frmLoadOLE
       ------------------------
       Text Box:
          Name: SearchFolder
       Text Box:
          Name: SearchExtension
       Text Box:
          Name: OLEClass

 5. Create a command button on the form:

       Command Button
       --------------
       Name: cmdLoadOLE
       Caption: Load Files

 6. Type the following event procedure in the OnClick property of the
    cmdLoadOLE button:

       Private Sub cmdLoadOLE_Click()

       Dim MyFolder As String
       Dim MyExt As String
       Dim MyPath As String
       Dim MyFile As String
       Dim strCriteria As String

       MyFolder = SearchFolder
       ' Get the search path.
       MyPath = MyFolder & "\" & "*." & [SearchExtension]
       ' Get the first file in the path containing the file extension.
       MyFile = Dir(MyPath, vbNormal)
       Do While Len(MyFile) <> 0
          [OLEPath] = MyFolder & "\" & MyFile
          [OLEFile].Class = [OLEClass]
          [OLEFile].OLETypeAllowed = acOLEEmbedded
          [OLEFile].SourceDoc = [OLEPath]
          [OLEFile].Action = acOLECreateEmbed
          ' Check for next OLE file in the folder.
          MyFile = Dir
          ' Go to new record on form.
          ' For Access 95 only, use the following Line of code:
          DoCmd.DoMenuItem acFormBar, acEditMenu, 12, 4, acMenuVer70

          ' For Access 97 only, use the following line of code:
          DoCmd.RunCommand acCmdRecordsGoToNew
       Loop

       End Sub

 7. Save the frmLoadOLE form and open it in Form view.

 8. Type the full path name of the folder you want to search in the
    SearchFolder text box.

 9. Type the file extension you want to load in the SearchExtension text
    box, such as bmp, jpg, doc, xls, tif, or gif. Do not type a period as
    part of the extension.


10. Type the Class name for the type of file you are loading, such as
    Paint.Picture for .bmp files.

    NOTE: To determine the Class name of an OLE object, see the
    documentation for the application supplying the object.


11. Click the Load Files button. Note that All files that match the
    SearchFolder and SearchExtension you entered are added to the
    tblLoadOLE table.


0
 
JimMorganCommented:
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:
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.
 
0
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

 
Jim Dettman (Microsoft MVP/ EE MVE)PresidentCommented:
I won't do what Jim suggests.  As far as printing, it really doesn't matter where the image resides.

  On the subject of where it resides, Access is terrible at storing any kind of graphic image because it puts it's own OLE wrapper around the object.  This can cause the MDB file to grow considerably.

  The accepted technique over the years has been the storing of a path name and using unbound OLE or image fields to display the image as required (as you are doing).

  Also, the fact that 3rd party tools can be used on the image without invoking Access can be a major plus.

  To print the image depends on the OLE server that your using.  You didn't mention the version of Access, so I don't know if this will work or not.

  You should be able to insert a Wang (or Kodak depending on your version of Windows) image control in your form.

  You'd then do something like:

With ImgEdit1
   .Image = "E:\tiffWANG\Simplicity1024.tif"
   .Display
   .PrintImage 1, 1, 0
End With

HTH,
JimD.
0
 
JimMorganCommented:
How about the printing capabilities?  I thought that this was the focus of the question.

I'm sorry.  I'm too tired to work on it any more tonight.  It is 5AM and I'm afraid once again that I got lost in EE and spent the whole night trying to figure how to get out. :-)

I'll look up my resources again when I'm more fresh.

Jim
0
 
TrygveCommented:
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!
0
 
Jim Dettman (Microsoft MVP/ EE MVE)PresidentCommented:
Trgve:

  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).

JimD.
0
 
TrygveCommented:
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.
0
 
Jim Dettman (Microsoft MVP/ EE MVE)PresidentCommented:
JimM:

  If you going to post that much of a MSKB article and not even bother to paraphrase it, you should acknowledge the source.

  Besides which, I really don't see how it ties into the ability to print .tif images.  As we've already discussed, it doesn't make any difference in terms of printing of where the image is stored.

JimD.
0
 
JimMorganCommented:
JimD:

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? :-)

JimM
0
 
TrygveCommented:
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" ;-)

For the record, here are the "missing parts of the article"


"
ACC: How to Load OLE Objects from a Folder into a Table
ID: Q158941

The information in this article applies to:

Microsoft Access versions 7.0, 97


SUMMARY
Moderate: Requires basic macro, coding, and interoperability skills.

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...

Here is the rest of the page.

"
Additional query words: Directory Multiple
Keywords          : kbinterop kbprg IntpOle
Version           : 7.0 97
Platform          : WINDOWS
Hardware          : x86
Issue type        : kbhowto

Last Reviewed: January 8, 1999


--------------------------------------------------------------------------------
Send feedback to MSDN.Look here for MSDN Online resources.
"
0
 
JimMorganCommented:
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.

Can I get down off my high-horse now?  :-)

Jim
0
 
TrygveCommented:
If you had only included a "MS ARTICLE-ID: Q114214", then none of this would have happened ;-)
0
 
mehlAuthor Commented:
Hi JimMorgan,

thanks for your answer. It took me only about 1h to get it to work. Great.

For me it's (really very) allright that the info is from the knowledge base. I didn't find it there. The reason was that I didn't know what exactly to look for.

Thank you.

Christian Mehl
0
 
TrygveCommented:
Noone has a problem with knowledge base articles, we love them!

But if the source link or ID is indicated it makes it easier to look it up and possible get more information and perhaps even links to related articles etc.

How did you solve the printing part?
0
 
JimMorganCommented:
Christian:  I'm pleased that I could help out.  You're welcome.

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.  :-)

Jim
0
 
TrygveCommented:
I will as usuall try to cover for you :-))
0
 
Jim Dettman (Microsoft MVP/ EE MVE)PresidentCommented:
JimM,

  I really didn't mean to kick up a fuss on this.

  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).

JimD.
0
 
JimMorganCommented:
JimD:

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.

Jim
0
All Courses

From novice to tech pro — start learning today.