How to batch "Add a tag" to Windows 7 and Windows 10 MS files

[sov]

Is there a way in WinBatch to "Add a tag" to Microsoft Office files?  In Microsoft Office files, we can manually go to Properties > Details and put in a tag for fast searching later (see attached screenshoot).  Is there a way to script it, in either W7 or W10?

This is also a way to trigger a "file change" which will allows the files I need to keep to escape the automatic old file purge system.  I tried file date and attribute changes, and they are not recognized as a "file change" by the purge system.  If there are other ways to trigger file change without changing the file content, it will be great to know.

Thanks.

Venus

[td]

Is there a way in WinBatch to "Add a tag" to Microsoft Office files?  In Microsoft Office files, we can manually go to Properties > Details and put in a tag for fast searching later (see attached screenshoot).  Is there a way to script it, in either W7 or W10?

Give this third-party Property Store Extender a try:
http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WIL~Extenders/_Third~Party~Extenders/Property~Store~Utility+Property~Store~Extender.txt


It is written by a knowledgeable developer and longtime contributor, Chuck Chopp.

This is also a way to trigger a "file change" which will allows the files I need to keep to escape the automatic old file purge system.  I tried file date and attribute changes, and they are not recognized as a "file change" by the purge system.  If there are other ways to trigger file change without changing the file content, it will be great to know.

The FileTimeSetEx function can be used to change the create, last modified, and last accessed dates of a file. Check out the function's topic in the Consolidated WIL Help file for details.

[sov]

Thanks!  Love to try it out, but looks like I need to either upgrade or buy a new version.  I have a 2011a version and looks like that I need 2011b version for 64bit.  My installation zip file seems to have corrupted as well.  Anyway, will figure the version/purchase out and try it out.

Thanks again.

[td]

Unless you are creating a compiled script for a Windows server core version without WOW64 or are using a 64-bit COM Automation object, you generally don't need 64-bit WinBatch.  32-bit WinBatch works just fine on 64-bit Windows.

[ChuckC]

I do still check in here periodically to read posts even if I don't post all that often.  If there are any questions about the Property Store extender and how it works, I'd be happy to answer them.

[sov]

Thanks all.  It's very helpful and looks like it should work.  I'm struggling with installing the 2011a version I have. I wonder if you can give me some hint. With the old computer gone, all I have left is the wb44i11a.zip file.  Somehow I cannot uncompress it using the Windows Explorer's Extract All.  I tried to look at the file in UNIX system.  Using the "less wb44i11a.zip" command, I get this information:

Archive:  wb44i11a.zip
[wb44i11a.zip]
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
note:  wb44i11a.zip may be a plain executable, not an archive
zipinfo:  cannot find zipfile directory in one of wb44i11a.zip or
          wb44i11a.zip.zip, and cannot find wb44i11a.zip.ZIP, period.


I then change the filename to wb44i11a.gz to see if gzip can unzip it. It cannot and returned this message: wb44i11a.gz has more than one entry

I then do the "less wb44i11a.gz" command, and see the content of a WinBatch script.  I copied the initial part of the script below and attach the entire script:

Code: Winbatch

