Marking an excel file with a key from system

[dee-u]

I would like to be be able to mark an excel file with a key which will come from the system so that when an excel file is imported it would try to find that key to determine if the file came from the system or not. I am currently doing it by specifying the key in the file name but that is very easy to fail. My google-fu is not working, my search results are returning links to adding keys/identification to the cells.

In the VB.Net section it was recommended that I use a custom property of the excel file. I am still looking for other more foolproof ways if possible. Would it be possible to binary edit the file and include a secret data?

TIA

[Schmidt]

Excel files these days are Zip-Archives - they just have a different file-suffix than *.zip.

So, use your Zip-lib of choice, open the Archive, place your "marker-key-file" somewhere - and the problem is solved.

Olaf

[dee-u]

Wow, that is very interesting, indeed I was able to add a file to the xlsx file using winrar and able to see it after opening it again. Will look further on how I can integrate this, thanks for the tip!

[Zvoni]

Why not use the Keyword-Property of the Workbook?
Go to File-Explorer, choose a xlsx-file, right-click on it, go to Properties, go to Details
There you'll find different Properties (Author, Title, Subject etc.)
Choose the appropriate one (German Windows for me, third from above should be "Keywords"

You can read those from vb-code (tested in Office-VBA --> Debug.Print ThisWorkbook.Keywords)
Or in your vb6-code oben the Object-Explorer and look for the Workbook-Object.
You'll find all those Properties there

if your Excel-Files come from the system (is system = your code?), set the keyword when creating the file, and you're all set

[Dan_W]

The suggestions above are likely the most straight-forward (and to easy to implement) solutions, but I thought I'd just throw into the mix the method detailed in Chip Peason's blog about writing and reading built-in and custom properties to closed files (). Of course, it requires the use of an additional DLL from Microsoft - DSO OLE Document Properties Reader 2.1 - so is not always appropriate in all scenarios, but I hoped it might be of value to someone.

[dilettante]

This scenario seems totally bizarre.

But assuming it makes any sense at all... why not just write some crap of your choice into an alternate data stream of the file?

[Schmidt]

This scenario seems totally bizarre.

It's not that bizarre IMO.

Sometimes you want to have such documents passed through some (semi-)automated workflow-stages
(partly system, partly human - and for the "system-parts" you need something that "keeps track").

But assuming it makes any sense at all... why not just write some crap of your choice into an alternate data stream of the file?

AFAIK, these are "NTFS-bound" - and won't survive:
- storing them on USB-sticks (which are still often enough FAT- or FAT32-formatted)
- or (more likely) - transferring them via Sockets (upload/downloads - or EMail)
- even the simple act of placing them in a Zip, would strip these DataStreams

Olaf

[dilettante]

So "detect if from this computer" except when not from this computer???

Wouldn't you want your "this computer" marker scrubbed whenever the file travels?

[dee-u]

So "detect if from this computer" except when not from this computer???

Wouldn't you want your "this computer" marker scrubbed whenever the file travels?

No one said about "detect if from this computer", I said I wanted to know if the excel file was generated from the system and it should be identifiable if it is imported to the system. System = software/program.