We have a program that processes PDF documents - Automated. We fail with certain PDFs because they are malformed . When we open the PDFs in acrobat, it opens it. I see that Acrobat goes to extra measures to fix the malformed PDFs. So in our case, someone manually has to open and save them to make them clean. Is there a way I can programmatically do this in Python or Powershell? Has anyone done this?
Thanks!
You might try this this link.
You can run a macro from powershell. You can also set up a scheduled task to run your powershell script in task scheduler at pretty much any interval you like (TASKSCHD.MSC) This particular example has a msgbox for the path to folder but it loops through all pdf files in a folder, flattens and saves. Perhaps flattening might not be required but might help with a malformed PDF.
** This relies on Acrobat and uses the javascript API through the excel ... I'm not sure if libreoffice draw has has a javascript api like acrobat. I'm not aware of any open source alternatives that have that sort of functionality. If anyone is please let me know.
So I'm having to run someone else's excel app on my PC, and I'm getting "Can't find Project or Library" on standard functions such as date, format, hex, mid, etc.
Some research indicates that if I prefix these functions with "VBA." as in "VBA.Date" then it'll work fine.
Webpages suggest it has to do with my project references on my system, whereas they must be ok on the developer's system. I'm going to be dealing with this for some time from others, and will be distributing these applications to many others, so I need to understand what's wrong with my excel setup that I need to fix, or what needs to be changed in the xls file so that it'll run on a variety of systems. I'd like to avoid making everyone use "VBA." as an explicit reference, but if there's no ideal solution I suppose that's what we'll have to do.
How do I make "VBA." implicit in my project properties/references/etc?
-Adam
I have seen errors on standard functions if there was a reference to a totally different library missing.
In the VBA editor launch the Compile command from the menu and then check the References dialog to see if there is anything missing and if so try to add these libraries.
In general it seems to be good practice to compile the complete VBA code and then saving the document before distribution.
I had the same problem. This worked for me:
In VB go to Tools ยป References
Uncheck the library "Crystal Analysis Common Controls 1.0". Or any library.
Just leave these 5 references:
Visual Basic For Applications (This is the library that defines the VBA language.)
Microsoft Excel Object Library (This defines all of the elements of Excel.)
OLE Automation (This specifies the types for linking and embedding documents and for automation of other applications and the "plumbing" of the COM system that Excel uses to communicate with the outside world.)
Microsoft Office (This defines things that are common to all Office programs such as Command Bars and Command Bar controls.)
Microsoft Forms 2.0 This is required if you are using a User Form. This library defines things like the user form and the controls that you can place on a form.
Then Save.
I have experienced this exact problem and found, on the users machine, one of the libraries I depended on was marked as "MISSING" in the references dialog. In that case it was some office font library that was available in my version of Office 2007, but not on the client desktop.
The error you get is a complete red herring (as pointed out by divo).
Fortunately I wasn't using anything from the library, so I was able to remove it from the XLA references entirely. I guess, an extension of divo' suggested best practice would be for testing to check the XLA on all the target Office versions (not a bad idea in any case).
In my case, it was that the function was AMBIGUOUS as it was defined in the VBA library (present in my references), and also in the Microsoft Office Object Library (also present). I removed the Microsoft Office Object Library, and voila! No need to use the VBA. prefix.
In my case, I could not even open "References" in the Visual Basic window. I even tried reinstalling Office 365 and that didn't work. Finally, I tried disabling macros in the "Trust Center" settings. When I restarted Excel, I got the warning message that macros were disabled, and when I clicked on "enable" I no longer got the error message.
Later I re-enabled all macros in the "Trust Center" settings, and the error message didn't show up!
Hey, if nothing else works for you, try the above; it worked for me! :)
Update:
The issue returned, and this is how I "fixed" it the second time:
I opened my workbook in Excel online (Office 365, in the browser, which doesn't support macros anyway), saved it with a new file name (still using .xlsm file extension), and reopened in the desktop software. It worked.
Even when all references are fine the prefix problem causes compile errors.
What about creating a find and replace sub for all 'built-in VBA functions' in all modules,
like this:
replace text in code module
e.g. "= Date" will be replaced with "= VBA.Date".
e.g. " Date(" will be replaced with " VBA.Date(" .
(excluding "dim t As Date" or "mydate")
All vba functions for find and replace are written here :
vba functions list
For those of you who haven't found any of the other answers work for you.
Try this:
Close out of the file, email it to yourself or if you're at work, paste it from the network drive to your desktop, anything to get it to open in "protected mode".
Now open the file
DON'T CLICK ANY ENABLE EDITING OR THE YELLOW RIBBON
Go to the VBA Editor
Go to Debug - - Compile VBA Project, if "Compile VBA Project" is greyed out, then you may need to click the yellow ribbon one time to enable the content, but DO NOT enable macros.
After you click Compile, save, close out of the file. Reopen it, enable everything and it should be OK. This has worked for me 100% of the time.
In my case I was checking work done on my office computer (with Visio installed) at home (no Visio). Even though VBA appeared to be getting hung up on simple default functions, the problem was that I had references to the Visio libraries still active.
I found references to an AVAYA/CMS programme file? Totally random, this was in MS Access, nothing to do with AVAYA. I do have AVAYA on my PC, and others don't, so this explains why it worked on my machine and not others - but not how Access got linked to AVAYA. Anyway - I just unchecked the reference and that seems to have fixed the problem
I've had this error on and off for around two years in a several XLSM files (which is most annoying as when it occurs there is nothing wrong with the file! - I suspect orphaned Excel processes are part of the problem)
The most efficient solution I had found has been to use Python with oletools
https://github.com/decalage2/oletools/wiki/Install and extract the VBA code all the modules and save in a text file.
Then I simply rename the file to zip file (backup just in case!), open up this zip file and delete the xl/vbaProject.bin file. Rename back to XLSX and should be good to go.
Copy in the saved VBA code (which will need cleaning of line breaks, comments and other stuff. Will also need to add in missing libraries.
This has saved me when other methods haven't.
YMMV.
Using VBA outside of the MS-Office suite of applications, is there a good way to create a PDF document, or another light-weight document that can be converted to a PDF?
I have data within classes, which I want to get into a PDF, how do I do that quickly, without resorting to opening up MS Word, MS Excel, etc?
This link seems like it might be helpful with solving your issue.
http://forums.adobe.com/thread/840511
According to the information there you can print to the adobe pdf virtual printer and it will generate the file. The people on that forum were doing something with emailing the file afterwards and generating the file from access data, but it looks like a solution that will work for any VBA project.
Part of my job right now is to build some dynamic functionalities into Microsoft Office documents. The only means I've found to do this is through VBA - and thus, the VBA editor which comes built in to Office docs.
The VBA editor is awful. It's missing a million different functionalities that modern development environments need to support. But the worst part is that I'm a hard-core Vim lover, and the VBA editor is barely any better than notepad.
So: Is there any way I can effectively use Vim to do VBA programming? Short of copy-pasting my code into the VBA editor from a different window when I want to try it?
I've never used the VBA editor, but here's something I've done with MS Visual Studio. (MSVS's editor does have some nice features, but I still prefer vim for most editing.)
I open or create the source file in MSVS. I then get the full path to the file (by right-clicking on the tab and selecting "Copy Full Path"), and open the same file in vim in a different window.
I use alt-tab to bounce back and forth between vim and MSVS. When I make a change in vim, I use :w to write the change, then alt-tab back to MSVS. The MSVS editor notices that the file has changed on disk and offers to read the updated version.
Alternatively, if I change the file in MSVS, I write the file (File > Save ...), then alt-tab to vim and use :e! to read the updated file into the vim buffer.
There's no need to copy-paste the code, since both editors are operating on the same disk file. I just have to be very careful not to make changes in both vim and MSVS without writing the file to disk.
It's ugly, and it's not for everyone, but it works for me. Maybe it will work for you.
I use Cygwin, so it's actually a little more complicated; Cygwin programs, including vim, don't recognize Windows-style paths. I can do this:
vi $(cygpath 'WINDOWS_PATH')
where WINDOWS_PATH is pasted from the full path I get from MSVS. The single quotes are necessary to keep the shell from interpreting the \ characters. If you're using a Windows native vim, this step isn't necessary.
That's an interesting opinion. I used VI briefly about fifteen years ago and based on that I contend that the VBA editor is far more suited to its purpose than VI (or VIM?) would be. Is there one particular piece of functionality that it is missing from the VBA editor that precludes you effectively using it for its purpose (editing VBA)? VBA has not been enhanced for many many years, but the fact is it can't be killed off because everyone finds it so easy to use.
If you wish you can write some piece of code in your preferred language that manipulates your word document via COM objects (if it supports that). Then you can call your external piece of code from a simple stub within your Word document. You need to get around some security constraints though in your Word document.
For example I could write some code in VBScript or VBA or Powershell or .Net that manipulates a word doc. I can call that from a small piece of VBA (that might be attached to a button or something in the standard word toolbar)
In C#/.NET I am able to open a DOCX file as a ZipPackage, then manipulate its XML parts separately by getting them as PackageParts and reading from / writing to their Streams using .GetStream().
As far as I'm aware, VBA is a million miles away from having this functionality (especially given that I've not found anything about it after a lot of web searching), but I just thought I'd check: can any VBA aficionados confirm or deny whether VBA has some kind of built-in functionality for manipulating DOCX ZipPackages, or would you pretty much have to write your own VBA DOCX parser from scratch?
Mostly the answer is no, but there is a glimmmer of yes.
Regarding your specific question of managing PackageParts from their streams. You could probably do this with some kind of "unzip" utility and then knowing the OPC structure, navigate to whereever you want in the Parts and change things with XSLT or other XML manipulation technologies - but you wouldn't be able to do this on the ActiveDocumentbecause its stream is already in use by nature of it being open. You could use VBA to create a copy of it and manipulate that one in a really cumbersome manner and when your manipulation is done, have VBA close and delete the current ActiveDocument and open your manipulated one as the new ActiveDocument.
On the other hand, there is a way to manipulate WordprocessingML for the current ActiveDocument from VBA, but it would be incredibly difficult to do. Have an open document, select something and then to the VBE. Then run this:
Sub InjectXML()
Dim wd As Document: Set wd = ActiveDocument
Debug.Print wd.Range.WordOpenXML
End Sub
You'll see all the WordprocessingML spit out in the immediate window. This is actually "Flat OPC WordprocessingML" as it is all maintained in a single string of XML. By using ActiveDocument.Range.InsertXML, you could technically insert Flat OPC-type of WordprocessingML back into the document at the selected location. Here's an example of someone using C# to do this via interop and Linq-to-XML. To do this in VBA would be incredibly hard.
So again, the answer is mostly "no", but a little bit of "yes".
You do not state your ultimate aim, but I guess one possibility is to use Microsoft.office.interop.word to manipulate the word document.