We have a proprietary file format which has embedded in it a product-code.
I am just starting down the path of "enabling the end-user to sort / filter by product-code when opening a file".
The simplest approach for us might be to simply have another drop-down in our customized Open File Dialog in which to choose a product-code to filter by.
However, I think it might be more useful to the end-user if we could present this information as a column in the details view for this file type - just as name, date-modified, type, size, etc., are also detail properties of a file-type (or perhaps generic to all files).
My vague understanding is that XP and prior Windows OSes embedded some sort of meta data like this in an alternate data stream in NTFS. However, Starting in Vista Microsoft stopped using alternate data streams due to their dependence upon NTFS, and hence fragility (i.e. can't send via file attachment, can't move to a FAT formatted thumb drive, etc.)
Things I need to know but haven't figured out yet:
Is it possible / Is it practicable / how to create a custom extended file property for our file type that expresses the product-code to the Windows shell so that it can be seen in Windows Explorer (and hence File dialogs)?
If that is doable, then how to configure things so that the product-code column is displayed by default for folders containing our file type.
Can anyone point me to a good starting point on the above? We certainly don't have to accomplish this by publishing a custom extended file property - but that seems like a sensible approach, in absence of any way to measure the costs of going this route.
If you have sensible alternative approaches to the problem, I'd be interested in those as well!
Just found: http://www.codeproject.com/Articles/830/The-Complete-Idiot-s-Guide-to-Writing-Shell-Extens
CRAP! It seems I'm very late to the banquet, and MS has already removed this functionality from their shell: http://xpwasmyidea.blogspot.com/2009/10/evil-conspiracy-behind-customizable.html
By far the easiest approach to developing a shell extension is to use a library made for the purpose.
I can recommend EZShellExtension because I have used it in the past to add columns and thumbnails/preview for a custom file format for our company.
Related
I'm currently working on a cross platform application that uses extended file attributes for storing it's own file ownership information (uid, gid) outside of the normal filesystem ownership. This information is application specific and has nothing to do with the normal filesystem ownership.
I just changed from using a small database stored in each folder for storing this information for performance reasons, but this leaves my solution lacking on the Windows platform.
According to wikipedia, NTFS may have some limited functionality as far as being able to store extended file attributes, but I certainly can't find any further information on how to get and set these attributes.
Has anyone done this before and can tell me how to do it? Or is it just plain not possible?
I'd ideally like to not have to revert to the database solution on Windows.
Maybe NTFS streams are what you are searching for?
Read more here: http://support.microsoft.com/kb/105763 , http://msdn.microsoft.com/en-us/library/ff469210.aspx
Vista introduced an interface: IFileDialog::SetFilter, which allows me to setup a filter that will be called for every potential filename to see if it should be shown to the user.
Microsoft removed that in Windows 7, and didn't support it in XP.
I am trying to customize the our Open file dialog so that I can control which files are displayed to the end user. These files are marked internally with a product-code - there isn't anything in the filename itself to filter on (hence file extension filters are not useful here -= I need to actually interrogate each one to see if it is within the extra filter parameters that our users specified).
I would guess that Microsoft removed the SetFilter interface because too often it was too slow. I can imagine all sorts of similar ideas to this one which don't scale well for networks and cloud storage and what have you.
However, I need to know if there is an alternative interface that accomplishes the same goal, or if I really am restricted to only looking at the file extension for filtering purposes in my File dialogs?
Follow-up:
After looking further into CDN_INCLUDEITEM, which requires the pre-vista version of OPENFILENAME, I have found that this is the most useless API imaginable. It only filters NON-filesystem objects. In other words, you can't use it to filter files. Or folders. The very things one would filter 99.99% of the time for a file open or save dialog. Unbelievable!
There is a very old article by Paul DiLascia which offers the technique of removing each offending filename from the list view control each time the list view is updated.
However, I know from bitter experience that the list view can update over time. If you're looking at a large folder (many items) or the connection is a bit slow (heavily loaded server and/or large number of files), then the files are added to the dialog piecemeal. So one would have to filter out offending filenames repeatedly.
In fact, our current customized file open dialog uses a timer to look at the view's list of filenames periodically to see if any files of a given pattern exist, in order to enable another control. Otherwise it's possible to check for the existence of these files, find none, but a moment later the view updates to have more filenames, and no events are sent to your dialog to indicate that the view has been changed. In fact, my experience with having to write and maintain code for the common controls file dialogs over the years has been that Microsoft is not very cluefull when it comes to how to write such a thing. Events are incomplete, sent at not-useful times, repeated when not necessary, and whole classes of useful notifications don't exist.
Sadly, I think I might have to give up oh this idea. Unless someone has a thought as to how I might be able to keep up with the view spontaneously changing while the user is trying to interact with it (i.e. it would be awkward to go deleting out entries from the list view and changing the user's visual position, or highlighted files, or scroll position, etc.)
You need to initialise the callbacks for your CFileDialog. Then you need to process CDN_INCLUDEITEM notification code to include or exclude items.
You can also check this great article. The author uses some other approaches in addition to callbacks
As you have already discovered, starting in Windows 7 it is no longer possible to filter out files from being displayed based on content, only file extension. You can, however, validate that the user's selected file(s) are acceptable to you before allowing the dialog to close, and if they are not then display a message box to the user and keep the dialog open. That is the best you will be able to do unless you create your own custom dialog.
Apparently this supposed to be possible. For example opening and operating on a file with NOTEPAD, or HxD. But aren't they all text files...how would one specify which text editor to open the file and operate on the file with using the WINDOWS API. It is certainly not in "CreateFile".
Hopefully I'm understanding your question... The easiest way to do this is to launch the desired editor and pass the filename as an argument, rather than "invoking" the file (which will launch the default program associated with the file type).
For example, notepad.exe mytextfile.txt or gvim.exe mytextfile.txt.
If the editor is not on your %PATH%, you'll need to use a full path file name.
What are you trying to do, exactly? You could:
Maintain a list of editors that you expect to be installed and have entries for in the system's PATH (bad idea)
Have an editor/editors that you want to use, query the Windows registry to find the installation path of the editors (using RegGetValue), and launch the editor with CreateProcess) (a little better idea)
Query the registry to get the default editor for a given file type and then launch that editor using CreateProcess. (best idea)
But it all depends on what your goal is really.
Edit based on requirements
So, just so we're on the same page, from C++, you want to:
Take a command line parameter to your C++ application (filename)
Open that file in an arbitrary editor
Detect when the user has made changes to that file
Operate on the file contents
Is that correct?
If so, you could:
Use Boost libs to compute a CRC for the current data in the file
Launch an editor using one of the methods I initially described
Stick in a tight loop and sleep so you don't chew up resources while the initially computed CRC matches one calculated every iteration of the loop
Of course, there are all kinds of issues that you'd have to deal with (that's just a super simple way of describing the algorithm I might use), such as:
What happens if the user doesn't change the file?
What happens if the file isn't found?
I'm sure that there are a number of different methods of doing this, but this is the easiest method that I can think of at the moment (while still being able to be fairly certain of the changes).
Disclaimer: I haven't implemented something like this, so I might be completely off base ;)
Are you looking for the ShellExecute() or ShellExecuteEx() APIs on Windows? They'll launch whatever program is registered for a file (generally based on the filename extention).
I've not done much coding for Windows lately, and I find myself sitting at Visual Studio right now, making a small program for Windows 7 in C++. I need some configuration data to be read/written.
In the old days, (being a Borland kind of guy) I'd just use a TIniFile and keep the .ini beside my exe Obviously this is just not the done thing any more. The MS docs tell me that Get/WritePrivateProfileString are for compatibility only, and I doubt that I'd get away with writing to Program Files these days. Gosh I feel old.
I'd like the resulting file to be easily editable - open in notepad sort of thing, and easily findable. This is a small app, I don't want to have to write a setup screen when I can just edit the config file.
So, what is the modern way of doing this?
Often people use XML files for storing preferences, but they are often overkill (and they aren't actually all that readable for humans).
If your needs would be easily satisfied with an INI file, you may want to use Boost.Program_options using the configuration file parser backend, which actually writes INI-like files without going through deprecated (and slow!) APIs, while exposing a nice C++ interface.
The key thing to get right is where to write such configuration file. The right place is usually a subdirectory (named e.g. as your application) of the user's application data directory; please, please, please, don't harcode its path in your executable, I've seen enough broken apps failing to understand that the user profile may not be in c:\Documents and settings\Username.
Instead, you can retrieve the application data path using the SHGetFolderPath function with CSIDL_APPDATA (or SHGetKnownFolderPath with FOLDERID_RoamingAppData if you don't mind to lose the compatibility with pre-Vista Windows versions, or even just expanding the %APPDATA% environment variable).
In this way, each user will be able to store its preferences and you won't get any security-related errors when writing your preferences.
This is my opinion (which I think most of the answers you get will be opinion), but it seems that the standard way of doing things these days is to store config files like these in C:\Users\<Username>. Moreover, it is generally good to not clutter this directory itself, but to use a subdirectory for the purpose of storing your application's data, such as C:\Users\<Username>\AppData\Roaming\<YourApplicationName>. It might be overkill for a single config file, but that will give you the opportunity to have all of your application data in one place, should you add even more.
How to add properties to a file like the Windows Office?
In Windows, is possible to edit fields from a file like Title, Subject, Keywords etc. How to do the same with an arbitrary file from C/C++ without using Office?
Do you have any hint about API, DLLs or general tricks?
This data can be stored in alternate data streams. Here are some examples of the APIs to access ADSs in NTFS.
There are two kinds of metadata that might be displayed. One is file based metadata, which is going to specific to NTFS, in which case you should research NTFS metadata API's. The other kind of metadata is going to be file format specific, like JPEG exif blocks, or MS Office Summary. This kind of metadata is going to require specific knowledge of every kind of file format you want to edit data for, and in the case of Microsoft Office documents, is liable to change between office versions. You're best bet for office documents would probably be to start with OOXML summary field editing and seeing if you want to continue with other formats from there.