;***************************************************************************
;**   Window Analysis Script
;**
;** This script creates a report on the windows visible at the time
;** the report is run.  Run the script.  Choose a top-level
;** window of interest, and it will show pertinent information
;** that may be necessary to use the Control Manager extender.
;**
;** Note that Tabbed dialogs sometimes must be displayed before
;** their controls are brought into existence.  So when using
;** tabbed dialogs, tab to the correct dialog first.  The
;** cWndInfo example shows how to move through a tabbed dialog.
;**
;** Revisions:
;**  5.0 Jan 7th 2010
;**      FIX: Handle titles with embedded doublequotes. Fixes issue with
;**      ItemExtractCSV returning error 1707.
;**
;**  4.0 Sept 4th 2009
;**      FIX: Handle strings with embedded linefeeds. Fixes issue with
;**      ArrayFileGetCSv returning error 1808.
;**
;**  3.0 Sept 29th 2008
;**      FIX: Handle Windows Names that contain a comma.
;**
;**  2.0
; **     Initial Release
;**
;***************************************************************************
thisver = '5.0'
thistitle = 'Window Analysis'
csvfile ='Analysis.csv'
htmfile ='Analysis.htm'
; Application Data directory to store CSV file output
appdatadir = ShortCutDir( 'AppData', 0 , @true ) : 'WinBatch\Temp\'
;Check if dir exists. it not create it
if !DirExist( appdatadir ) then DirMake( appdatadir )
;if this is already running then exit
if WinExist( thistitle )
   WinActivate( thistitle )
   exit
endif

Any idea how I can uncompress and get it installed?

[td]

Obviously, your zip file is corrupt.  You need to download a new copy at

http://files.winbatch.com/downloads/wb/wb44i11a.zip

[sov]

Great!  I installed and did a quick test.  I ran the setup.wbt in the downloaded WWPSU45001.zip folder.  Added "AddExtender('WWPSU45Ix86.DLL')" line to my test script and get an error message (Illegal delimiter found for the line prop=psuOpenPS(MyFile).  I tried adding "IntControl(29, @TAB, 0, 0, 0)" but doesn't help.  Likely the syntax is wrong (I copy the script below).  The Property_Store_Utility.chm help file only has list of function by no example of usage/syntax.  Or maybe the Property Store Extender installation is not right?  I copied the WWPSU45001 folder within C:\apps\WinBatch\System\ folder, and I do see WWPSU45Ix86.dll and WWPSU45Ix86.ext copied to the WinBatch\System folder. Any idea how to get it work?

Code: Winbatch

AddExtender('WWPSU45Ix86.DLL')
;default file delimiter is set to TAB
;IntControl(29, @TAB, 0, 0, 0)

types="All Files|*.*"
MyFile=AskFileName("select file","C:\Users\sov\Downloads",types,"",1)

prop=psuOpenPS(MyFile)
Message("Properties of file are: ", prop)

[ChuckC]

Take a look at the PSExplorer.wbt script that is included with the extender.  It is a fully functional sample script that exercises most of the extender's functionality.

[sov]

Ah, got it.  Just took a quick look at the PSExplorer.wbt.  It has a nice interface to look at various properties related to the file.  A few quick questions for now:

1) I don't see a "Add a tag" related property.  Is it something that depends on how Microsoft designs to put what things where, or something that is adjustable in the script?
2) the newer XML-based Microsoft office files (like .docx) are not recognized.  Is it something that can be adjusted in the script?

Thanks!

[td]

Ah, got it.  Just took a quick look at the PSExplorer.wbt.  It has a nice interface to look at various properties related to the file.  A few quick questions for now:

1) I don't see a "Add a tag" related property.  Is it something that depends on how Microsoft designs to put what things where, or something that is adjustable in the script?

It's the system.Keywords property for Word documents.  Likely the same for other Office documents.  Just manually type something in the tag property and then check the file with Chuck's property explorer script.  Find the value you added and you have found the property.

2) the newer XML-based Microsoft office files (like .docx) are not recognized.  Is it something that can be adjusted in the script?

Not sure that XML-based Office files are worthy of the term 'new' as they have been around for more than 10 years and that is ancient in computer years.   Anyway, the property functionality for a given document type is provided by a "property provider" and that needs to be installed on the system before any properties can be gleaned from a file.    Generally, this happens when the application that creates and or supports the file type is installed.  For instance, for docx file properties to be available, a version of Word that supports that format would likely need to be installed on the system.  That said, I don't know of any reason why some entity (like Microsoft) couldn't just write and install a provided without the supporting applications if they had some burning reason to do so.    I do know that the property store extender has no problems accessing docx file properties on my workstation that also has a Microsoft Office suite installed.

