topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Friday December 13, 2024, 11:35 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Adding the ability to zip files from multiple locations to a vbs script  (Read 4911 times)

questorfla

  • Supporting Member
  • Joined in 2012
  • **
  • Posts: 570
  • Fighting Slime all the Time
    • View Profile
    • Donate to Member
There may not be a way to do this.  I have seen a few comments about VBS and zip not being compatible. 
The current working VBS script is used to automate adding multiple attachments to an Outlook pre-addressed email and sending it out all at once.  As written, the files can be selected from anywhere on the system by using Ctrl+click to select them and copy/paste or drag-drop to get them to the script which then does the rest.  They all get attached regardless of where they are located once selected. I have never tried to add more than about 10 but I think the only limit is the file-size allowed by Outlook for an attachment.

Most file types can only be attached to an email by first adding them to a zip or other 'protective' shell and adding all the collected files to a single zip when they come from multiple locations is the problem.  There seems to be no way to do this within the bounds of the VBS script and also no way to do it externally and then bring the results back into the script for completion.

If anyone can supply the missing "zip from anywhere" lines to the script it would be appreciated. :)

Somewhere after this line is where I presume it needs to be added.   
..       Set objArgs = WScript.Arguments 'gets paths of selected files   ..
Once the selected paths are set, those files need to be either zipped separately or added to a single larger zip before they are added to the email as attachments so Outlook will process it without choking up.  This works as-is as long as all files are .txt or other allowed file types.


Code: Visual Basic [Select]
  1. Option Explicit
  2. Dim objArgs, OutApp, oNameSpace, oInbox, oEmailItem, olMailItem
  3. Dim a, oAttachments, subjectStr, olFormatHTML
  4. olMailItem = 0
  5. olFormatHTML = 2
  6. Set objArgs = WScript.Arguments 'gets paths of selected files
  7. Set OutApp = CreateObject("Outlook.Application") 'opens Outlook
  8. Set oEmailItem = OutApp.CreateItem(olMailItem) 'opens new email
  9. oEmailItem.To = " "
  10. oEmailItem.cc = " "
  11. For a = 0 to objArgs.Count - 1
  12. Set oAttachments = oEmailItem.Attachments.Add(objArgs(a))
  13. subjectStr = subjectStr & Right(objArgs(a),Len(objArgs(a))-(InStrRev(objArgs(a),"\"))) & ", " 'recreates the default Subject e.g. Emailing: file1.doc, file2.xls
  14. Next
  15. If subjectStr = "" then subjectStr = "No Subject "
  16. oEmailItem.Subject = "" & Left(subjectStr, (Len(subjectStr)-2))
  17. oEmailItem.BodyFormat = olFormatHTML
  18. oEmailItem.Display
  19. oEmailItem.Send

If there is another method of accomplishing the same goals in another language that would be OK as well. :thmbsup:

Note:  Giving credit where credit is due:  This code is originally from the 'Slipstick Outlook Forum' and named 'Joseph's Script Method'
It works extremely well for what it was originally written to do.

MilesAhead

  • Supporting Member
  • Joined in 2009
  • **
  • Posts: 7,736
    • View Profile
    • Donate to Member
You may find this useful:

http://stackoverflow...-directory-structure


If you do not need to preserve the directory structure then you could just demp the files in a temp folder. That is if you are sure there will be no name collisions.

questorfla

  • Supporting Member
  • Joined in 2012
  • **
  • Posts: 570
  • Fighting Slime all the Time
    • View Profile
    • Donate to Member
Yeah, I think I read everything in StackOverflow and all their sister sites as well.  Plus several including MS Tech Net and all of them are vague to nonexistent about doing what this script does in a way to keep it all on full auto. 

If it requires any interaction then it can't be used as a drag and drop receptacle as I do it now.  Currently, if there is more than one file with same name it follows the normal windows doctrine of using (2) etc for duplicate files but does not stop to ask me anything.  Both copies get attached if they come from different paths.

Generally speaking, there would normally not be duplicates though.
 
 :Thmbsup:
Surprise!  Thanks for a wake up Miles!  I had given up on Stack but this was one I had not read yet and does have some interesting options using Java.

The thing is, if you check the script it does not actually copy or move anything at all.  It attaches the files directly tot he email based on the path to the file to be attached.  There is no point in time that I could perform the compression on all the files without adding a complete section to do that.

I was hoping I could intercept the calls for the files to be attached and run each of them through a compression before the get attached.  I actually would prefer each to be a separate file if possible so a procedure such as this would do that.

As an aside.  While this is more of a 'stunt' than anything else,  I did figure out that I could get by if I simply add the extension of .txt to each file-name.  Then program.exe would become program.exe.txt before being attached and this works perfectly. Outlook sends them with no complaints then.
« Last Edit: May 12, 2016, 03:53 PM by questorfla »

MilesAhead

  • Supporting Member
  • Joined in 2009
  • **
  • Posts: 7,736
    • View Profile
    • Donate to Member
I found this article how to use 7-zip from vbs:

http://naterice.com/...h-vbscript-and-7zip/

Another consideration, WinRar is not free but you can seamlessly build in error correction data, say the default 10%, during compression.  And the unRar part is free.  Compression tools like 7-zip can unrar the .rar files.  Zip is quick but it has the inherent problem that if one bit is corrupted the CRC fails.