Monitoring an out-of-process compression can be tricky so we’ve developed a safeguard that covers different contingencies such as compression occurring too quickly or when there is a delay between compression dialog’s progress bar is filling up and it is closing. Because it’s an interactive action that occurs asynchronously, we must write waiting into our code. In this case, we need to wait until the compression has completed before taking any further actions. This also means it comes with UI components which may impose some issues, especially when we are automating the process. So when we invoke a “CopyHere”, it’s equivalent to actually dragging a file and dropping it in a folder (or a zip file). In either approach, we can use VBA to rename a file as simply:įinally, when using Shell32, we are essentially automating the visual aspect of Windows Explorer. Option 1 is more safe but requires creating a temporary directory & cleaning up, but when you have control over what the target directory will contain, option 2 is quite simple. This can be solved in two different ways: 1) unzipping the files into a temporary directory, renaming them, then moving them into the final directory or 2) rename a file prior to zipping so it will be uniquely named when unzipped and thus can be renamed. Still, referencing can be useful for developing & validating your code prior to switching to late binding & distribution.Īnother issue we have to handle is that as there is only either “Copy Here” or “Move Here” method available with a Shell32.Folder object, we have to consider how we should handle the naming of files that will be zipped, especially when we are unzipping the files that potentially have the same name or should replace the original files in the target directory. However, our preference is to late-bind as to avoid any problems with versioning that may occur when running code on different computer with different operating systems, service packs and so forth. Early-binding is not subject to the string variable bug. In VBA references dialog, it is labeled “Microsoft Shell Controls and Automation”. Set f = CreateObject(“Shell.Application”).Namespace(CVar(s))Īlternatively, you can choose to early bind by referencing Shell32.dll (typically in WindowsSystem32 folder). Converting the string into a variant will work also: This is why Ron de Bruin uses a variant in his sample. Set f = CreateObject(“Shell.Application”).Namespace(s)į.CopyHere “C:MyText.txt” ‘Error occurs hereĪccording to MSDN documentation, if Namespace method fails, the return value is a nothing and therefore we can get seemingly unrelated error 91 “With or object variable not set”. A Shell32.Folder object can be either a real folder or a zip folder so by manipulating a zip file as if it was a Shell32.folder, we can then use the “Copy Here” method of the Shell32.Folder to move the files in and out of a zip file.Īs Ron has noted, there is a subtle bug when dealing with retrieving a Shell32.Folder via Shell32.Applications’ Namespace method. Thankfully, Ron de Bruin has provided a solution which involves automating the Windows Explorer (aka Shell32). (Reading between the lines, it seems to do with licensing constraints). When you think about it, it is quite odd considering that zipping is built-in to Windows Explorer. One sore point with zipping is that there’s really no simple way to zip or unzip files without depending on a third-party utilities. On occasions, we have a need to zip files as part of our workflow within Access VBA.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |