Can I launch a program when a FOLDER is double clicked | Tech Off

John Melville-- MD
Equality Through Technology

I write software to assist medical professionals in collecting evidence in cases where children may have been abused. I have an interesting problem with data storage.

I would like to have my "data file" actually be a folder. My files are large (200+MB) and contain multiple JPEG, WMA, and (soon) WMV streams. I would like to use the file system to manage this stucture because that's what the file system does best.

Furthermore, when my district attorney discloses my data file to the defense (like we always have to) I want it to show up as a completely normal folder so that the defense experts (who presumably don't use my software yet) can quickly see that its just a directory structure full of file formats they already know about. Since we always disclose evidence on read only media I am not worried about the defense modifying the folder.

I am worried, however, that my own users will muck with the files in the folder, and my software is not robust to this possibility. (Right now I am using a SQL CE database that is pretty hard to modfy outside of my software.) I also want to have a real easy "just click on the file and my software opens up" experience.

Is there any way to make a folder look like a file? By this I mean that when you click the folder in the shell my software would open up instead of the shell opening a new shell window with the contents of the folder. It would be very nice if I could replace the folder icon with my own, this would make the disguise sufficent that any users who manage to open the folder in the shell are sufficently skilled to be held responsible for their own misery.

Thanks in advance for any assistance

Sven Groot
My name has 9 letters. Coincidence? I think not...

I think a better approach would be to store your data in e.g. a zip file with a custom extension so your app can recognize them, much like Word's .docx files are actually zip files.

John Melville-- MD
Equality Through Technology

In reply to Sven Groot

#Sep 30th @ 8:37 PM

Thanks for the tip. I actually not only thought of that, but implemented using the .net package library. A few problems came up.

1. The .NET package library performs very poorly in a highly multithreaded enviornment, and trying to serialize my data accesss was turning into a whack-the-mole bug farm that wasn't working. (I often have multiple audio streams and photos comming in from multiple devices simultaneously, multithreading is a must.)

2. The .NET package library has a particularly egregious bug that if you don't close it right, it throws an exception and leaves the file in a completely unreadable state. The software threw one of those bugs at me just as I was printing the results of a 6 hour long forensic consultation. I swore I would never use a data store that didn't support transactions. (So I could guarentee that the worst clicking save would do is take you back to the last save point.)

3. Beleive it on not, renaming a file from .pda to .zip is a little to complicated more complicated that some of my collegues want to deal with. (By expert here we mean medical experts, who are by no means computer experts.)

4. WPFs media player will play from a file, but not from an arbitrary stream. It would be nice to be able to hand a video file to that componet and have it just play rather than trying to jimmy it into working with a stream.

Anyway your solution is very good, and had a lot of positives running for it. If I could find a ZIP library that did in place zip file modifications, was transactional, and was threadsafe, it would be the perfect solution. Given that no such library is forth comming, I was hoping to find a hack to make it work.

AndyC

In reply to John Melville-- MD

#Sep 30th @ 10:55 PM

Theoretically you could probably do something like this with a Shell Namespace Extension, but at that point you are well outside the safety of .NET development and firmly in the category of hardcore COM C++ code. I think you'd have to be really worried to go to those kinds of lengths though (and it'd be a pig to get right).

Personally, I'd go with Sven's suggestion. That is probably the easiest/safest way of doing it. The default .NET zip functionality isn't great (it's really intended from zipping streams sent between web server/client) but there are numerous third party ones, I'm sure there must be one that meets your needs.

figuerres
???

In reply to John Melville-- MD

#Sep 30th @ 10:55 PM

have you looked at dotnetzip?

http://www.codeplex.com/DotNetZip

also what about an app that manages the whole thing?

like a file-explorer interface - so they get it on how to browse and view the data.

but you control read/write and versioning the files inside the app.

then have a combo of dialogs and drag and drop to "Add" | "Update" | "Publish"

where publish could log the action and copy 1 or more files to a normal folder.

so the user exp. is just like using the normal shell but with more control.

also dot net zip lets you encrypt the archives ... as this is legal stuff that might be a plus.

staceyw
Before C# there was darkness...

I can think of a few things I might do:

1) Personally, I would not use zip in this case. The wait time to unzip/zip a 200MB+ zip file is not appealing.

2) Create a meta file for each folder and associate that file extention with your app. Something like "Case1.pda" or something not common. Can associate your own Icon with that file extention and users can double click on it to open your app. The app will read the file, and do its thing with Directory contents. The meta file (e.g. *.ini) will contain properties for that Case. Like Name, Target Dir, etc. It can be xml, json, CSV or anything you want and can parse. Make the directory and file read only for Users and RW for Admins. The Directory in the Meta file could point anywhere, even hidden folders I would think or maybe even folders they have Read, but no view - I would have to play with it - but you should be able to find a combo that works well for you and your users.

3) There is nothing wrong with .Net's multi-threading. Has history of working fine. On the other hand, threading and locking is plain hard for anyone. Try to avoid it if possible, if not, try to use things like Task Parellel Library et al.

4) Not closing your files right is a developer bug, not a bug in .Net. Would have to see code to go further into that issue.

BTW - Vista now has transactional NTFS file system.

http://www.microsoft.com/uk/msdn/nuggets/nugget/69/Programming-the-Transactional-File-System.aspx