I'm writing an application that processes PowerPoint presentations and I'm looking into ways of detecting whether or not a PowerPoint presentation has a password if it does then stop processing it.
It seems to me that there is no way to check if the presentation is password-protected. You have to open the document first to make properties accessible. You have to provide the password when you are opening the document.
There is a Password Property you can check.
I've found a workaround on Expert Exchange:
The problem is the following: Visual
Basic is a single threaded
application, this means that you cant
put a certain procedure on hold and
proceed with another (in the same
application). When powerpoint has an
"on open"-password set, the
CreateObject procedure inside your
application is put on hold untill
powerpoint releases it, this is when
the user types in a password. There is
no way around this that I know off,
but you can make a workaround:
Make 2 applications, 1 application is
the application you already have, the
second one is a "powerpoint unlocker".
You run the second program just before
you open the protected powerpoint
presentation in application 1. You can
do that with the shell command. The
"powerpoint unlocker" can be as
advanced as you want it to be, you can
for example provide command line
parameters to specify which
presentation must be unlocked with
what password. Then you use the
findwindow api to get the window
handle of the locked presentation.
Once you have that, you use the
sendmessage api to input the password.
After this the "powerpoint unlocker"
unloads and the first application can
resume with its excution.
I hope this helps!
Osmodean
Consider looking at this -
http://blogs.msdn.com/b/openspecification/archive/2009/07/17/overview-of-protected-office-open-xml-documents.aspx
For a PPTX document, you can examine the first 8 bytes to look at the header (should be [d0cf 11e0 a1b1 1ae1] for an encrypted file), and know if it is an encrypted PPTX or not.
However, for files created with Office 2003 (default extension .ppt), the header is the same (MS-CFB header). So, if somebody creates an office 2003 document and then renames it to a PPTX, your code will consider it as an encrypted document (whereas, it wouldn't necessarily be one).
If you are working with documents already opened in Powerpoint, you can use the SaveCopyAs function to first save the document to disk in the pptx format (use the default option in the second parameter), and then examine the header to check if it's an encrypted file.
Consider looking at this -
https://msdn.microsoft.com/ko-kr/library/dd948895(v=office.12).aspx
For a PPT(office 2003) document, you can examine the unsigned integer(0xF3D1C4DF bits) to identify whether the file is encrypted.
Related
I am relatively new to VBA and I need a solution to a problem I have.
Currently I have two excel documents - one which is a form where the user enters data and this is then sent to a second document which acts as a database for this information. My issue is that when people are looking in the database data cannot be sent to the second document because it is open and there are overwrite errors.
It is my intention to have the databases location hidden away within a network drive so it cannot be found meaning the only way to access I is through a button on the first document.
Is there a way that when the open button is pressed to access the database that a copy of the document is opened instead of the actual document itself so data can still be sent?
So, you have a few options here:
a) Use an actual database. Not so much to solve this specific problem (that too) but also because making a "database" in excel is usually a terrible idea in the long run. But I know that is not always possible, and it's overkill in many situations so...
b) Have that "database" workbook set as "Shared Workbook". Shared Workbooks come with their own host of issues (namely, can't edit certain aspects like the VBA in them, conditional formatting, and others). But if it's strictly for reading and writing data, it can work. It also comes with its own version control, so that's good.
c) What you originally asked. It is quite simple really, as you said, you make a copy of the document, ideally in one of the user's local folders . You can do this using FSO (see VBA to copy a file from one directory to another)
The only issue with this last approach is that you need some way to track when the user has closed that temporary file, in order to delete it (if you absolutely don't want to leave any traces). Otherwise, you can just leave it, and overwrite that same file each time the user presses the "View Database" button.
TL DR version: what errors should I specifically look for in a error handler with an excel vba running a word template and saving as word doco and pdf.
For the first time, I am actually giving a macro spreadsheet to someone excel literate, but macro illiterate.
This spreadsheet basically opens a bunch of word templates, changes some bookmarks, saves as a word document and as a PDF.
I cannot afford for this spreadsheet to fail, which brings me to error handling.
I haven't really pushed into error handling too much previously. But I have come up with a list of possible errors the 3rd party could run into
Invalid Inputs (various)
Cannot find word templates
Cannot find bookmarks
Cannot Save As Word (various reasons)
Cannot Save As PDF (various reasons)
Not having Microsoft Word 16.0 object library
Is there any other errors I should be catching?
how do I deal with the Not having Microsoft Word 16.0 object library?
Sorry to be writing this - I know it's not the answer your looking for, but my experience has been that it is not possible to create an exhaustive list of errors that might occur... especially user errors.
Nevertheless... here are some more to add to your list:
Check if template or other source document is already opened by someone else
Check if directory exists (if different to the one being pulled from)
Try to lock down as much as possible for user... let them only access that which they absolutely need to
I have a system with an Excel spreadsheet template file which is used for invoicing. I would like the user to be able to click a button on an Xpage, which will then open the spreadsheet and enter the latest invoicing data in Excel. I don't mind if Excel is either the application on their machine or on the server, but my preference would be the application locally on their machine.
I've looked into Xagents, as I feel this is probably the answer. I know they can be used to create Excel but I have not been able to locate any mention of opening an Excel file, and entering data into specific cells.
Is this possible?
EDIT: you can use Apache POI for editing and creating Microsoft Office documents. This is a java project which gives you a handle to office documents and this can be used using java.
A good starting point can be the blog of Christian Guedemann from webgate:
http://guedebyte.wordpress.com/2012/09/17/documents-and-spreadsheets-with-xpages-building-the-kernel-part-ii/
(end of edit)
The only way I KNOW and tried to write data from Notes to Excel is exporting the data to an HTML page and setting the Content Type accordingly (e. g. as described here (there are a lot more resources available for taht):
http://www.dominoguru.com/pages/developer2010_xpagexlsexport.html
I am not sure if this is of help but it seems that this project can help you:
http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=ZK%20Spreadsheet%20for%20XPages
As far as I can see this project can load Excel files from XPages - and then it should also be possible to edit the files.
Besides that the only solution I can think of is a Notes Agent that is called from the XPage. This agent can then run in background and do all the excel stuff. After running, the XPage can show a link to the Excel file. Actually this is the solution I would consider to implement - but maybe others step in with better answers here.
You don't want to introduce a dependency on Excel in your application -- wouldn't work with an iPad front-end. Rather have a look at the ZK Spreadsheet, it will fulfill your needs.
However if you have to have Excel, then you need a roundtrip solution: load the Excel from an URL (probably generated by an XAgent (?) and save it back. The saving back part is the tricky one. Normal HTTP doesn't allow that. What you need there is a webDAV capable server. Watch out for a project on OpenNTF soon (just clearing IBM legal) that provides webDAV.
However the ZK Spreadsheet looks much better for your needs.
I have a sample database at the following URL --> http://www.nnsu.com/nnsusite.nsf/%24%24OpenDominoDocument.xsp?documentId=B65507CB2DE15B3286257986005F061D&action=openDocument
Download the APCC.nsf. This will allow you to create/read a new EXCEL spreadsheet and then stream the resulting file to the requesting browser. There is not need to have EXCEL or office installed on the Server.
THe examples create a new workbook, but you can also store a "template" on the server or in a notes document and use it as a starting point and then save it to a document or stream it to the requesting browser.
With Apache POI you can read/write to a spreadsheet using data from the notes document the process is initiated from.
I am new to VBA and this area. I would like to capture the document proporties like (document title, subject, author, team, manager,company etc...) while create or saving the document. This properties capture is must and i would like to implement to all the Word, Excel, Powerpoint users in my company.
How this can be possible. If I wrote a macro, is it possible to deploy all the MS-Office users. or a VB program will do?.
All i need is to make mandatory to input document properties for all the documents. these properties can also be fetched from a template file from the user machine.
Is this possible in VBA or any other easy ways to do it.
To force users to fill in all the properties before saving the document, you can create add-ins (one for each of Excel, Word and PowerPoint) that intercept the "before save" event and check the document properties. If the add-in detects some properties that have not been filled in, it can prompt the user and cancel the save.
The means by which you can create an add-in is similar (but not identical) across the 3 applications. You would of course also have to ensure that the add-ins were installed on all your users machines.
If you just want to be able to read (or modify) the properties, you can use the Office Document Property Reader to read and write properties of Office documents, without even needing Office installed. That works across all Office applications.
I made a discovery some time back. Just follow these steps:
Create a .doc/.xls/.ppt file in office 2003. Keep some test data in there and close the file. Now rename the file to change it's file extension to a random string, taking care that it is unassociated, like test.asdfghjkl etc.
Double click the file and it opens seamlessly in the parent application.
Now AFAIK, windows checks the file extension of the file and uses it to do an action, viz open an application and pass the file to it to open. Then how does the office suite manage to do this?
EDIT: How about the case when the extension is changed to one that is associated with another application. Is there a priority algorithm in place for handling that ?
Do you have the "View extensions for known types" option on?
EDIT: #Comments....
Yes, its a stupid/insulting question, but when troubleshooting a problem I have learned to assume nothing, and trust the users 0%.
BUT, I tried it, and you're right. Its stupid that MS has this kind of behavior, and it can only lead to security vulnerabilities, which led me on a search for your answer.
From the posts at http://seclists.org/fulldisclosure/2007/Jan/0444.html
"You have stumbled on an age-old
quirky behavior of Windows. Office
document formats are based on a
standard Windows container format, OLE
structured storage files, also known
as "docfiles". A docfile's name and
extension are irrelevant - the file
is, conceptually, a serialization of
an OLE object, and like all
serialization formats it contains the
identifier of the application that
produced it, in the form of an OLE
class id (in GUID format) in this
case. You can easily verify that it
doesn't work with the newer Office XML
formats"
Indeed it doesnt work for the 2007 *X file types, but 2K3 is still a problem. To solve this problem... Upgrade! =)
And here at security focus under TOC point 2.
So, there you go.
I can't seem to make this happen now, but I know I saw Windows reading XML processing instructions a few years back. Maybe that is what's going on?