[ChuckC]

Regarding the "tags" that can be applied to a file with any given extension:

The technical term is "property", rather than "tag", and that's not to pick a nit, so to speak, but if you go searching Microsoft's MSDN site or performing more general Google searches, referring to file "properties" and the "property store" will net you much more useful results w/respect to the search terms that are used.  With that said about the semantics, what is important to know is that the Windows Property Store functionality is, for the most part, implemented almost entirely by Microsoft, although it can be extended with 3rd Party Property Store Providers that can be registered to manage the properties that can be applied to files with certain file types.  With the functionality present in the default property store provider, Microsoft provides for a finite set of properties for each file type/extension that is supported.  You can't add arbitrary properties/tags to just any old file type.

PSExplorer.wbt is written to present you with the possible set of property names that are supported for a file of any given type/extension.  If a specific property is absent, then the text box for the property value is disabled.  If the property is present, then the text box is enabled and the value is present, including a value that is an empty string of zero length, which is different from a value being absent entirely.  Depending on what types of applications have been installed on the system, there may be additional properties available for additional file types/extensions.

The Golden Rule of the Windows Property Store is that if you can view/edit the value on the "Details" page of the file/folder Properties Panel in the Windows Explorer, then the Property Store Extender can access it as both are using the same underlying Windows-provided facility to access the properties.

Note... simply renaming a file to have a particular file type/extension doesn't imply that you can hack your way into adding properties that are otherwise inappropriate for the file's original type/extension.  The Property Store Providers are implemented as DLLs that contain code that can parse the binary format of various file types and properly manipulate their supported properties.  If you were to rename a file from ".doc" to ".mp3", it wouldn't allow you to add MP3 IDv3 tags to a Word document.  Instead, what you'd get is some kind of error, with the Windows Explorer not showing any defined properties beyond the basic file system attributes, time stamps, size, etc..., and with the PS Extender most likely returning some kind of error when attempting to load the properties for the file that's masquerading as a MP3 file.

[sov]

Thanks td. Yes, it's the System.Keywords property.

Thanks Chuck.  Good to know that tags can b eapplied to a file with any given extension (well, provided that they are valid).

From the PSExplorer.wbt, I see a line " bResult = psuSetPropertyValue(nPSIndex, sSelectedPropertyName, sSelectedPropertyValueNew)".  Sounds like this is the one for changing property values.  Is it that:

• sSelectedPropertyName: "System.Keywords"
• sSelectedPropertyValueNew: "whatever"
• nPSIndex: file index? like if there are 100 files, I can do a for loop and this is the file index?
• bResult: which does this capture?

Thanks!

[td]

Regarding the "tags" that can be applied to a file with any given extension:

The technical term is "property", rather than "tag", and that's not to pick a nit, so to speak, but if you go searching Microsoft's MSDN site or performing more general Google searches, referring to file "properties" and the "property store" will net you much more useful results w/respect to the search terms that are used.  With that said about the semantics, what is important to know is that the Windows Property Store functionality is, for the most part, implemented almost entirely by Microsoft, although it can be extended with 3rd Party Property Store Providers that can be registered to manage the properties that can be applied to files with certain file types.  With the functionality present in the default property store provider, Microsoft provides for a finite set of properties for each file type/extension that is supported.  You can't add arbitrary properties/tags to just any old file type.

PSExplorer.wbt is written to present you with the possible set of property names that are supported for a file of any given type/extension.  If a specific property is absent, then the text box for the property value is disabled.  If the property is present, then the text box is enabled and the value is present, including a value that is an empty string of zero length, which is different from a value being absent entirely.  Depending on what types of applications have been installed on the system, there may be additional properties available for additional file types/extensions.

The Golden Rule of the Windows Property Store is that if you can view/edit the value on the "Details" page of the file/folder Properties Panel in the Windows Explorer, then the Property Store Extender can access it as both are using the same underlying Windows-provided facility to access the properties.

