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!!
Related
This is likely not a simple topic - I have researched this to the best of my abilities and realize that it is not supported in any typical fashion.
My goal is to enable something similar to .app files from OSX, where the application, as well as its user data, can exist in the same file. I imagine it would require writing a tool to manage this behaviour, but this question is more about how to achieve this in the Windows OS. I am quite flexible regarding the implementation details, but the more straightforward the behaviour, the better (i.e. avoiding copying or compressing/decompressing entire directories/archives at runtime would be ideal).
Approaches I have considered:
Find a way to get explorer to treat a directory as a file, so that it can be associated. I have found a way to get explorer to treat a directory as a control panel item, I have thus far been unable to find a way to use this to associate a custom program. See the infamous "godmode hack" for Windows (name a directory something to the effect of "GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}"). This one seems the most hopeful, but I'm at wits end trying to find information about creating a new association of this type.
Come up with some kind of archive format which can extract executable information to a temporary directory, launch this executable passing the archive as a commandline parameter. This seems like the ugliest solution, from a performance perspective. I would prefer a different solution if at all possible, one which doesn't involve making duplicates of the program or its data to run.
Find a way to associate a directory directly, though I have found no trace of this being supported in Windows, and I assume this is a dead-end.
Find a way to get an executable to include writeable embedded files. I have been unable to make any headway with this- I even tried a resource hacker approach, but obviously you cannot modify the assembly while its in use.
Tried to make a self-modifying JAR file with Java, but the route I took would add the JDK as a runtime requirement, which seems a bit overkill. Even then, it would be limited to Java, and I'm pretty sure it's not actually supposed to allow that in the first place.
Modify Windows Explorer. I shudder at the amount of work this would take, not to mention the at-best gray area it falls under legally. Perhaps there's a way to extend explorer to achieve this, I'm not sure.
A custom archive file. This seems like the most straightforward way to do it. But it would ideally need to be an archive format that has very little overhead for file I/O. Could even be some kind of virtual disk that gets mounted, but I am imagining that would be pretty heavy.
I would appreciate any insight that anyone has on this topic. I won't go into reasons as they are irrelevant to the question itself- I'm aware it is likely not the most practical solution to anything in particular. Consider it a novel pursuit.
It can be done by application virtualization,
Read this wikipedia page theory:
https://en.wikipedia.org/wiki/Portable_application
https://en.wikipedia.org/wiki/Application_virtualization
And two pages about software:
https://en.wikipedia.org/wiki/VMware_ThinApp
https://en.wikipedia.org/wiki/Turbo_(software)
Windows 7 added the ability for a Desktop.ini file to add/change the folder verbs on a per-folder basis. Using that trick it is possible to create a "folders as applications" style setup.
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
Is there a way in Windows 7 to create a directory that has as its virtual contents all the files and folders from 2 other actual directories?
I'm hoping I can define a single dir that reflects the contents of 2 other dirs via symblinks or something without having to copy files.
*edit: I need to be able to specify the combining dir as a filepath. Looks like using a library doesn't let me do this.
c:\actualdir1\ a,b
c:\actualdir2\ c,d
c:\virtualdir\ a,b,c,d
thanks
Seems like libraries would be perfect for this. You can create a library and add folders to it from code, then use the library almost anywhere you would use a folder. You don't mention what language you want to use - for managed code the Windows API Code Pack has some wrappers for the shell stuff, and from C++ you can use shell APIs.
(If you're asking as a user then the answer is still libraries, but the question is offtopic and belongs on SuperUser.)
No, I don't think this is possible without writing your own Shell Extension. However, depending on what you are looking for, perhaps using Windows 7 Libraries would do the trick.
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'd like to make a customized file manager using Ruby, but I don't want to reinvent too many wheels. Is there an existing file manager with an open API that could be accessed from Ruby? Or, is there a toolkit or framework available to make my own file manager?
What do you mean by a file manager? Command line or GUI based? Do you need it to be full featured, or are you just trying to do a file selection window, or something like that?
If you'd like a GUI based one - check your OS. There's probably hooks for manipulating the OS's GUI file manager. They may not be offered natively in Ruby, but more than likely they're available in C. You can wrap the hooks in a ruby extension, and then do what you want.
If you'd like a command line like one - check out FileUtils. It gives you the hooks you need to find out the directory contents, move, copy, or rename files, and pretty much anything else you want to do.