I think there is a way to extend the Windows Shell to make (for example) other types of archives in the same vein of the support for ZIP-files "compressed folders".
I admit that the Shell Interface is pretty clear when you're familiar with the shell terminology, but really obtuse otherwise. My current guess would be IShellFolder, but I think this would be creating an extra folder at the same place as andin addition to the file, instead of providing special support for the file itself.
Therefore, what to implement?
There is no shell interface specifically intended for implementing compressed folders. It is implemented as an ordinary Shell Namespace Extension that just happens to create/open a normal .zip file and represent its content to the Shell using PIDLs and standard shell interfaces like IShellFolder, IShellItem, IDataObject, IEnumIDList, etc. The SNE even represents a .zip file itself as a subfolder within its parent folder, instead of as a file, so the Shell can traverse into the .zip file using the SNE's IShellFolder implementation like any other folder. The Shell has no concept that it is accessing a .zip file, it is just another Shell item whose characteristics tell the Shell how to work with it. The SNE's implementation handles the details of accessing/updating the .zip file instead of the file system.
There is a whole section of MSDN that describes has to create Shell Namespace Extensions, including:
Windows Shell
Creating Shell Data Source Objects and Extending the Shell Namespace
Creating Shell Extension Handlers
Implementing the Basic Folder Object Interfaces
Related
I've been finding all kinds of Shell Interfaces via COM that help prevent reinventing the wheel when you have a Windows only application. One thing I haven't found is something that will put up standard messages like the question to overwrite an existing file (where it also shows the source and target file with icons, dates and such). Does something exists for that (outside of MFC/.NET)?
TIA!!
My application is to be written using wxWidgets, but the question may be related to using gettext in general.
For the application named app, some sources suggest I sould create <lang>/ subdirectory, create the app.po file inside with the translation, and convert it to the distributed app.mo file in the subdir.
Another approach is to create app.pot (i.e. the template from the sources via xgettext), and to msginit and msgmerge it to the <lang>.po for the language.
For the first approach, more .mo files can be put inside the <lang>/ subdirectory. Also the wxLocale::AddCatalog() gets the domain name (where the domain can naturally be app, wxstd, etc.). On the other hand, the <lang>.po file name is descriptive on itself -- wherever it is located.
What are the pros and cons of the two approaches? Is there any text that explains the path to be chosen?
Thanks for your time and experience,
Petr
The Unix convention is to use app.mo for binary catalogs, see the contents of /usr/share/locale directory. Sometimes lang.po is however used for the source ones, as done in wxWidgets itself (see its locale subdirectory), but they're still installed into language-specific subdirectory using the app-dependent name.
For an application I would like to store a collection of files together, and have them appear in the filesystem as a single file so its easy to manage. I am currently storing everything in a folder.
I would like to keep things accessible so you can manually edit the inside contents if neccesary.
One way to do this would be to create a zip archive and give it a custom extension other then .zip. Then it appears as a filetype and if needed you can unpack and access the content, but for normal use keep it hidden.
I can't seem to find a convenient way to do this. Boost and zlib can do the compression but don't work with archives. I found libzip but I have a hard time understanding how to use it and to me it seems that it only reads/writes zip archives without doing the actual compression.
Is there a more convenient way to tackle this?
Can you call system functions for creating an archive on OSX from c++ / Carbon?
Is there another way to make a folder appear as a single file?
In OSX, you can create Document Packages (similar to application bundles) which are treated as a single file in the Finder, but are really just directories with some internal structure.
Apple does not zip these packages, but they do provide the functionality you describe and they can be created and accessed through CoreFoundation by using CFBundleRef .
From the documentation:
... The important thing to remember about creating a document package is that it is just a directory. As long as the type of the document package is registered (as described in “Registering Your Document Type”), all you have to do is create a directory with the appropriate filename extension. (The Finder uses the filename extension as its cue to treat the directory as a package.) You can create the directory (and create any files you want to put inside that directory) using the standard BSD file system routines ...
As 1st step, simple rename the folder and add the extension .bundle, e.g. Myappdir.bundle
That's will show the whole folder as one file with a lego-like bundle icon.
The next step is you must create one Info.plist file inside.
I've developed a GUI for some build scripts, and am now in the process of deploying it. As the script will be deployed to a number of different machines at various points, I need to use the standard format of directories that the team use.
The GUI consists of a ".fig" file that contains the visual definition of the UI, and a m-script that defines the functionality. I need to locate these two in "fig/" and "m/" folders respectively, but I can't figure out how to. I first searched for an include statement of some kind in the m-script, as when I Run it on its own, the error message in the command window states that the ".fig" file can't be found, but there doesn't seem to be a reference to the ".fig" file anywhere, I assume that it's inferred as both files have the same name but a different extension.
I fear that Matlab's GUI system requires that both ".m" and ".fig" files are in the same location, but this will be an inelegant solution that I'd rather not go for if I can avoid it.
The next thing I'm going to try is to call a script that copies the fig file from the other directory to the same location as the m-script, when it is executed, then deletes that copy once the script exits, which again seems a clunky solution, but will allow me to adhere to the team's organisation conventions.
Does anyone else know of an undocumented means of specifying the relative location of a GUI ".fig" file?
You can export the GUIDE-generated GUI as a single .m file. Check out this blog post: GUIDE GUIs in All One File.
I'm not sure if this is a new feature, or one of those things that has always been there...
I'm working on a shell extension that is supposed to display extended properties of files (mostly .jpgs) stored on a virtual drive (think of it as an external harddrive).
Is it possible to register the shell extension in a way that it only kicks in for files of a specific folder/drive (in my case the external harddrive) and leaves the handling of jpgs in other folder to the Windows default shell extension?
Regards,
Sebastian
This article lists ways that you can register your shell extension: http://msdn.microsoft.com/en-us/library/cc144096(VS.85).aspx.
You should be able to create a system folder on your external harddrive that contains a desktop.ini file that points to your extension.
Alternately, within the extension itself you could check the path and not do the extra logic if it's not located in your designated spot.
Place Your app infos in:
HKEY_CLASSES_ROOT\Directory\shell\