Note... simply renaming a file to have a particular file type/extension doesn't imply that you can hack your way into adding properties that are otherwise inappropriate for the file's original type/extension.  The Property Store Providers are implemented as DLLs that contain code that can parse the binary format of various file types and properly manipulate their supported properties.  If you were to rename a file from ".doc" to ".mp3", it wouldn't allow you to add MP3 IDv3 tags to a Word document.  Instead, what you'd get is some kind of error, with the Windows Explorer not showing any defined properties beyond the basic file system attributes, time stamps, size, etc..., and with the PS Extender most likely returning some kind of error when attempting to load the properties for the file that's masquerading as a MP3 file.

With regard the term 'tag', I believe the OP was referring to a property called 'tag' in the UI that appears to be part of the schema for all Office documents.   The shell displays the text 'Add tags' using a low contrast font in the edit box for the property's value.  The property associated with the UI property name 'tag' is  'System.Keywords' as previously mentioned.

[ChuckC]

Ah, OK, I wasn't aware that the property name itself was "tags"... when I first started reading this thread, I somehow missed the little screenshot graphic with that in it.  My bad!

nPSIndex, per the help topic for psuSetPropertyValue(), is a property store index value that was previously obtained by a call to psuOpenPS().  For all intents and purposes, it is analogous to a "file handle", except that it's something that's used exclusively with the Property Store API functions in Windows.  You pass a file specification to psuOpenPS() and get back the index value that is then passed in as a parameter to other functions that manage the properties associated with that index [file].

bResult is simply receiving the return value of psuSetPropertyValue(), which, again, in the help topic for psuSetPropertyValue(), is documented as being a binary value of either @TRUE (1) or @FALSE (0).

WinBatch/WIL may be a "negatively" or "weakly" typed language w/respect to the data types associated with variables, but my background is in C and C++, which shows itself in the use of Hungarian notation in the names that I use for variables where the lowercase leading characters in the variable name serve to identify the data type that the variable should contain.  For WinBatch/WIL, you'll see in my scripts that variables will have "b" for binary, "n" for numeric [integer], "f" numeric [floating point] and "s" for string.  Any WIL variables that are of a pointer type that refers to a variable will have a "p" for pointer prefixed in front of the data type [e.g. "pnPointerToIntNumber", "psPointerToString"].

[sov]

Thanks!  I've guessed some of the data type prefixes, but not the ones like ps.  How about functions.  Your functions all starts with "psu". What does that stand for? 

You mentioned "per the help topic".  I just want to make sure that I'm not missing something. The Property_Store_Utility.chm file I opened, only has a list of help topic, but no content (see screenshot)?

[td]

The help file is blocked.  This was an issue with Internet Explorer but I am not sure if Microsoft Edge browser still blocks downloaded files the same way. 

At any rate, the following Tech Database article explains how to remove a bock added by EI:

http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch+Help~File~Issues.txt#STORY2

If the above solution does not apply, give the following script a try:

http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/UDF~-~UDS~Library/Files~and~Directories+Alternate~Data~Stream~UDFs.txt

[ChuckC]

Ah, yes, I encountered the same blocked access for the extender's help file when I tried to double-click on it in the Windows Explorer and the folder that it was located in was under a scratch pad area where I had unzipped the extender's content.  However, when I double-click on the help file out under "C:\Program Files (x86)\WinBatch", there doesn't seem to be any restriction/block applied to accessing the full content of the help file as it's located under a "secure" location in the file system that Windows trusts.

As for the extender function naming and that "psu" prefix... the extender's full name is the Property Store Utility extender, and thus all functions within have a "psu" prefix so that their names all relate them back to the extender that makes them available.  Most WIL extenders do the same thing with their functions, as you can see with the various "wnt", "nw", "wts", etc... prefixes for the different "families" of functions associated with each extender.